Devlog #9 – Local multiplayer UI (co-op) and Thread Hell

Posted by

This last two weeks I have been coding mainly the multiplayer part of the game. But I have been also having some multithread issues I would like to share.


1. Multiplayer UI

Local multiplayer is (almost) done! The first idea was to have different play modes, but for now I will just keep de Co-op mode. I will develop more multiplayer modes once I start selling and if it does ‘reasonably’ good. The worst part of it has been the interface.

Also I had the following problem, I just added stat points to the game, but I did not want the players to change their skill points according to the stats of the owner of the game. So I decided to add ‘Multiplayer Characters’. You start having 4 ships unlocked (with the same stats). And from there on, every ship has different attributes. I am thinking that in the future, it may be that each ship has different ability, but for now it won’t be that way.

Character selection

I realized I have a horrible UI/UX iteration time (and with no great result). Most of the time this week has been spent in redisigning the ingame UI for multiplayer. For the next project I need to work on that head on. I am thinking in a way of designing the UI in a different editor and import it to the game. Well, that’s for another day.

Multiplayer

Now the score is shown per player, which could lead to a competitive coop gameplay, at the end both score get summed up, but you know, one could have done better than the other:

Separated score

Also as you can see in the next image, the Combo UI and the turbo UI are now local to the player, instead of taking full window, they go with the player. I am not very sure about this, since it takes a reasonably big chunk of the screen and it may add noise to what’s going on, I have to test it more.

Local UI

I will make a multiplayer trailer after I invite some friends to play with. It’s hard to test multiplayer one your own!.


2. Thread Hell

So, I have the following architecture (simplified):

Render flowThe problem arise with the particles. The particles use a VBO that they are uploading through a render job and then sending it to render.

In main thread

  1. Create a render upload job A
  2. Submit render A
  3. —- NEXT FRAME
  4. Create a render upload job B
  5. Submit render B

In render thread

  1. Execute Job A
  2. Render A
  3. —- NEXT FRAME
  4. Execute Job B
  5. Render B

The problem was that when I am deleting a Particle System. I need to cancel any job that were submitted, because the mesh is being deleted. It is designed with double buffer (and you can only access your current buffer, so I can’t modify RT buffer from MT).

Now, if I cancelled a ParticleSystem Job after it has been rendered by RT, no problem at all. But no one assured you it had happened, and I did not want to wait on it.

Cancelling a Particle Render Job

The solution: DO NOT CANCEL THE JOB, DO NOT DELETE THE MESH

What’s wrong with seeing the particles one frame more? And not deleting the mesh? Nothing at all. Except the memory Leak.

So I took advice of a friend programmer of mine (Asier) and I started using pools. Not only the problem has dissapeared, I use many less meshes and particle instances. Good call!

Now the meshes and the particles jobs are only deleted at the end.


3. Other improvements

More sounds have been added, but there are things still missing feedback. More “art” has been added.

SteamWorksApi is on the way of being completed. Although some work need to be done for the mini dumps. The game will fail, and I need to stablish a way of knowing why and how to fix it as fast as possible. Plan for the worst, hope for the best.

A new song is on the way for the default songs! (This is arduous, it’s hard to compose).


4. What’s next?

  1. Steam achievements!
  2. Song select reestructure, the UI is just horrible.
  3. Songs!
  4. START PLANNING ON THE RELEASE! (This is generating some anxiety problems)

Leave a Reply

Your email address will not be published. Required fields are marked *