Roxy's Quest mini post-mortem and goals going forward
Hi gang, wall of text incoming!
I’m far from a regular game developer like most of you here, but last year I completed my first game, Roxy’s Quest, which was made for NAG as a part of our rAge offering. It was more than just a marketing exercise, though, it was a personal challenge – can I make a game in three months that I’d be proud to show to 30,000 people? In short, I wanted to make a game and having the backing of NAG just made it a little easier. Sort of.
I completed Roxy’s Quest in three months of development, with about a month up front for pre-production (more like learning the tools, really). All game design and programming was done by me using Construct 2, and all of the artwork was done by Toon 53 Productions.
I learnt a lot from Roxy’s Quest, and now that I’m gearing up to get started on a sequel, I thought it’d be a good time to write down a few lessons that I learnt, plot out some goals going forward, and get some feedback from the community on anything they feel like sharing. If you'd like to take the time to play Roxy's Quest, here's a download link [61MB, installer]. It's around 15-25 minutes long. I bet there are still some bugs lurking about but I'm no longer working on the game, although I'd welcome any feedback on the gameplay for my own personal notes going forward.
Screenshots:
Link to gameplay video.
Quick controls: Up, down, left, right to aim/run. Space to jump. Z for primary attack (blaster pistol). X for secondary attack (any weapon you pick up).
Anyway, on with the things I learnt:
1) Plan artwork right from the start. The artwork had a hand in dictating gameplay, which was not what I wanted. I struggled to get the isometric (or whatever) art to work with certain gameplay mechanics that I had prototyped, and in the end it was easier and quicker for me to simply scrap some of those mechanics in favour of having pretty art. This leads me to my next point:
2) Communication is vitally important when working with other people. The artists we commissioned were incredible as both directors and creators, but the back and forth we shared for those three months took its toll on every aspect of the game. Far too much of what I had considered to be production time was spent figuring things out.
3) Pre-production: I didn’t spend enough time doing this. I prototyped for about a month before things really got underway, but so much of that actual code was thrown away (the techniques I learnt obviously weren’t, at least).
4) The highway level was a mistake. I wanted to include it as a throwback to beat-‘em-ups but in reality it was just a huge timesink for what I think is ultimately the least enjoyable part of the game.
5) Audio takes a long time. I spend days scrounging through public domain and Creative Commons music and sound effects. I need to budget more time for this in future.
6) Polish and bug-fixing makes the difference between an okay game and a great one. The game felt good at about 70%, but I’m glad that I spent the time putting in little visual effects and cleaning up bugs even at the last minute.
7) Build a robust control scheme. The controls in RQ were cobbled together throughout the time I spent working on it and are the biggest giveaways of my lack of experience. Tying in player controls with animations, collision checks and audio means designing a control scheme that takes all of these things into account right from the start. Eventually I actually had to scrap an entire attack because it was causing a memory leak, and I didn’t have time to fix it (this was on the Saturday morning at the show).
8 ) Public feedback is important. Roxy’s Quest was a weird one for me because, even though I’ve been in touch with so many community members for the last year, I didn’t want feedback. I chose to develop in isolation because I was intimidated by the prospect of being bombarded with input. This is probably the biggest challenge I faced because I knew that the way I chose to make this game would result in it being not as good as I wanted it to be, but I had to "get it done". Wrong mindset? Maybe. Probably.
So, lots of stuff. My goals going forward with Roxy’s Quest 2:
1) More strategic variety for the player in terms of both weapons and level traversal. RQ1 was too simple. Not bad simple, just simpler than I had initially planned. Because so much was dropped during development based on artwork and time, I want to ensure that these features make the cut this time.
2) A second character. I’ve been struggling with ideas of how to include a second character and I might even drop it altogether. It’s an important part of the storyline so I want to do something, but at the moment everything I’ve prototyped has either been beyond my technical abilities, or has seemed like it just added fluff instead of some real bulk to the game.
3) Smarter enemies. The enemies in RQ1 are dumb as bricks. I need to spend time developing at least decent AI for everyone.
4) Puzzles. Nothing too heavy, but I’ve always enjoyed platformers that have simple puzzle elements, and I want to bring that across to RQ2.
5) An actual story, with game levels and mechanisms that make sense in the context.
6) Better use of artwork. This comes back to the “planning for artwork” thing. Really, it comes down to experience, or my lack thereof. Really looking forward to making RQ2 look incredible.
7) Spend more time on the game. This is probably the biggest thing, because starting with pre-production now means I'll have, like, twice as long to actually make the game. Still not a lot of time, granted, but I think it's enough to significantly improve the quality of the sequel in relation to RQ1, and even get some more game time out of it.
I'm going to continue using Construct because I know it well-ish now (quirks and all), and we're already chatting with Toon 53 to come back on board.
Phew, thanks for reading!
I’m far from a regular game developer like most of you here, but last year I completed my first game, Roxy’s Quest, which was made for NAG as a part of our rAge offering. It was more than just a marketing exercise, though, it was a personal challenge – can I make a game in three months that I’d be proud to show to 30,000 people? In short, I wanted to make a game and having the backing of NAG just made it a little easier. Sort of.
I completed Roxy’s Quest in three months of development, with about a month up front for pre-production (more like learning the tools, really). All game design and programming was done by me using Construct 2, and all of the artwork was done by Toon 53 Productions.
I learnt a lot from Roxy’s Quest, and now that I’m gearing up to get started on a sequel, I thought it’d be a good time to write down a few lessons that I learnt, plot out some goals going forward, and get some feedback from the community on anything they feel like sharing. If you'd like to take the time to play Roxy's Quest, here's a download link [61MB, installer]. It's around 15-25 minutes long. I bet there are still some bugs lurking about but I'm no longer working on the game, although I'd welcome any feedback on the gameplay for my own personal notes going forward.
Screenshots:
Link to gameplay video.
Quick controls: Up, down, left, right to aim/run. Space to jump. Z for primary attack (blaster pistol). X for secondary attack (any weapon you pick up).
Anyway, on with the things I learnt:
1) Plan artwork right from the start. The artwork had a hand in dictating gameplay, which was not what I wanted. I struggled to get the isometric (or whatever) art to work with certain gameplay mechanics that I had prototyped, and in the end it was easier and quicker for me to simply scrap some of those mechanics in favour of having pretty art. This leads me to my next point:
2) Communication is vitally important when working with other people. The artists we commissioned were incredible as both directors and creators, but the back and forth we shared for those three months took its toll on every aspect of the game. Far too much of what I had considered to be production time was spent figuring things out.
3) Pre-production: I didn’t spend enough time doing this. I prototyped for about a month before things really got underway, but so much of that actual code was thrown away (the techniques I learnt obviously weren’t, at least).
4) The highway level was a mistake. I wanted to include it as a throwback to beat-‘em-ups but in reality it was just a huge timesink for what I think is ultimately the least enjoyable part of the game.
5) Audio takes a long time. I spend days scrounging through public domain and Creative Commons music and sound effects. I need to budget more time for this in future.
6) Polish and bug-fixing makes the difference between an okay game and a great one. The game felt good at about 70%, but I’m glad that I spent the time putting in little visual effects and cleaning up bugs even at the last minute.
7) Build a robust control scheme. The controls in RQ were cobbled together throughout the time I spent working on it and are the biggest giveaways of my lack of experience. Tying in player controls with animations, collision checks and audio means designing a control scheme that takes all of these things into account right from the start. Eventually I actually had to scrap an entire attack because it was causing a memory leak, and I didn’t have time to fix it (this was on the Saturday morning at the show).
8 ) Public feedback is important. Roxy’s Quest was a weird one for me because, even though I’ve been in touch with so many community members for the last year, I didn’t want feedback. I chose to develop in isolation because I was intimidated by the prospect of being bombarded with input. This is probably the biggest challenge I faced because I knew that the way I chose to make this game would result in it being not as good as I wanted it to be, but I had to "get it done". Wrong mindset? Maybe. Probably.
So, lots of stuff. My goals going forward with Roxy’s Quest 2:
1) More strategic variety for the player in terms of both weapons and level traversal. RQ1 was too simple. Not bad simple, just simpler than I had initially planned. Because so much was dropped during development based on artwork and time, I want to ensure that these features make the cut this time.
2) A second character. I’ve been struggling with ideas of how to include a second character and I might even drop it altogether. It’s an important part of the storyline so I want to do something, but at the moment everything I’ve prototyped has either been beyond my technical abilities, or has seemed like it just added fluff instead of some real bulk to the game.
3) Smarter enemies. The enemies in RQ1 are dumb as bricks. I need to spend time developing at least decent AI for everyone.
4) Puzzles. Nothing too heavy, but I’ve always enjoyed platformers that have simple puzzle elements, and I want to bring that across to RQ2.
5) An actual story, with game levels and mechanisms that make sense in the context.
6) Better use of artwork. This comes back to the “planning for artwork” thing. Really, it comes down to experience, or my lack thereof. Really looking forward to making RQ2 look incredible.
7) Spend more time on the game. This is probably the biggest thing, because starting with pre-production now means I'll have, like, twice as long to actually make the game. Still not a lot of time, granted, but I think it's enough to significantly improve the quality of the sequel in relation to RQ1, and even get some more game time out of it.
I'm going to continue using Construct because I know it well-ish now (quirks and all), and we're already chatting with Toon 53 to come back on board.
Phew, thanks for reading!
Comments
So, point: Temp graphics save you so much time and effort.
Building stuff with temp graphics will solve so many of your graphics/planning related issues in the second game. For serials... Firstly, having temp graphics that don't get in your way while you're building the code that makes the game work is crazy useful. It means you won't get stuck having to use something because it looks good, you'll be able to build systems and animations the way you want them to feel without worrying about invalidating existing art, etc.
Secondly, temp art is easy to replace. That means that you can not only tell your art production team EXACTLY what you need: "This animation is 4 frames long, stretches to 200px width max and 80px width at the start, then back to a rest position of 120px, must integrate with weapon state alpha, blah blah, fishpaste" But they'll also be able to give you stuff in the right format much easier, you hand over the sprite-sheet or texture or whatever the way it is now, they see how that looks ingame currently and then just replace the thing as they're working on it to see it change ingame.
Finally, temp art allows you to manage better. If you know exactly how much art you need from your prototyping phase, each piece with exact instructions and guidelines like above, you can budget time a lot more efficiently and make decisions about what to cut much easier. Plus you can de-couple your code and gameplay production from asset production and not have that waiting on integration feedback to slow both down.
Hope that's a useful tip, has made a ton of difference in the time-strapped projects we used to work on.
First game? Surely you did other stuff in the Game.Dev days? Am I misremembering? Regardless, I've played the game, and it's really not too shabby at all for a supposedly first effort. Seriously. I think the only main issues I had gameplay-wise (that you haven't already pointed out) were occasional control dodginess that didn't allow me to quickly reverse directions when running, and the fact that those smoke flare things didn't look inherently dangerous, had an unclear area of effect, and didn't give enough of a window to be avoided when fired from alien ships. I probably died more from those than anything else. :P
Regardless, it's really pretty solid, all things considered. It'll be pretty cool to see what you come up with this year now that you have a handle on your tools and workflows. :D
Also, yes, feedback. Definitely a big thing going forward. I could practically hear you telling me every time I didn't post about RQ on these forums :P
@Gazza_N, I've played around with some dev before - prototyping, mostly - but this is the first game that I've actually completed. I also did work with another chap on a Game.Dev competition submission (we even won a bit of cash when we came third), but I only did the art for that.
Yeah man, those flare things - I had a number of complaints about them. I initially put them in to create a bit more challenge for the player, and I think the idea is probably right, but the execution needed a lot of refinement.
A few notes:
- The one thinq that I would really like is for shooting to be a bit more dramatic - more sound, and also sounds on impact. It will make shooting monsters down more fun; make me feel more powerful. (And let me know if I hit!)
- I'm not so sure that the fading-on-death for monsters work so well. I keep stopping not sure whether they are still alive for a split second; it really breaks my flow.
- Nit-pick: I don't like shooting some monsters so close to the top of their heads; it feels like I will miss.
Overall, I like it, and I think you did a good job given the time-constraint.