Lacuna Passage - Devlog #13 - The mundane side of game development

I really struggled to come up with a topic for a devlog this week. I feared that I might have to skip a week for the first time since I started writing devlogs for Lacuna Passage. Despite lots of game-related work that I had been doing I didn’t think that any of it was interesting enough to show off. A few people suggested, “Why not write a post explaining the mundane stuff?”. So you can thank those people for this devlog... hopefully it gives you some insight into the less-than-glamorous aspects of developing Lacuna Passage.

Managing a Team

The sad fact of team development is that someone inevitably has to spend time “managing” the team which detracts from the amount of time they can spend actually developing the game. This means finding reference images for concept artists and modelers, critiquing finished work, assigning new work, and documenting art pipeline specifics. Believe it or not, team management requires more than just poking your head into a room and telling someone to “tighten up the graphics on level 3”.

Google Drive is a lifesaver when it comes to communicating with your team. There is no better way that I have found to share and collaborate on important documents. All of our story and art pipeline documentation is shared via Google Drive.


Another great tool for team management is Trello. If you haven’t heard of it I highly suggest you check it out. It is essentially an advanced to-do list. You can assign team members to tasks, set due dates, attach files and screenshots, and leave comments and feedback. It’s seriously great. Even if you work alone it is perfect for keeping yourself on task.

Managing Assets

When I tell people I make video games in my free time I highly doubt they picture me spending 4 hours on a Saturday night converting image formats and adding new filename prefixes. But that’s exactly what happens more often than many developers would care to admit.

The allure of quickly throwing assets into your game “just to see how they look” can be strong, but you must resist the urge. Haphazardly importing BigAwesomeRock_07, MoreBigAwesomeRock_07_new, and SeriouslyThisIsTheFinalBigAwesomeRock_07_morenew will turn your folder structure into a wasteland of assets that have you scratching your head. Sometimes I wonder what the ratio of asset production to asset management is, but I know it’s much higher than most people think (or at least it should be). I spend a lot of time ensuring that there are backups of all our files and that all those files are properly labeled according to our naming conventions (which are conveniently available for reference in a Google doc).

When an asset is finally imported into the game I make sure that it has been properly checked for quality and conforms to our import settings for scale, etc. On the (hopefully rare) occasion that an in-game asset needs to be replaced it’s a good idea to make sure that both the old and new versions are backed up in a separate folder. Once the new version of the asset is imported into your game’s working project folder you want to be sure and delete the old file so that you never use the incorrect version by mistake. It will always be in your backup files if you need to return to it.

This process of keeping your game assets properly organized can be tedious and extremely repetitive, but in the end you will be glad you had the forethought. You might have a firm mental grasp on your folder structure when your game only has a few dozen assets, but before you know it you will be swimming in hundreds of messy files.



I’m not sure if I can even conceive of a more annoying aspect of game development. If someone asked me how I spent last Friday evening this would be how the conversation would go:

“Hey Tyler, so you’re still working on that game of yours huh? What did you accomplish recently?”

“Oh, well just the other day I was trying to get the image loading code for the in-game digital camera working and I couldn’t figure out what I was doing wrong. After hours of pouring over my code I realized I forgot to capitalize a letter. If there was a baby nearby at the time I would have punched it.”

Absolutely infuriating. Though I suppose I should mention that I am not a trained programmer and everything I do in code is extremely amatuer (I mostly work in Playmaker), but the stories I hear from close friends who have been programming for years are fairly similar. Bugs and code errors are the bane of the game developer’s existence.



Email, Twitter, Facebook, YouTube, Reddit, Screenshot Saturdays, press kits, Indie DB, and yes - Devlogs. I actually really enjoy promoting Lacuna Passage. It’s great to see people’s reactions to all your hard work, but it really takes a lot of time and effort to do it right. After all, even if you have the greatest game in the world it doesn’t really matter if no one knows it exists.

Just last week I spent nearly three days putting together a press kit for the game so that we have an easy place for journalists to find the latest info. That’s three days that I would love to have back for improving the game, but it’s just another necessary part of the process.

After a full day of work at my 9-5 job I come home to manage team assignments, manage new assets, hunt through the previous day’s progress for bugs, do some quick rounds of promotion, and maybe - just maybe - I will have time to get some real development done. All of this I do without the promise of any pay or reward, because there isn’t anything I would rather be doing. I make games and this is what it takes.