Tuesday 25 November 2014

Game Engines Blog 4 - 2LoC

This blog I'm going to be talking about my experience using the 2LoC engine as a 3rd year student game developer. This engine in no doubt gives a lot of useful tools for easily rendering simple geometry or text and is pretty organized with its entity and component system. The samples included gives a lot of useful examples to obtain code and learn some of the functionality of the engine. The project setup with cmake allows me to create multiple instances of a project with all of them sharing the same assets path saving space. But while all of these aspects are great, I feel that it comes with a lot of drawbacks. To start off, there is very limited documentation available online and not much of a community which makes it more difficult for me to resolve an issue in a short period of time, and there have been many instances where I was completely clueless as to why some things weren't functioning properly or having massive frame rate drops without knowing the underlying cause. Another example would be the random euclidean values being assigned to floats belonging to other entities when creating new separate materials completely unrelated to those objects. There are also instances where behaviors of certain entities change every time I re-run the project even though none of the code was changed. These unpredictable behaviors and being unable to understand the background operations has caused some deal of frustration at times and has often led me no choice but to look for a work around fix. Some of things I was easily able to accomplish in last year's framework takes more effort to mimic in 2Loc and may run slower as well. I've also found sending in uniforms to the shaders is more of a complex task then it needs to be. Compared to last year, I feel I have a lot more overhead when working with 2LoC in this year's workflow. But the engine is pretty sophisticated and I'm overall impressed with the modularity of its entity and component systems, but I feel that it still needs some work and optimization to remove these unpredictable behaviors and slow downs.

Sunday 2 November 2014

Game Engines Blog 3

(In game screenshot)

These past few weeks I have been playing around with more texture backing and global illumination. And seeing how our maps will be static, this made sense for us to bake some of the lighting effects. I think the end result looks pretty nice, it gives a more realistic look to our levels. 

I've added some bloom post processing effect to our game as well. This was done by creating an FBO with color and depth attachments along with a post processing shader that works on a single texture. 


(In game screenshot)

Our gameplay will have a heavy focus on multiplayer, so I wanted to have a quick way to test it early. What I did was implement a familiar library called SDL_Net, which does very simple server to client communication with TCP/IP packets.


//networking
if (isOnline)
{
net->send(&netPlayer);
net->recieve(&opponent, &netPlayer);
}

I've set up a simple server that will assign IDs to each game client. The clients have 2 functions, Send and Recieve, once the server receives a packet, it will send out the packet to other clients that isn't the sender. This is a very basic form of networking and can work through LAN connection by assigning the client's with the appropriate IPv4 address.

Each packet data simply contains player data stitched into a single char array format then sent to the server application.

math_t::Vec3f pos = p->model.position;

//this packs data into a single char array (tmp)
// 1 = packet id, %d = ID, %f positionX, %f positionY, %f positionZ, %1f rotation_angle
//%d for int, %f for float, %1f for double
sprintf(tmp, "1 %d %f %f %f %lf \n", p->getID(), pos[0], pos[1], pos[2], p->rotation_angle);

 int size = 0;
int len = strlen(tmp) + 1;

while (size < len)
{
size += SDLNet_TCP_Send(connection, tmp + size, len - size);
}

And that's the current state of our game. We plan to use this to polish our gameplay and test various forms of PVP game types in the near future.