I'm glad we were able to spend this time together, even though you'll just leave like everyone else
I'm glad we were able to spend this time together, even though you'll just leave like everyone else
I’ll be completely honest here: around two years ago, when I first decided that I was going to start making my first game, The Many Deaths of Lily Kosen, I had no idea what I was in for. Sure, I knew that it was going to be work, and that I’d have to spend money on it if I wanted it to be good, but there were so many more things around it that I didn’t consider. I think that my initial timeline estimate was completing the game within about six months which, yeah, talk about overambitious.
In spite of my arguably quixotic goal, I did manage to get through all of the hurdles of development and publishing, even if at times it felt as though I wouldn’t be able to. Here are some things that I learned along the way which might not be obvious - if you’re looking to make your own game, hopefully they’ll help you.
The Many Deaths of Lily Kosen is a visual novel, so broadly speaking, I had three things I needed in order to program it - a script, images, and sounds. The script was easy, since I knew that I’d be writing it all myself, but images and sounds were things that I was going to need to outsource. For an early prototype of the game, I drew up images myself or used stock backgrounds, and similarly used music ripped from game OSTs for placeholders. This was all fine, as doing so helped me work out what I’d need in the final product and whether there was anything else I needed that I hadn’t covered in my notes. Whether you’re making a 2D or 3D game, placeholder assets are a useful tool to use.
The problem that happened to me was that even though I’d used my placeholder assets to confirm what I needed and what suited the mood of the game, I then dragged my feet when it came to progress towards the final assets needed. It took me months before I started looking up artists to commission for the sprites, who then of course needed time to actually make the sprites. Instead of learning from this and immediately sorting out my remaining assets, I continued to drag my feet, taking time between commissioning each asset type.
What this meant, of course, was that even though my script was pretty much finished and I could program it in, there was a long time between that stage and being able to put out a demo, simply because I had to wait for so many assets to be completed. Overall, it’s hard to say exactly how much time was lost due to this, but I’d estimate it to be at least three to six months? The smarter thing would have been to commission everything early on and work in parallel at the same time, but instead my own nonsensical decision added in a massive delay to when the game and it’s demo could have released. Time issues aside, sorting out your assets early on helps with the next tip.
Look, I don’t care how cool the new feature for your game that you suddenly thought of last night is: cut it out, and save it for your next game. If you try and fit it into your game, whatever benefits you get from it will be massively offset by the time and development costs implementing it. It’s not going to be something that’s added in a vacuum - you’ll now need to balance existing mechanics, make sure that it doesn’t break any parts of the game, and potentially even change the story of your game to explain or accommodate it.
Putting aside the excess time and money that will be added when you try and add in new features for the moment, here’s a little secret about game development that you might not be aware of: you’re going to have scope creep whether you want to or not. You’ll have to fix bugs that you thought you’d stamped out, you’ll realise midway through developing something that it can’t actually be done in as elegant a way as you initially thought, and you’ll suddenly find that some things you’d planned for need more coding than you initially realised. This is going to happen, and there’s not much you can do about it. Why would you want to add to that?
My advice for this sort of thing is to work everything out at the start - see what mechanics (or story beats, or whatever) you want and are happy with, and test coding simple versions of them to see whether they’re viable. If they are then focus on them, and as mentioned above, save them for your next game. This is also where sorting out assets early helps a lot - when you’ve got all of your assets completed, you’re not tempted to suddenly add in a new character or level, since that would mean waiting for more assets. As a bonus to all of this, working within these limits will help creativity as you work out all of the ways to use what you’ve got, creating additional depth and flexibility.
You know what’s genuinely awesome? Having a concept for a game that you’re so sincerely enthusiastic and passionate about that you need to make it, regardless of how long it might take or how difficult it will be. You know what’s less awesome? The realisation that you - or your team - will have to be the one(s) to make the entire thing from scratch. You need to come up with the entire story, work out all of the mechanics and how they fit together, work out what assets are needed, program it all, promote it, set up a platform to sell it through, fix bugs, address feedback, explain it to people - and that’s only some of the list you’ll be working through. If it sounds like a lot, it’s because it is.
If you’re planning to stay sane throughout the whole process, there’s one thing that will help a lot - passion and genuine love for your project. Knowing what the end result will look like and seriously wanting to bring that into the world will help keep you motivated and let you push through the tougher bits. It’ll be what gets you sacrificing free time to stick to a development schedule, what drives you to improve and iterate weaker parts of your project, and will make the end result all worth it.
On the other hand, if you’re not passionate about your project - if you’re just trying to jump onto a trend, or you’re not entirely pleased with your concept - then that’ll affect you, and it’ll show in the work. You’ll find yourself taking shortcuts in places that you shouldn’t, you won’t be able to show people why your game is deserving of their attention, and you might even end up scrapping the entire thing before the end. If you want to make a game, you had better be passionate about your idea, because without passion you won’t have a good end product.
This tip isn’t going to be applicable to everyone - larger teams in particular - but it’s something that I think is worth bringing up. If you’ve had an idea for a game and you’re passionate enough about it to actually start making it, there’s probably one or two things involved in it that you’re excited about and are helping to drive development. Maybe you’re keen to write an involved story, or to program in an exciting combat system. Maybe you’re looking forwards to working with an interesting art style, or composing a bombastic soundtrack. Whatever it is, you’ve probably got at least one or two things that you’re looking forwards to doing, otherwise you wouldn’t be on the project.
Game development will involve doing plenty of things you love, sure, but it’s also going to involve doing plenty that you didn’t even think about before starting. I had a fun afternoon trying to come up with a description of The Many Deaths of Lily Kosen for the Steam page, as well as resizing and cropping images to meet Steam’s requirements for listing a game on the store. I also had to promote the game on social media, design and style the majority of the game’s interface, work out how to explain what I was looking for to artists as elegantly as possible…there were a lot of things to do, when all that I really wanted to focus on was writing and programming.
Still though, as much as I didn’t enjoy some aspects of publishing the game, they had to be done, and I’d do them all again for another game. Be aware of what you’ll need to do, and that you might have to wear a few different hats during the development process, because if you can’t, your game might never be finished.
“Oh, that makes sense; I was thinking that getting bad feedback would be the solution here,” said no one ever. Yeah, it’s a bit of a vague tip, so let me elaborate on it a bit - ultimately, the point of feedback is to work out what the quality of your project is like using a third-person perspective. When someone finishes playing your game and they tell you that “it was alright”, or they say they liked something but can’t elaborate on why, it’s difficult to know whether you’ve actually done a good job or not.
Before sending your game off for playtesting, note the areas that you’ve got the most concern about or want detailed information about. Let your players know that you value their feedback in those areas, and ask them specific questions about what their opinion is. Sometimes it’s hard for people to identify what makes them feel a certain way, so a bit of prompting can help with it.
Something else to take note of when it comes to feedback is that it’s possible for you to get feedback that’s completely irrelevant. If someone says, “The combat is too fast and I couldn’t get the hang of it,” when a fast-paced action game is exactly what you’re going for, it probably won’t hurt to ask some further questions, but a player like that probably isn’t your audience. On the other hand, if that’s the feedback you get when you’re trying to make a faux-Mario platformer, you’re probably going to need to change some things around.
Hopefully these five tips will help you out wherever you are in the game-making process, whether you’re just thinking about making a game or you’ve already had several completed and published. If they have, then please let me know, and if not, then let me know what I can do better next time! Making games as an indie dev can be pretty tough, so I’m always happy to lend a helping hand and give advice when able.
Back to news
