I missed out on the development update last week, so this post will cover that time period as well and be a bit longer as a result. The game is shaping up, but some unexpected snags have pushed the release timeline by about two weeks. Doing this in my spare time means I have very flexible timelines; I don’t always get the time to work on it that I think I might.
During my first push of the alpha version I was hoping to get some feedback on the graphics, gameplay and interface. Unfortunately there were some compatibility issues with the shaders I wrote and that was all the feedback I got. None of the machines I have access to had the issue so I was a bit stuck on that, but lucky for me one of my testers who had the issue was very accommodating and let me send him iterative builds until I got it worked out. I also managed to fix the other issues that I found in the build that caused crashes in certain situations.
An example of the shaders that caused my compatibility issues.
After tackling the bugs with the alpha release it was time to start finishing features to get ready for the beta. I had a few vacation days I had to burn through at my day job so I decided to use them to go on a four-day coding binge. As the weekend hit, so did a lapse in motivation to code; I ended up taking an actual vacation, spending time with my wife and catching up on my pile of unplayed steam games. I’d rather take a hit to the release schedule than burn out and not finish as has happened so often in the past. It did a lot of good as I was able to tackle some issues that had plagued the game since it’s inception when I came back to it after the break. Issues mostly related to lighting.
Blending the lights resulted in this bug where you can see into a room without having to enter it.
One of the big changes between the Ludum Dare version of this game and what I intend to release is a drastic improvement in graphics. The per-tile lighting that the LD version used was fine for a 48-hour competition, but it was unsightly and I wasn’t a fan of it from the start. The first thing I did when updating the graphics was to blend the lights across the corners of the tile to get a smoother look. This caused the unintended side effect of being able to see into the edges of rooms without actually entering them. I knew what the answer was, I needed to calculate the lighting by vertex instead of by tile, but initial attempts at that were not successful, so I hacked together a “close enough” solution by computing vertex brightness by averaging the adjacent tiles. After my break I took another swing at it and got it working flawlessly.
Vertex lighting, keeps rooms completely dark if you haven’t seen into them.
One of the common pieces of feedback I got during the Ludum Dare competition was that the puzzles were unintuitive. One of the reasons for this was a lack of good visual feedback to the user, specifically there was a puzzle element involving restoring power to a door to get it open, but there was no way to know that’s what the issue was, and when power was restored there was no way to really tell anything had happened, as the only change was a door opening somewhere offscreen. I like the idea of messing with the power on the map to sneak around, so I didn’t want to scrap it, but I did need to make it more obvious to the player what was going on. The first way I intended to do this was to tie the room lighting to the power system. This would ensure that the player knew something had happened and have a general idea of the area affected. The second way I intended to do this was to give the switches on the map some indication of whether or not they had power. After a small hiccup due to blending weights, I got colored lights working on the map and added a soft purple glow to each powered switch.
It should be obvious that the only switch here that isn’t powered is the one in the bottom left.
The last missing piece of the lighting puzzle was mobile lighting. With the ability to turn off the lights in an area, some new puzzle concepts became possible. Areas guarded by aliens might be passed by cutting the lights and sneaking across under cover of darkness. To make this not a miserable experience, the player would need a way to be able to see in the dark. This was a much easier problem to solve than I thought it would have been, but it exposed a deeper issue that previously had been less obvious. The way OpenGL blends light across triangles, and the way that LibGDX renders images to triangles in OpenGL causes a bizarre issue with light along diagonals. At the moment I have no good ideas for how to fix this, and since it doesn’t actually affect gameplay I’m not too shaken up about it. I would like to fix it eventually, but I don’t want to delay release because of it.
Sneaking into a condemned lab with a flashlight.
You can see the jagged blending issue on the top of the light cone.
After spending far too much time on lighting, doing a slight update to the blood trail mechanic to give the aliens a way to track the player by them, and reworking the action-finding system to be a bit more efficient and enable activating items directly, the game is in a good state for two weeks of work. I have started work on the map that will be used in the release version of the game, ironed out the implementation details of all of the upgrades, items and drugs the player can find on the map, and fully mapped out the intro and finale scenes. The AI system is still in progress, the music and sound effects are still incomplete, I need to make the save/load system, and I have to finish the final map. I’m not sure if that is an unreasonable amount of work for two weeks, but I feel like I can do it.
I’m not super great at this whole sharing my development process thing, so I often put off or neglect updates without really thinking about it. Since I have no real following, it’s easy to do and there’s no real accountability, but I’m working on it, and hopefully I can get into the swing of making regular updates here.
