• Register

Everblind is a 2-4 competitive local multiplayer game. Played on a shared top-view, players control an invisible ball in a maze and must capture a golden artifact to win the game. We are looking for alpha testers, so if you are interested feel free to reach out to us @everblindgame

Post news Report RSS Devlog for version 0.24

Nordic Game, new maps, and why you shouldn’t let your artist do particle emitters unsupervised. Come read devlog 0.24!

Posted by on

Hello there, Restaste for another devlog for this 24th iteration on the game. Pleased to have you, get a seat and a cup of tea, and let's dive right into it.

Nordic Game 2017!

Next week the Nordic Game conference takes place in Malmö. We’re very proud to be part of the SwissGames delegation there! As part of the delegation, we get 2 full expo passes, a financial help per studio for travel and expenses, access to the matchmaking module with a ton of credits, we get put in the publisher market for quick pitches, and we get a spot in the Swiss booth to showcase our game. We’re all pumped up and ready to go! Many thanks to ProHelvetia for including us in the trip.

We’ll land in Copenhagen tuesday 16th, take the train to Malmö and then setup the booth with our Swiss colleagues there until 6pm. On Wednesday the Publisher Market takes place, thursday is booked for matchmaking and on friday we’ll dismantle everything at 3pm. We’ll be on our way back saturday morning. That should be a pretty busy week.

Anyways, if you’ll be there, feel free to get in touch, we’re always happy to chat!

Performance (or why you shouldn’t let your artist create particles unsupervised)

I’ve been profiling the game a little, to pinpoint what was eating so much performance. The result: our particle emitters (obviously, duh). I setup a test scene in which all our 6 balls were constantly attacking, to see how my GTX780 TI was taking it, and I was stunned by the result: >90% GPU usage. It got down to a ~10% GPU usage when the balls were not attacking.

So I looked into the emitters. Our artist implemented them with GPU sprites. That is not a problem usually, except that we emitted tons of transparent overlapping sprites. To illustrate, here’s the “shader complexity” view of one of the emitters:

image10

As you guess, green is okay, red is bad and white is terrible. Each square is a 3d quad that needs to be rendered. This "shader complexity" view represents the number of shader instructions that were required to render each pixel. So what we're seeing here is transparent sprites taking up a large amount of screen space and many more smaller sprites. These are all more rendering passes that make the whole emitter very suboptimal.

Here’s the same emitter after an optimization pass:

image8

The updated version performs much better, with even more particles! The secret ingredient was opaque materials and mesh emitters.

The problem with overlapping transparent sprites is overdraw: because the sprites are transparent, no culling can be made, and all the sprites are drawn on top of each other. This means that rendering one pixel requires way too many instructions. We switched to using 3D meshes with opaque materials instead of sprites. The difference: the meshes write to the depth buffer, which prevents overdraw, and they come off as green in the complexity view.

Here are the meshes we used for each emitter:

image1image3image4 1


image6image7 1image11 1


Ball selection in main menu

If you’ve read the previous devlog, you know that players can select which ball they play with, but the feedback on the main menu is missing for that. I’ve quickly improved upon that in this pass by creating and destructing the corresponding ball for each player that has joined the game. Here’s how it looks when four players joined:

image5 1

With this menu selected, when you press left/right your ball changes to reflect the one you select. Pretty neat! Still an initialization bug that remains, which will go away when we do a second pass in this, with an animation of the box opening when we select it.

I’m still missing feedbacks for the game modes selection, and I hope I’ll be able to do it in the next sprint.

Fifth and Sixth map

While our artist was on holiday, he designed two new maps which I’ve integrated. Please welcome “Trapped” and “Random Access”:

image9

image2 1

They should play very differently, with Trapped being a tight environment, with plenty of short-range fighting and the deadly jaws that prevent passing the longer lanes. Up-close and personal. Random Access will be much more open and players will fly next to each other pretty often, creating intense moments of “are we in the same path about to collide, or are we going to fly by each other?”

I'm very excited to try these out in the coming days!

These images are concept arts, but the meshes are ready and integrated in the game. I’m just missing the final textures, so I’ll post in-game images as soon as I’m done integrating them.

What’s next

In addition to all this and the ton of bugfixes we’ve done from the first alpha feedbacks, this has been a very productive sprint! Now that the core feels robust and our first elements (see Indiedb.com) are implemented, we’ll do a second pass on playing around with our core mechanic and see how it can be expanded to support more diverse play.

/Restaste

Post comment Comments
g-phil
g-phil - - 11 comments

Good stuff! :-)

Reply Good karma Bad karma+1 vote
Post a comment

Your comment will be anonymous unless you join the community. Or sign in with your social account: