Uroboros Initiative is a puzzle game about preventing space from collapsing by making big hexagons out of smaller hexagons. Give it a play if you have time, player feedback is super awesome.

This is my second succesful Ludum Dare so I want to try reviewing some things I learned along the way.

Things that went well:

The Engine

Usually I use Unity3d. This time I used typescript + threejs + jquery built in webpack. It took about a week to learn how to get webpack to properly compile sass and typescript but it was worth it. I had no problems with running webpack during the dare, and even getting a few things like fonts to work was hassle free which is unusual for my webpack experience. It also let me develop a UI in HTML which I am very familiar with and can style much better than unity UI. And of course the deploy story was brilliant. Sending people one link where they can play the game is so much better than making them download some zip file.

Presentation Focus

My last Dare game Gunkata taught me that presentation is really important. I was satisfied with it as a game, but being visually bland really made it not appeal to players, so this time around I wanted to focus on aesthetics, and I think that was succesful. Using HTML allowed my to create a cool UI pretty cheaply. I also found a nice font which added a lot of character to the game. Something to try to build on again next time.

Dev Stress

This was by far the least stressful Dare I've done. Mostly this is just due to previous Dare experience, but also it's just a move away from a self destructive "at any cost" mentality where I wouldn't sleep or take breaks and break down in day two. I'm sure that I could have squeezed an extra few hours if I worked that much harder, but visualizing the Dare as just a weekend spent programming as the worst case really helped me not stress and enjoy the exercise.

Things that went okay:

Game Design

The core concept of the game didn't change too much from the outset. I wanted to make a strategy/puzzle game about preventing or reverting space from collapsing. But in hindsight this was really more of a plot idea than a game idea, so most of the competition was me doing exploratory playtesting to find the game.

This was a great experience as a game designer, which is a big part of why I do the Dare but it also cost me a lot of time. I think a lot of this understanding of what is a solid game idea is and what you should prioritise when playtseting is really hollistic and something you have to learn with practice.

As an example I spent about 3 hours on day 1 designing a sort of fractal tile that would have more depth if the tile had more 'space'. This was all for a mechanic that didn't wind up in the finished version where 'Vacuums' would have to be built to power Spacers by moving space from where they were to the Spacer.

It was something I knew was a mistake at the time but as a programmer it was a cool problem and I really wanted to solve it so I wasted too much time on it, but I'm trying not to kick myself too hard over it.

Things that went poorly:

Design Communication

Big truth: if your players can't understand your game, they can't play it.

• I did not explain enough.

I wanted the game to have a zachtronics style creepy office worker feel, but also I'm really bad at writing box text because I'm self conscious of my design. This is bad. It is totally ok to just explain how the game is played in a direct way.

• The game was more complicated than it seemed.

I tried really hard to reduce complexity. In a puzzle game you need it to be complex enough for the player to have something to reason about but you need it to be simple enough to parse. Some parts like the fact that your spacers move to an adjacent tile when a singularity appears on it are probably still a mystery to most players. Hidsight 20/20 I probably still couldn't have done anything about this without writing even more text, or making potentially confusing animations, but it's just something to understand.

I got a question from one player later about what the "wait" button does, and this was just embarassing to me because really, the wait button does nothing. I wrote a wait feature for testing that I added to the game as a "learning tool" to try and make it feel more realtime like the game had been in the beginning. But the reality is that it is a button that you should never ever press because it just makes the game harder. Bad Design.

If I'm going to spend so much time and energy trying to make my game look appealing and engaging I need to also make it parsable. Focus more on this next time. I'm not trying to make cryptoidcore games. Probably.

Sound

The second big takeaway from Gunkata was that sound was really important. This is also another thing that I understand logically but am too afraid of commiting to. Partly this was due to the problems I had in finding the correct design and always prioritising something else. I had to make really crucial balancing changes all the way to the last second so it's hard to just say do music no matter what.

I also have little experience with my music making tools and really need to invest some time into those skills before the next dare so that I can pump out a full track that I can actually put into my game and be happy with. But there are low hanging fruit I should have reached for. Like sound effects for building spacers. Or a low thrum ambient noise that grew louder or quieter with the number of warps. That would have just taken the spooky atmosphere up a notch and I'm really regretting not dedicating a bit of time to it.

Overall I'm happy with where this game wound up which I was not my disposition at the end of day one. And hopefully I get to do it again!

PS: Uroboros. Cool word. Really hard to spell.