Making of Nexus overload
You can play Nexus overload here, if you haven’t done so already!
Once the theme was announced by Js13kGames, I brainstormed a few ideas with my wife and brother. Personally, I found “Glitch” to be a very difficult theme to work with and after two days of pondering, scribbling and research I decided on a different approach.
I set some goals, picked three of the main ones and made sure every decision I made was checked against those:
- The game should be something that I considered to be fun and would play again in future.
- The game should have some form of replayability.
- The game should have some kind of progression system.
On the technical side, I wanted to improve my skills from my previous entries. So the game had to have:
- Scaling -the game should scale based on window size.
- Sound -my previous entries felt incomplete, and I suspected adding sound would go a long way.
From here I started looking at the game in a ‘thematic’ way. The theme could be incorporated in the story and with visual effects.
Taking these goals, the size and time constraints into account, helped define my options. A top down shooter was almost a no-brainer for me. I have always enjoyed these types of games and I felt it was quite easy to make them fun.
With my brother’s help, we came up with the idea of traversing a network. Initially we had elaborate ideas of a maze-like network that the data-packet (the player) could traverse. We researched the technical side of networks, data-packets, header files, network nodes, etc. and the initial idea was to move through the 7 network layers. The player had to navigate the network, encountering different enemy types and intricate boss rooms, with a few abilities to boot . The player would enter nodes or rooms in the network, encounter a bunch of enemies which he would have to defeat before moving to the next room, leveling up and buying upgrades to be able to move deeper into the network.
At the end of that session I had an idea, I knew how the theme would fit into that idea and I had clear goals which I wanted to accomplish by the end of the project.
I decided to start from scratch, only writing code which the game would need. I tried to abstract my objects only as much as would be useful in this application . I tried not to worry too much about writing reusable code, instead I wanted to write compact code. Directly accessing variables in other objects is something I generally try to avoid, but in Nexus overload I did it constantly (can anyone say ‘spaghetti’) as it meant I didn’t have to write special getter and/or setter functions. I know this approach leads to code that is a nightmare to reuse and maintain, but it did allow me to save bytes for essentials.
Collision checking with triangles and rotated blocks are much trickier than I first realized. I ended up doing something similar to AABB collision detection with all the entities in the game with the exception of the player character. I wanted the ability to have 300, odd, enemies with 200, or so, bullets on the screen at any time, and as such the AABB collision detection model provided the best performance, in my opinion.
Also, the bullet speed was high enough and the enemies were generally small enough that the player wouldn’t notice that it was not 100% accurate. The fact that the bullets have different angles (bullet spray), also helped hide the inaccuracy.
With regards to the player character, I decided to do the AABB type collision detection to see if any of the bullet are close enough to the payer. If the bullet is in that area, the game starts doing the more expensive collision checks to see if the bullet is actually hitting the triangle. This way I could ensure that the player only takes damage when he is actually hit.
At first I had a long list of features that I wanted to implement. Abilities, a ‘tech tree’, procedurally generated content and interesting enemy mechanics, were at the top of my list. Half way through I realized that the scope had to be reduced and I decided to start focusing on features that would support my goals the best.
I actually developed two procedural map systems. The first was too elaborate and frankly not fun to play with. The second (which the current is based on) was the ‘linear’ system that mimics a network map. This was also later abandoned for predefined maps, as the code to generate useable content was just taking up too much space. Pre-designing the maps ensured that the player would always see the content I wanted him to see, while drastically cutting down on the size.
By the time I was ready to start working on the abilities, I knew there would not be enough space and therefore abandoned the idea. I started working on the ‘tech tree’, which was removed almost as fast as it was implemented, purely due to the size constraint. I still feel this would have added massive value to the game, but I opted for ‘free upgrades’ based on highest level reached, at the start of future playthroughs. This helped my progression system goal and it allowed me to use a system that was already in the game.
This was quite a tricky one to get right. Just changing values based on my gut feel and trying them out did not get the results I was hoping for. The first 2 or 3 levels went great, but things tended to spiral out of control very quickly, either becoming too hard or too easy.
I had to design difficulty curves, compare them to the player’s stat curve and implement that. This was not perfect, as player choice makes a massive difference to the player’s curve, but it gave me a very good place to start from. Once I was happy with the enemy curves, I just had to tweak the upgrades to get my intended result.
I tried to design the curve to allow skilled players to reach level 20, but not much further than that. I personally have only been able to reach level 16, but I generally died due to silly mistakes and suspect the curve is not a 100% accurate. I suspect some players might go well beyond level 20 at this stage, but further testing will be needed. I definitely underestimated the time I would need to fine-tune a system of this type, but that’s part of what makes these exercises so valuable.
I am still going to add some form of data collection to the game and have a bunch of friends play it for the sole purpose of data collection. Comparing the actual data with the predicted data should help me understand where this system could be improved for future projects. I’ll post future findings, once I have them.
I really wanted to go for a retro, ‘crt’ feel but in the end I spent too much time and ‘size’ on the game and the progression system. I’m also already pushing the browser to its limits with the giant canvas I’m rendering to, so having too much ‘flashy’ filters and effects would be really hard to pull off, without sacrificing other things.
I am a trained multimedia designer, and lucky for me flat design seems to be all the roar these days. I decided to go for a plain and simplistic look that would be cheap to draw, interesting to look at, but familiar to the player.
The glitches ended up being basic size, angle and colour changes. The player is drawn from point to point, so that was also easy to ‘glitch’ by adding random values before drawing, giving the impression that the player is distorting.
Finally, I chose warmer colours, orange, red and purple, for elements that the player want to avoid and cool colours, blue and green, for elements the player should interact with. This should help the player easily identify friendly elements vs bad elements.
A lot can be done with very little. Flashing colours, twitching blocks and moving lines are what Nexus overload is made of. I am strong in minimalistic design, so I tried to incorporate that in my look. I know what kind of games I like and play, so. it was a logical choice to work with a genre that I knew well.
I had an absolute blast with the competition, it is a great way to improve my skills. I always learn tonnes of new tricks when participating in the JS13K competition. An interesting article on the Forbes website talks about “How Constraints Drive Genius”, having these kinds of constraints drive you to think ‘out of the box’, and to solve problems within these constraints. This principle is evident in a bunch of entries.
As an interesting side note, the very first game I completed was for this competition and it was an absolutely horrible game, but the experience I gained from that exercise is something that still serves me well.