The Anthology of Pure Phenomenology

So, in our case, the WM_CREATE message is initially sent when we create the parent window. That message is sent out, & instead o' Windows doing its thing by using DefWindowProc(); willy-nilly, we, the programmer, intercept or HANDLE that message & specify that, when that message is sent out, all these other child windows will be created. Simplifying to the extreme, that's all that "handling a message" means. It means we set up a case in our switch statement to run code whenever that case matches the message being passed into the WndProc(); function. If you understand that, programming with Win32 API becomes all the more easier.

Now, our game/application loop, is essentially a while loop that is conditioned by Win32 API messages. Back in our WinMain function, Ln. #109, we've created a MSG object, that will be updated with all the messages. "msg" with all lowercase letters is that object, & one of its properties "msg.message" is (gasp!) the message that is currently being sent out. Or will be sent out. Going down to Ln. #149, we're telling the while loop that its condition is true so long as the message is not WM_QUIT. So it will always be true, & the while loop will always run so long as the message is not WM_QUIT, & to ensure that that is our beginning state, we set "msg.message" to "not WM_QUIT" (Ln. #148). In order to handle both Win32 API messages & process SFML stuff, we use an if statement conditioned by the return value returned by the PeekMessage(); function. Microsoft does a better job o' explaining juste exactly what PeekMessage(); does:

As for the return value of PeekMessage();:

So! If there are no new messages available, 0, i.e., false, will be returned. Therefore, the code will jump to the else statement, & run the code therein, which is SFML specific. So, in effect, we're not really handling SFML events. We're juste making SFML draw things onto the screen, & we really needn't worry about SFML events because all our parent window procedures are handled in "Win32 lingo". (Whatever capabilities SFML has in terms o' creating buttons, UI's, &c. I, due to preference, outsource to Win32 API) Now, if, however, PeekMessage(); does return true, it'll translate that message for processing, & then dispatch it, so it can be taken up to the WndProc(); function (Lns. #177,178). This continuous juggling of Win32 messages & SFML-related things will happen forever & ever!!

Now, we can finally talk about the actual game. Honestly, as far as games go, it's an incredibly simple programme. The factour which determines the end state o' the game is the collexion o' all the apples drawn on the screen. The meat & potatoes o' our game loop will reflect this. See, e.g., Lns. #183--#201. The fact that I've spent a lot of words on describing how Win32 and SFML work hand-in-hand reflects the fact that, once we have that architecture in place, it's juste a matter o' figuring out the best places & order to set all our game-specific variables, game-specific class instantiation, game-specific functions, & game-specific logic. We have to think about, e.g., which variables will end up in our game loop, as opposed to which variables will have the dubious honour o' being global. The general rule-o'-thumb that I was following was this: if both Win32 & SFML needed access to this or that variable, that variable became global, since if Win32 needs a variable that SFML also needs, it'll need to be handled or modified in some non-trivial manner in WndProc();, meaning it's a variable whose scope cannot be limited to WinMain();, therefore the variables points, eatenApples, reset, &c. find themselves in the earlier portions of main.cpp (Lns. #23--#32). There're not many, but I imagine, once the complexity o' the game increases, more variables governing the functionality o' the game will have to go global, or perhaps it would be better practise to have these meta-type o' variables become members o' a class. Who knows? I'm still learning.

The first task ahead o' me was to draw the game's protagonist and move him with the keyboard (no animation). Perhaps I did this in manner that was more complicated than it truly needed to be. Tell me what you think. So, in my crazy mind, in the Spirit o' being a true Hegelian, I said, OK, let's separate the character's physical being drawn on the screen apart from the logic governing his movements. I decided on two classes. One which we'll call Player & another called Draw. These class's respective header and .cpp files can be found on PDF pgs. 6 & 9, respectively. Now, if I did make any REAL mistakes in this, it was making Draw's constructor handle the actual creation of the sprite. I could have used Draw for both the main character & the apple objects, instead o' having to create another class specifically to draw the apples. See PDF pgs. 13--14. I have to really look it over again, but I suppose Draw could have also handled the animation o' the character's sprite (perhaps still in its own class that inherits members from Draw?), in addition to the animation o' any other NPCs ore enemy characters should I include them in the future. But, the game being as simple as it is, this alternative method didn't occur to me at that moment. Alternatively, Draw would have no-parameter-having void functions, each specific to the creation o' a type o' character. So: loadSpriteForMainChar();, loadSpriteForNPC();, &c. All we'd have to do would be instantiate the class, & boom! Give all the variables holding the gfx & whatnot default values which mean nothing in essence, & create them in our loop wherever we please.

But that's neither here nor there. As it stands . . . well, you can see how it stands: main.cpp, Lns. #140--#146. Our Draw constructor takes in four parameters: we pass in the Player object by reference, the path o' the sprite sheet's location, & the initial values for the player's position on-screen (set by a #define up top in main.cpp, Lns. #18 & 19). This will allow us to create the actual sprite for later drawing/moving on-screen, set the initial position o' the sprite on-screen, & most important, match the position which it occupies on screen with the x-position & y-position values tracked in the Player class's logic. At all times, the Sprite & the "Player", P1, must have matching coordinates. We update these coordinates in Player.cpp, Ln. #60, & depending on which way yoo're moving (& therefore facing), we will also update the IntRect initialised in Draw.h (Ln. #11) in Player.cpp (Lns. #12--#43), with the appropriate sprite from the spritesheet. I think the logic in Player.cpp is pretty straightforward. Essentially, it's saying, if this key (either left, right, up, down) is being pressed, set the velocity o' the character to x-amount, otherwise keep the velocity at 0 (i.e., not moving), & before we update/move its position on-screen (Lns. #58 & #59) increase the x position by the current velocity. Also, Lns. #50--#57 make sure that the main character never goes off-screen. This SHOULD be a seamless process, so of course all this logic is run through in our game loop, main.cpp, Ln# 161.

Now the on-screen player will find his Sprite moving at the press o' a directional key. Detecting whether or not a key is being pressed can be done in a single line o' code for each key. Refer to main.cpp, Lns. #155--#158. It's that simple.

So now we have to draw the apples that our character will eat on the screen. The game's already boring as it is, so definitely we need more than one or three apples. First thing's first. Define the amount o' apples we want to put on-screen. I've done it way up top, in main.cpp, Ln. #17. Now, if we DID only want to create one apple, well we could juste write the code out, & that would be that. But even drawing 2 apples the ol' fashioned way would necessitate duplicating the same code. Now, I could have done this in the Object class. As a matter o' fact, I did try it this way, but since I needed "SFMLFrame"'s width & height (in order to make sure that neither apple was drawn partially off-screen), something about passing in SFMLFrame (a RenderWindow object) into a function, which would hold all the code that creates an apple every time it's called, always caused a compiling errour. Really, I could have juste declared two variables (or an array) in WinMain(); & put this information in those variables. It's funny how these simple & elegant solutions come to yoo EX POST FACTO. Anyway! I juste created a global function for easy access, & called it createApple(); in main.cpp, Ln.# 34. The apples, however, most definitely will be stored in a vector, which is basically an array whose size can change during run-time. Ln. #143, in main.cpp, shows the creation o' this vector. The function createApple(); (Lns. #34--#39) shows how each iteration (the total o' which is determined by the #define we looked at earlier) creates a new object o' the Object class & stores it in the vector "apples". We make sure that we have a limit as to where those apples CAN be placed, & the loadSprite(); function (whose definition can be found in PDF pg. 14) which is a member o' each object will use all this information to make sure that they spawn randomly & not collide with the player on start-up or after a reset. It works for the most part (the anti-colliding aspect), but sometimes an apple will still collide with the main character before the game has even begun. Another quirk to fix!

The collision detexion, frome what I've seen here & there, is pretty standard. Nothing fancy. All the collision detexion is done in one function, isColliding();, found in main.cpp, Ln. #41. Basically, it checks whether any extremities o' the Sprites' are intersecting. If they are, delete the object which is currently being checked against the player. Also, play a sound effect, increase the global variable (eatenApples) that tracks how many apples have been eaten & increase the points counter by an arbitrary amount that we set. Updating this information & displaying current stats on-screen (apples eaten, points accrued) will be handled by Win32. See Lns. #165--#175 in main.cpp.

Now, our game loop will determine if the game is complete if all the apple objects have been pushed out o' the vector. See main.cpp, Ln#183. (Other parts of the game loop will be restricted by the gameOver & reset booleans) The reason we have a boolean "toggle" as part o' the condition is because we only want to run through those lines of code (#183--#201) once, but the "reset" boolean should still be true 'til the player clicks the reset button, in which case the game will restart; but before any o' that happens, we want to make sure that the game understands that it CAN be reset the game if it player so chooses, that 'til then, it is in the Game Over state, & that toggle which allowed us to run through that code in the first place is switched back to false, that way (1) our stats are not repeatedly sent to the server & sent to the MySQL database God knows how many times, & (2) more apples are generated only once, & the main character's position on screen is reset once. I know the "goto" statement (Ln. #201) is generally frowned upon in the programming community, but it was such an easy way to break out mid-loop.

That said, if we've specified that connecting to a server is permitted (it is), we take all those stats, along with a timestamp, and transmit them to a UDP server. The sever is a different programme. I've already linked the PDF for that programme above. I'll refer to "udp_server_code.pdf" as the server code, ore something general like that. In an ideal world, the server would be running 24/7, & every time a player finishes the game, the game (now having become a UDP client) sends those stats. The server receives those stats, connects to a MySQL database, & inserts that information therein. I've got a working demo in place. Click here to check out a demo o' the end result. The circle is complete!!

The Network class only contains a single member function: void transmitData(); which takes in three parameters: a timestamp, the number o' points, & the number o' apples eaten. You can see this on PDF pg. 22. The definition o' that function (Network.cpp, pg. 23) is nothing but WinSock. WinSock is the socket-programming library created by Microsoft, so programming noobs like me who don't know a thing about Linux ore any o' those uber-programmer-approved tools can actually fiddle around with these weird things called sockets. Now, I understand what I'm doing in the function (it's rather simple once you get your head around the concepts), but Sloan Kelly will do a much, MUCH better job explaining the process involved in connecting a client with a server, & once the server has that information, you juste treat the rest o' the process o' sending data (from your server) to your MySQL database as normal. My comments in the game code, in Network.cpp, in any case, clearly state what I'm doing. What I figured out too late, however, was a more efficient way o' packing all the data I want to transmit, & it revolves on a simple principle that is self evident in the code as it stands. However, let's take a look at what I'm already doing in Network.cpp.

First of all, I'm making sure that every bit o' information is in std::string format. This makes sending the data a lot less complicated. The timestamp, which is "stamped" in main.cpp, Lns. #188--#190, is already comes in a string. Nice. "points" & "eatenApples" come to us as integers, so we simply convert them to strings (Network.cpp, Ln. #13 & #14), & later, juste as the timestamp, send them off, loop by loop, as a C-string (Network.cpp, Ln. #34, #37, & #40). The alternative I SHOULD have taken is inserting all these values in an array, & send them off in that array, not because it looks cleaner (it does), but because "time", "points", "eaten" are going to be sent off in some arbitrary order the programmer chooses (that's the "simple principle" I alluded to earlier). So, when the server receives the information, (1) there is no need for all this acrobatic jumping between loops (as you will no doubt see in the server code), & (2) there will be no chance o' that order o' information being disrupted by the fact that the server is being sent data from multiple users one after the other. Apparently, doing THIS is tricky business as well , but I think I could make it work. If anybody knows the logistics involved in this, please oh please, let me know. It certainly seems like a better method than the one I'm using in the game (client) and server code.

That's all, folks!

Originally published on Fri Aug 07 22:00:24 2020, & last updated on Mon Aug 10 23:43:04 2020