Hello,

I have been watching more Game Developer Conference talks. Since I find them interesting I’ve decided to make a blog series to collect my thoughts. One of the best ways to refine your knowledge is to explain it to someone else. Naturally all of this is second hand musings on my part. I may be wrong, but that just means I’ve got another blog topic. 

Through the talks I found the four main topics I want to talk about:

• Know what scope you can handle.
• Have a well defined creative vision.
• Get feedback quickly by making a “shareable game”.
• Put your name on your game.

So without further ado let’s tackle the first point. I have bemoaned how much pain I have gone through in development hell more than once. Why? It is also a topic I have delved into before, but I believe I missed something crucial. Was it really about a failure of character or some problem with my methodology? Being obsessive and using manual testing might be reasons why I went through some bad times but I think that it isn’t the root cause. One of the first talks I watched was “No Time, No Budget, No Problem: Finishing The First Tree”. The First Tree is a game made by a single artist, which he managed to ship by working on his game at night for months. He used a lot of assets from the asset store, though with many of the art assets he tweaked them. Most of his code however was stitching together asset store packages - his game’s architect would have essentially been held together by duct tape. To be clear, I am not looking down on him. He successfully executed his artistic vision and was kind enough to share his experiences. So why did he ship his game and Illic is still in development? It is simple: he fixed his scope and made a deadline to finish. The First Tree is only a couple of hours long and doesn’t have a lot of complex mechanics. It is not just him - another GDC talk about being a solo developer which had a similar message from three separate solo developers. During that talk one of the developers had made a specific point about locking the scope down. He decided from the outset he wouldn’t have an inventory system for instance. That particular line reminded me of when I decided I needed Illic to be more “gamey” and brazenly implemented an inventory system poorly. Most of the work the last couple of years has been centred around fixing the integration of the inventory system with the rest of the game. I think he might have been onto something.

So why is fixing scope so important? Dave Farely’s Continuous Delivery has a great video on that topic in relation to CyberPunk. (The video which really got me into his channel). In the video he explains how the triangle of constraints (time, cost, scope/quality) falls apart for software. I’ve listened to Adam Savage talk about using it when bidding how much a client has to pay for a commissioned prop and it makes some sense in that context. It is easy to imagine someone making a lower quality prop faster, or a more complicated / higher quality prop taking longer. What about software though? Low quality software takes longer to make. Defects slow you down far more than the speed you gain by going “faster”. Besides, I don’t know about you but I avoid buying games with floods of bad reviews due to technical issues - cyberpunk included. So our calculation is now, how many people and how much they all cost and scope of course. While the games industry may be rife with crunching it just lowers productivity. Coding is all about solving complex abstract problems - something very hard to do even decently when exhausted. So maybe you want a bigger team? Except the bigger the team is the harder to manage (and afford in the first place). All you have left is… you guessed it: scope. It makes sense. A game on steam and a game jam game might be both fun, but the scope of them is profoundly different. No one is going to think they can make the next Elden Ring in a weekend. Similarly if you keep on moving the goalposts of “finished” you will never finish. There is always room to improve or to grow. If you don’t limit scope you won’t ever finish - a recursive algorithm with no exit condition.

Which is perhaps just another way of saying “haste makes waste” and “don’t bite off more than you can chew.” Which reminds me of something funny. Initially I scoped Illic very well. After all, I finished the original version of the game in my last year of study, where I was working too much on Poppy in Paintland AND I also had a VR internship at SA Power Networks. I had art, 3d models and most of the main mechanics of the game implemented by the end of that year. After I graduated I could have started a new project/s and used the experience from Illic to make something with a different better game. I could have also worked to polish it as much as it could within the framework I had created. If I had continued to manage the scope I could have created a lot more or at least a lot more hours of gameplay. All without actually developing fundamentally better workflows. To be honest I don’t like the idea. I wish the journey could have been a bit easier but I am glad I stuck with Illic.

Tune in next time for my second point in this series of blog entries. I’ll be focusing on the second point about “vision”.

Until next time.