Ludum Dare » Corporate Espionage

Corporate Espionage was my entry to Ludum Dare 35 (theme "Shapeshift") and my first Ludum Dare!

Get in, steal secrets, and get out! Use your powers of shapeshifting for some stealthy Corporate Espionage.

Sadly, but not unexpectedly, I ran out of time. So while much of the core code works, there are no win or lose conditions and thus not much in the way of "gameplay."

The reason I ran out of time seems to mostly have been that I underestimated my scope. And that I was a bit sick surely didn't help matters. Still it was definitely a fun learning experience.

Made in Unity and C#, plus Pyxel for art and level.

See link for the LD entry page and download links.

Judging has now ended and, as expected, I didn't do too well. Not terrible though for being an unfinished game. And someone else who had the same idea but better execution actually got in the top 100, so that's good.

Post-mortem

Idea - Questionable

The orignal idea was to have a game where you had to take out individuals and assume their appearance in order to sneak around where you wouldn't otherwise be allowed, in order to steal some secrets and get away with it.

I still think that this could have been a fun game, but looking back on it I think I very much underestimated how much work would be needed. In particular I think I spent way too much time getting full pathfinding and AI behaviour to work.

I could probably have ended up in a much better position by a) ditching the real-time part of it and stuck to turn-based movement, and b) ditched full AI and instead just have stationary agents or maybe simple patrols. This would have made it less of an "action" game and more of a "puzzle" kind of game. It would also have made level design (which I'm no good at) more of an issue since puzzle games must have good levels to be fun, but probably would have been worth it.

Art and Tilemaps - Success!

I'm actually really quite happy about what I did with the map. The art was made using Pyxel, which is a neat pixel and tileset editing program that I happened to already own. There are two things that made this a very good choice:

First, both tileset information and tilemap information can be easily saved to a JSON file. This made it very easy to create a Unity component to handle the details instead of having to do it by hand.

Second, Pyxel supports named layers. This made things so much easier since I could place tiles on different layers (e.g. "Floor" and "Barriers") and have the C# code do different things depending on the name (in particular see the next section regarding the barriers).

Navigation - Costly Success?

I did implement my own navigation system and A* pathing. This did allow me to do some pretty neat stuff, but the way I did it the first time turned out to be a bad idea. And fixing it took some extra time I should probably have spent doing other things.

Initially, a tile was either walkable (on the "Floor" layer) or not (on the "Wall" layer). This made some things very easy but it really didn't look very good, and made some other things a bit tricky.

In particular, I wanted a) doors, b) furniture that blocks movement but not vision, and c) walls that didn't look like they were a meter thick.

My solution was to change the navigation system to have tile be potential barriers instead of the tiles themselves. This was done quite easily by having a layer named "Barriers" in the map which had special tiles with magenta next to edges that should be unwalkable, yellow near edges that should not be walkable but "see-through" (mainly around tables), and cyan for edges that were doors. This barrier layer was then not shown, but sampled on startup to put the barriers in the right positions (though doors were ignored in the end).

Line-of-sight

Tied into the navigation system is the line-of-sight calculations, which is one of the parts I'm actually quite proud of. At first the function to check whether one tile A could see tile B was simply to step from A to B incrementally and check if a barrier was hit. This mostly worked, but wasn't really the most efficient solution. And when I scaled up and put around 100 AI agents in this turned out to be a bit of a bottleneck.

My solution was to, 30 minutes before the deadline, derive and implement a line raster algorithm to go one tile at a time from A to B. The final algorithm is quite similar to a Bresenham line algorithm.

Planning - Failure

Yeah, I never did get any real gameplay into the game. And I think part of that is because I never actually made a detailed plan for what I wanted to do. I did have a pretty clear idea of how I wanted the game to work, but programming is all about details.

As a result I every now and then ended up in a position where I wasn't sure what to do next, which I guess should have been a clue that maybe I should plan ahead more. It probably also led me to allocate my time a bit suboptimally.

Conclusion

In the end, while I did not get a full game done, I did get a really good learning experience. And while I'm sad about not finishing what I wanted, I am still happy about part of it.