Lich Rising – compo entry
[I’d put an image of the game here, but WordPress doesn’t give me that option…]
Lich Rising is probably best described as an RTS tower defense in reverse built by someone who hasn’t played an RTS in a long time. It was developed solo in 48 hours with C# and Monogame. The details and download link are through the link above, the rest of this post will be a quick post-mortem from my experience creating the game. I’ll to talk about what went well, challenges I encountered, and the design process.
Some background on me, I’ve been developing games for years, but only came to LD in the last year. I’ve got a lot of experience and boiler plate for working with C#/Monogame, so the platform choice was obvious.
I wasn’t real excited about the theme selection this time around. The idea for this game was the only real feasible and interesting idea I came up with. This one just didn’t hook me. The final result is fairly similar to my initial pitch. Since I wasn’t super excited, to keep things interesting I pushed in new personal directions for art and code style.
Art Style
I’m quite pleased with how the art style turned out. I settled on the direction very quickly and the results are appealing for how simple the core style was to create content for. It might be difficult to tell, but there’s no real 3D in the scene. The style creates a good illusion and it looks better than if all the sprites were laid down from straight overhead. Each object in the scene is comprised of several planes parallel to the camera with varying heights from the ground. I think the key to it working well is the bright solid colors, no borders, mostly angular geometry, and little anti-aliasing. The effect gives a good illusion of a more detailed 3D model for a very low time cost.
I implemented it with a 2D camera by offsetting planes from the center of the camera based on height. I’m more comfortable working with a 2d camera, so I went that route instead of 3D. 3D obviously would have been the better choice given more time to experiment.
Towards the end of the weekend, I added several new models to the scene in just a few minutes, and the characters took maybe half an hour each. Some of my janky animations break the effect if you pay attention, but not severely with all the other action.
Early on, I also made the decision to use bright and unusual colors for the monsters and props, and drab colors for the humans. I think that helped add visual interest and convey what was going on when there were a lot of things on screen. The coffins were a bit of a challenge. I knew I wanted to make it clear you were raising the enemies you killed. They also needed to be findable and targetable by the player. A grave or cross might not have been easy to see in battle, and I suspected a dead body on the ground wouldn’t look good with the art style. A coffin seemed like the best choice.
In retrospect, I am a little disappointed in the ground texture, I wanted something that conveyed camera movement, but the result doesn’t look as good as I had hoped. I also wanted to go back and change the tower to be octagonal. It stands out as particularly not angular with everything else in the scene.
Development
The style of game and art style pushed my game logic outside my comfort zone. Most of the games I’ve built before this have either been turn based, or built on top of simulations that are still compartmentalized. Most of my code library has been built for integers and discrete grids. That didn’t seem feasible with this game, so I had to get comfortable with floats and vectors pretty quickly. For most game code that wasn’t a problem outside of a few hooks in my library. The two biggest problems – collisions and pathfinding – came at the tail end of the first night.
Leveraging the grid-based pathing code I’ve used before was impractical. I didn’t have anything resembling a useful quadtree or navmesh, and six hours in is a bad time to realize how important that was. The original plan was to build several windy trails through the woods. I considered a system of waypoints or possibly directional slopes to funnel units into the players home base, but that fell apart as soon as a unit encountered a player unit and gets led off-path. I also briefly considered something like hugging the right wall to sidestep obstacles. That was probably closer to feasible, but still a lot of work and still not great. Additionally, even simple collisions require more than comparing each object to each other object and look for overlaps. Not even having a reliable quadtree available, let alone geometrical collision system, was a major problem.
Luckily, the two biggest problems had a single LD-style solution. I constrained collisions to mostly happen in a single direction, removed most obstacles, and used the simplest collision model. By confining the space vertically, it let me divide the world into vertical slices that could reduce the search space for any given collision (it isn’t quite that simple, objects can exist in multiple slices, but it reduces the algorithms complexity by a significant factor). That same tool was also later reused for fast access to what’s on screen and what’s under the mouse pointer.
Each character on the map used a relatively simple state machine, with only some small variation between player controlled units and AI controlled one. The collision handling was managed in the state machine for simplicity, and is slightly interesting. On the tick for each unit, a first pass collision check is done against friendly units. If friendly units overlap, they apply a small force against each other so they spread out a little. Then a stronger force is applied towards their state goal (nearest unit or the player base). Finally, the unit checks for collisions with props in the scene where it’s planning to go. If there is a collision, the prop pushes back outward from the center of the prop, and then that final normalized movement is applied to the unit.
I had to make a choice in how to build the map. I could build a simple map editor and place objects by hand, or I could generate the map procedurally. In the end, I chose to place all the props and spawn locations procedurally for several reasons.
- Because of the issues with collisions there weren’t going to be complex path layouts
- I was worried I might need to change the map size over time (and I did), which would likely mean rebuilding the map
- Spending time to build a tool that then takes more time to use sounded like a lot of time total
Gameplay and Controls
The original goal was to have a single unit that would raise the dead, have direct RTS-ish control over the main character an their minions, and defend against waves of humans. Everything else I expected to would figure out along the way, and that worked out okay *this time*.
I sort of wanted to have the player work from a graveyard in the middle of a map with paths coming in from various directions, and obstacles like fences, trees, and graves. Technical limitations meant that probably wasn’t feasible, so I had to improvise. It was early enough in that I could still make large changes. I took some time to really think on it and work on some rendering and animation. It would have been easy to give up at that point. What helped the most was thinking about the subsystems I knew I would need and challenging myself to find a way to implement them quickly. If I built a simple collision system around circles intersecting, could I change the game to fit that restriction? If units only knew how to walk in a straight line and bounce off obstacles, could I change the game to fit that restriction? The answer was obviously yes.
So after making sure the game was feasible, implementing the collision system, unit state machine, and basic mouse controls, I had a mostly empty playing field early on Saturday. I still wasn’t totally clear on the goal of the game. Defending against waves can be fun if there is variety, but I wanted something more. I didn’t want it to just be a tower defense, and having a clear goal and end state can keep a player engaged. Taking the fight back to the humans seemed like a good idea from a theme perspective, maybe you attack a castle or village. That seemed like a lot of time. So thinking about limitations, what if I restricted it to just a tower as a representation of that? That could work, so then we had a goal.
So with that I had a barebones game. As I went, I took time to occasionally play around with the systems and imagine what I could add with a little more than a day left. I zoomed the camera out so you could better see and manage units, I made the map taller so it felt less like a corridor and gave some options for going around the edges. I spent some time on the controls.
I chose to have the spell casting be a two step process because I was thinking I might implement other spells where the location mattered more. Something like a corpse explosion or summoning a healing corpse flower turret thing. It wasn’t intentional, but it does have the side effect of adding more to do minute-to-minute, which is nice. I went with the cooldown time mechanic for spell casting because it was a safe choice. If I wanted to switch to like mana or something else, I would probably still have a short cooldown. After a bit of playing the game, the cooldown felt alright, so I left it pretty much untouched to focus on other things.
I then implemented some more thematic units, animations, projectiles. and wave spawning. Along the way, I noticed the map felt empty. Enemies trudged on a linear path, so the top and bottom were somewhat wasted. I had planned on adding random objects to the center of the map, but that would just mean sometimes the humans would look silly walking straight into objects. I also realized you could just send a unit along the back side and chip away at the human tower. Putting turrets in the middle as an obstacle was a logical solution.
I actually found myself with some time after implementing what felt like a decent mix of units. I could have added more units, I could have worked on the spell system, or I could have improved the progression. Those would have been nice, but a tutorial system was probably the best use of time. The controls weren’t going to be immediately obvious from within the game, and for an LD game there is a lot going on in this one. Tutorials and basic usability aren’t very sexy, but as quickly as people jump between LD games, it’s more important than many devs expect. A giant text dump or click through dialog is only somewhat better than nothing, so I definitely wanted some interactivity to it. It’s just a linear series of steps, and it was pretty easy to add a hook to progress the tutorial on certain basic actions. This was also a good opportunity to not just convey the necessary information, but give the game some flavor.
One of the last gameplay changes I made was to coffins. After a few waves, if you weren’t really keeping up with the spells, you would have a pile of coffins in the middle of the path of the enemies. This meant enemies could get stuck on the coffins and become easy targets, and you had all the coffins you could ever ask for. Removing collisions from the coffins was the first thing I tried, but the coffins looked a little weird when every unit was just stepping over them. I could have had a drop rate for coffins, but I felt something would need to happen to the enemies that didn’t turn into coffins. Luckily, I had a bit of a eureka moment. Making the coffins targetable by enemies was surprisingly easy to implement, and meant coffins weren’t a limitless resource and would never really get in the way of the enemies.
Sound
I’ve never been particularly musically inclined, but I wanted to push myself and include music this time. I had allocated about two hours for it, and had a looping track, but it obviously didn’t make it. I didn’t think it fit the game well. I was worried it was too distracting, and didn’t want a situation where music is worse than silence. I probably spent too long getting set up for it, I’l have to make sure I have a workflow figured out in advance next time.
I recorded quite a few sound effects, but only used 4 and really needed some more in places. I spent most of the time focusing on the battle sounds. I recorded a few dozen, trimmed that to 12, and then pulled the ones that weren’t speech after hearing them in game. Even playing with distortion and how often they’re played, the sound effects didn’t sound right in battle.
I also recorded a set of responses when you select a unit. I got as far as compiling them in, but then forgot to hook them up. Whoops.
In retrospect, I needed a few sound effects for a few other events. When a spell recharges would be really useful, and spell casting might be nice. Something when the Lich or altar is under attack would also have been good.
What went well
- I was really happy with how the art style turned out. If I want to implement another top down game, there’s a real good chance I go this direction again.
- I’m really surprised how much I got done. I didn’t really think I would get all the units in I did.
- There was a point in dealing with collisions and pathfinding that I considered scrapping the whole thing, but I’m glad I pushed through.
Needs improvment
- The controls weren’t great. Even after playing for a while I occasionally hit the wrong button, which is never a good sign. I did some research into control schemes, but I didn’t find one that made sense to really clone. I also forgot to add screen-edge mouse scrolling for the map. I meant to come back to that.
- Audio ate a lot of time, with very little to show for it. I need more practice with music, it would have been nice. I also recorded three dialog bits that I forgot to add to the game, and that’s just embarrassing.
In retrospect
- One lane of enemies is maybe too straightforward. I wish I had thought to break up the spawns into lanes. It would have added some variety and a use for the map edges. It would have been very easy to implement, but I just didn’t think about it in time.
- Unity is good at several of the things I struggled with. It wouldn’t have been a good time to start from scratch on a new platform, but it’s worth thinking about for the future.
Future
This post-mortem is really sealing the project. I don’t have a strong desire to polish this up an publish it somewhere. I learned a lot and it was a bunch of fun, but I have a long list of other projects in process.
