Programming

I haven’t updated this blog for a couple of weeks so I will be summarizing each week up until now below.

Week 48

This was the week where I made the Webserver for the second assignment of the course Game Programming III at Uppsala University.

The code for this small project can be found here.

Basically the assignment was to host a webserver that could be accessed through the ip of the host, when accessed the server would first answer the connection-call and then send back a header containing the same information as every other webpage header should. The data that the server recieves from a client includes a GET-request that tells the server which page it wants to access. I handled this request very simplistically at first, sending the index.html-page every time, no matter what the request was. At the same time I had a webpage written in the code and not an actual index.html-file that was read and sent.
Seeing as both of those were required to pass the assignment I had to remake alot of things, the first thing I did was to create the method LoadPage that took a std::string page as a parameter to attempt to open and load a webpage instead of having it written in the code itself. This made the first issue easier as I could simply retrieve the requested page from the header sent to me from the client and attempt to open and load that page, and if it failed I redirected them to a 404-page of my creation.

All in all I made just about as simple a webserver as possible seeing as the only grade for this assignment is G (Pass), I would rather spend my energy on the third assignment that we can actually get a VG (Pass /w Distiction) on.

Week 49

Another server was made this week, this time for assignment 3 of Game Programming III.

This assignment is to choose one of three preset concepts (racing, space shooter, marble game) and then make a 3D-game using DirectX and C++. The concept that my team (Myself and Laban Melander) chose was space shooter but instead of the twodimensional standard space shooter we asked and was permitted to make a first person shooter instead.

The concept document for this concept can be found here: https://docs.google.com/document/d/1IKorgIe-K1CIddaYZSanQPoJmU9qiwgo3DCjwJVN8hg/edit?usp=sharing

A link to the repository will be posted when we have progressed enough to feel comfortable sharing our code with the world.

Back to the server.
I used the same principle as the webserver from the week before, only this time it has to use UDP instead of TCP because of the slow nature of TCP and the fact that a FPS has to be near instantaneous for it to be playable at all.

This meant that I had to change alot of things, mostly though it was the three-way handshake of TCP that took up most of the time. The way that TCP handles packetsending is that it checks an address if it is trying to send data and if it does it accepts this request and then recieves the data. UDP however just stays openended and tried to recieve data from anyone and if a client wants to send something to the server it arrives with minimal delay. The problem with this method is that no side of the connection verifies that the sent packet actually arrived and just keeps going no matter what happens.

The way I chose to do this (and this is still untested in practise and will most likely be changed) is to send every movement from every player to the server that then cycles through every known connection (stored when the first packet from a source is processed) and sends it back out to everyone.
One of the problems I see with this is the unreliability of the messages being sent, if for example a player fails to recieve another players messages for more than a second in a 1v1 fight then that player will percieve his opponent as continously moving the same direction of the last recieved message (it sends position and direction in every message) and no bullet has been fired during this time.
This means that if the player that is not lagging shoots the other player the message will not be delivered and that player will take no damage, thus having the upper hand just from lagging.

Some ways of solving this would be to store every players data on the server and tell this lagging player that he did infact take damage even though he never saw the other player shooting. This could, however, lead to the players feeling that the game is unfair since he does not know what killed him but seeing as it is just a programmingassignment and not gamedesign it’s fine.

The message interpreter looks for “codewords” to know what has been sent in the message, for example SENDER: Bullda ENDSND will read from the : to the E of ENDSND and store that as the identifier of that ip address.

Week 50

During week 50 I made the states of our FPS. The hardest part of doing this was understanding how the project that our teacher had given us as a template for our projects even worked.
Most of the project was selfexplanatory but other things seemed almost too abstract to comprehend. Again, I will share this code when it is ready.

The statemanager provided uses a state factory-class to create and attach states to the manager using a stringhash for an identifier and an abstract state-class as a base. I made the menustate and the gamestate using this, and then started working on a way to implement the server/client that I made last week into this project.

Week 51

This week I made modifications to the menu as well as managed to build and include the library AssetImporter or assimp for short.

By far the most timeconsuming part was getting assimp to work as it simply would not build in CMake.
After troubleshooting both online and asking our teacher, and after trying many different versions of assimp I finally found the answer: you have to have the DirectX SDK installed on your computer or it wont build. What had confused me first was that I had DirectX installed already, and every file was in the folder it was supposed to be, and yet CMake insisted that the files did not exist at all.
When I finally managed to build the library I was presented with a bunch of solution-files and no lib-folder in sight. Luckily in my previously mentioned troubleshooting I had read that you had to open the files and build them in Visual Studio to finally get the so so elusive lib-files.

After building I was tired and just entered the folder and searched for every file with the extension .lib and copied them into a folder that I included into the project, paying no heed to the names of the files. After changing the compiler to build the 64-bits version it finally, after so many hours of errors, worked. Assimp was implemented.

All that remains now is to read and handle the data that assimp reads from the modelfiles and then convert that into actual models in the game.

The other thing I made this week was the menubuttons, using a GUITexture that the other member of my team had created before to render two-dimensional textures on a fixed position on the screen no matter where the camera moves or is pointed at.
The button compared the position of the object (building a rectangle using the width and height of the object) to the mouses position and if they overlap the button is triggered.
This worked fine until I tried getting more than one button rendered at the same time, this proved difficult since apparently the only thing that is drawn is the last read texture, so only the last button created would be rendered.
This problem has yet to be solved but I will be updating next week with how it was solved.

EDIT: Solved it, one of the variables in the GUITexture-class was static and was updating every object with the latest ones position, rendering everything in the same place and the last one being drawn as the one on the “top”.

Thank you for reading and I’ll see you next week!