Ludum Dare 50 has been the most fun I've had in a game jam in quite a while. Leading up to the event, I had decided that the instead of participating in the 48 hour Compo format as usual, I would try out the new Extra format.
Almost immediately, I realized I wanted to keep working on this idea after the Ludum Dare event. So instead of rushing to get a game out, I took my time working on the core game loop. As a result, the final product is more of a tech demo than an actual game, but I'm really excited about where I can take this in the future.
Enjoy!
Week 1
On Friday evening, I got home from work and sat down to have a quick dinner right as the theme was announced: Delay the inevitable.
After brainstorming for just a few minutes, I came up with an idea that stuck, and latched onto it. I would make a game where the player is alone in the woods, with a slowly dying fire, and they would have to feed it firewood to keep the flames alive as long as possible. There would be no win condition per se - your metric for success would just be how long you can keep the fire going before it inevitably burns out.
Great! That seems like a solid idea. Next challenge: what should the gameplay look like?
For years, I've been wanting to make a game on a hexagonal grid, but never had any ideas of what the actual game would be. This seemed like a good time to try that idea out. The player could occupy a single hexagon tile at a time and search out tiles that had a wood piece to collect. Once they have enough pieces of wood, or have strayed too far from the fire, they can make the journey back to deposit the firewood to the campfire.
Because I was going with discrete movement on a hexagon grid, I also wanted to take visual and audio inspiration from board games. It felt like a natural fit with the gameplay, plus it would make the models and sound assets easier to create on a tight deadline.
Since hex grid movement was going to be the foundation for this game, I figured starting with the hexagon tiles themselves was a natural starting point. I hopped off to Blender to whip up some low poly hexagons and got them imported into Unity.
Once I was happy with the grid layout, I created a simple player token and coded some movement behavior. I was exhausted at this point, so once I had the proof of concept working, I headed to bed.
I spent the entirety of next morning working on audio. Continuing with the board game theme, I wanted the sounds to give the game a very tactile feeling and response while playing. I experimented with dropping a variety of household objects onto different surfaces until I got the sounds I liked.
I also needed some color on my assets. I briefly considered going for a painted wood look. While it would have been thematically consistent, it didn't seem like I was going to get good looking results quickly enough. Instead, I used a shader that I wrote last year for my game Hedge Maze. It does a simple blend of 4 colors depending on the direction the surface of the object is facing: Top, Front, Side, or Bottom.
I also spent a lot of time modeling and animating a campfire, which didn't work out very well. It had been a while since I had worked with animations in Blender and Unity, and I fought for a long time to get several animations for the player token, tile, and campfire working in the game. Ultimately, I had to cut my losses and decided to animate everything in code instead. This burned up a lot of my Saturday.
Sunday was a bit of a wash as well. I spent a lot of time working on a visibility mechanic, where tiles would be hidden if you were too far away from them. One thing that I did achieve was a board that generates new tiles as you explore. I am really pleased with the effect!
Unfortunately, that's where I had to stop for the weekend. I was not able to get the firewood mechanic implemented, which is supposed to be the core of the game. Thank goodness I have 3 more weeks!
Controls: QWE, ASD to move.
Week 2
After recovering from the jam weekend, I needed to plan out what I was going to spend the next couple of weeks doing. I really felt like I'd come up with an interesting idea for a project that I would want to keep working on, so instead of trying to rush out a quick playable game, I decided to take my time and see how far I could get in the next week working on a solid foundation for future work.
Of course, that meant I deleted all my code and rewrote it all from scratch.
See, the problem with my jam code (and I expect a lot of others have this issue too) is that it's written to get quick results on screen, but it's not scalable by any means. Speed comes at the cost of flexibility and stability, and it really leaves your project in such a messy state that it would be difficult to work with it for too long.
The first thing that I knew I needed to do was rewrite the hex coordinate system. My first implementation was rushed and naive. I treated the hexagons as a 2d grid of squares; each column offset by half of the former.
The problem with laying out hexagons this way is that it makes a lot of simple operations needlessly difficult.
Because each column is offset by half, your Y coordinate is always dependent on whether your X coordinate is even
or odd.
I needed a better solution.
A year or two ago, I had bookmarked a webpage: Hexagonal Grids: from Red Blob Games. Specifically, there is a section on Cube Coordinates. I'll admit that it took a while to wrap my head around the idea, but once it clicked, the math behind the grid system became way simpler.
The link above explains this much better than I ever could, but the basic idea is to give each cell 3 coordinate values:
Q, R, and S. Each step to a neighboring hexagon changes exactly two of the coordinates.
With that figured out, I also needed to work on the gameplay loop. I was really starting to think about the gameplay in board game terms - where each round, each player takes a turn that consists of 1 or more actions.
Unity's coroutine system is a really handy way to build this loop - it lets us step from action to action and wait for player input, while still allowing things in the main update and render loops to continue uninterrupted. If you're curious about the implementation, check out GameManager.cs on GitHub.
The last important thing I needed to do was break up my components. I had a few bloated components that were handling all aspects of the game. Keeping scalability in mind, and also trying to obey the single-responsibility principle, I needed to separate my components into smaller pieces that did just one thing each.
Probably the most important part of that was separating the pure logical implementation of the data models that the game deals with from their physical representation on the screen. To that end, I split everything into a separate "Brain" and "Body". The brain would handle all the logic of the game, and then it would send update events to the body so that it can show a visual representation of what had just happened.
For example - an Actor represents an entity on the board that can take an action (such as the player), and the Token
is the 3D model that represents that entity. So when we want to move, we call Actor.Move(), which will update the
actor's position. At the same time, the actor also calls Token.Move(), which will play the animation and move the
piece on the board.
After all that work, the game ended up playing exactly the same. No new features were added, but I had a much more robust foundation for the game.
Click to play Embers v0.2
Controls: QWE, ASD to move.
Week 3
As the last weekend loomed, I knew I had to take a minute to figure out what the end product of the jam would actually look like.
I had my mind set on working slowly, but at the same time, I wanted something playable with a definite start and finish. Even if the end result would be more of a tech demo than a game, it should still have gameplay elements that are obvious to anyone giving it a shot.
This is a game jam after all. It feels wrong not to have some semblance of a game.
There's not much to write about at this point - most of the code written in this last sprint was quick and will be discarded when I do my post-jam cleanup. I did more work on the visibility mechanic, and threw together a quick system to randomly distribute wood as you explore the board.
The intro and outro do an okay job at bookending the experience and making it feel like a game: you know your goal and inputs moments after booting up, and the number of rounds you are able to last serves as a score mechanic.
One thing that I am a little proud of is the animation of the board collapsing when you finally run out of turns.
At that point, I decided that this was an appropriate stopping point for the jam.
Click to play Embers v0.3
Controls: QWE, ASD to move.
Thoughts on Ludum Dare Extra
I'll echo my sentiments from the beginning of this post: This is the most fun I've had with Ludum Dare in a long while. The Extra format gave me time to work on a fun prototype and still live my life. And more importantly, it transformed the event from an exhausting, panic-filled weekend into an inspired weeks-long journey of creativity and exploration.
In the past, I would have viewed this final product as a sort of failure. It has some clever ideas, but it isn't particularly fun, even through the generous lens that we view jam games through.
But I did what I set out to do. I started working on a new game, and had a blast doing it. I have so many ideas for where I can take this project in the future, and I can't wait to share it!
Post-jam
(I'm writing this long after the fact, and do not know what happened to v0.4)
For the rest of April, I worked quite a bit on refactoring the project and trying out some new ideas. Unfortunately, due to work and real life obligations, I got kind of burned out on the project, and wasn't able to work on it for a while.
Because my personal projects more or less live and die based on momentum, I think that means I'm going to shelf this game for the time being. I learned a lot, so if I don't end up coming back to it, then this was still time well spent.
Plus, I got to spend an absurd amount of time exploring hexagon math. I don't think me and hexagons are over quite yet.
Alright, let's take a look at the updates. The biggest task was stripping out all the "gameplay" from the Ludum Dare version of the game. This allowed me to focus more on the core tech of the board generation and movement, which is what interested me most.
Another important update was adding regions to the board. This let me group individual hexagons into larger hexagon regions. The idea is to use regions for loading and unloading sections of the board for performance reasons, as well as being able to break up the world into more interesting terrains and biomes.
Finally, there's also some height variation to the tiles in this version of the game.
Click to play Embers v0.5
Controls: QWE, ASD to move.