Everblind is a 2-4 competitive local multiplayer game.
Played on a single, top-down, shared screen, everyone controls an invisible ball inside a maze and must capture a golden artifact to win the game.
The gamepad’s vibrations are crucial in this game. They are your only feedback when you are invisible, so pay special attention to them. Use your attack to destroy any opponent in your way, but do it wisely, for everyone will see you then.
Feel free to reach out to us for a build of the game, we'll happily send one to you. You can also check out our presskit() at Digitalkingdom.ch
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.
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!
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:
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:
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:
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:
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.
While our artist was on holiday, he designed two new maps which I’ve integrated. Please welcome “Trapped” and “Random Access”:
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.
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.
We hosted the very first tournament of everblind and it was awesome! It gave us plenty of ideas for improving the game. I also rant a bit in this article...
Introducing “King of the Gold”: a noob-friendly version of the original “Gold Rush” game mode. Also completed features in the main menu (game...
Ever wondered how the game looked like in motion and not in shittily compressed gifs? Now there's a video for that!
No articles were found matching the criteria specified. We suggest you try the article list with no filter applied, to browse all available. Post article and help us achieve our mission of showcasing the best content from all developers. Join now to share your own content, we welcome creators and consumers alike and look forward to your comments.