I'm not going to reveal many details yet, but I've begun working on a new game with Andrew Nare(known on teh interwebz as Sakar). You can check out his blog here.
It's a game in the same vein as a castlevania or metroid(metroidvania), but it's got some unique twists, both in gameplay and in story, which will set it apart from the mold of the genre. Oh yes, and it's being targeted mainly at mobile devices. Don't worry though! There will be a PC release as well. Stay tuned!
Thursday, July 28, 2011
Saturday, July 23, 2011
Pocket Protector Postmortem
Eight months ago I was looking towards the future with blazing excitement. Today, I look at the past with mixed feelings. I look back upon my journey, and I am ready to acknowledge the mistakes I’ve made for the sake of progress.
First and foremost, I made a huge mistake underestimating the amount of work it takes to make a cohesive experience with randomly generated dungeons. I can probably attribute 40% of my entire development time to working on the generation algorithms. Heed my advice, randomly generated environments is not an easy way out by any means. It’s like trying to tame a wild beast. You have very little control. The more control you put on it, the more same-y everything will start to feel, and the generation will become stale. The trick is finding a balance, I’ve found.
The greatest problem I had during development was a lack of direction. It might seem trivial, but choosing and sustain a direction can be hard on your own. Ideas constantly flooded into my head during development, and I was constantly inspired to try new things. It wasn’t a bad thing, but it slowed my development time by a ton. Why? At first I programmed things with one idea in mind, but then I wanted to do something I hadn’t originally intended, and I’d have to go back and hack my code to make it work with my new idea. I was doing this daily for the first 3 or 4 months. Afterwards, my code was an absolute wreck and I was nearly forced to go redo all of it.
From that, I’ve learned the true value of planning a thorough game design document. I made a 6-page plan for this game, and in the end only about 1 page of it actually ended up in my game. My design document wasn’t nearly as specific as it should have been. I didn’t consider balancing, tweaking, progression, challenge, or reward. I conceptualized characters, enemies, and environments and dabbled with some features I’d like to have. That’s not a design document. Not on it’s own, at least. A truly useful design document, I’ve learned, should contain specifics and detail the utmost details of player interaction with the game.
The importance of having such a clear document, is that then you’ll know what to program your game for. If you want to leave yourself leeway in design, such as for more weapon or enemies, then you know to do it ahead of time, instead of going back and hacking in support for that later. It’s crucial to development time to never have to take steps back. For one, taking steps back is completely demotivating and hurts your development momentum. Notes for the future!
In retrospect, one of the biggest mistakes I made was choosing a low pixel resolution to make spriting easier for me. Let’s be clear—It didn’t make it easier. It made it harder. The main character is 11x12 pixels. With some good pixel skills you can fit quite a bit of detail in there, but alas it’s still only 11x12 pixels. If I went with a much larger resolution I’d have had much more opportunity to detail my game.
Flash is a great platform for making games. It’s well suited for making nearly any 2D game. Flash is very portable, and very developer friendly. Flash game portals, however, are not developer friendly. I’ve found that they often have a very narrow view of what games they want for their sites. Which is a shame, but that won’t stop me from using Flash for commercial games in the future. I simply won’t be aiming to get my game sponsored on a game site at all.(unless it seems like it fits what game portals want)
That concludes my Pocket Protector postmortem. I guess it was fairly short, especially in respects to how long it took me to make the game. I guess that’s due to all of my trial-and-error’ing along the way. That’s a lesson in itself.
First and foremost, I made a huge mistake underestimating the amount of work it takes to make a cohesive experience with randomly generated dungeons. I can probably attribute 40% of my entire development time to working on the generation algorithms. Heed my advice, randomly generated environments is not an easy way out by any means. It’s like trying to tame a wild beast. You have very little control. The more control you put on it, the more same-y everything will start to feel, and the generation will become stale. The trick is finding a balance, I’ve found.
The greatest problem I had during development was a lack of direction. It might seem trivial, but choosing and sustain a direction can be hard on your own. Ideas constantly flooded into my head during development, and I was constantly inspired to try new things. It wasn’t a bad thing, but it slowed my development time by a ton. Why? At first I programmed things with one idea in mind, but then I wanted to do something I hadn’t originally intended, and I’d have to go back and hack my code to make it work with my new idea. I was doing this daily for the first 3 or 4 months. Afterwards, my code was an absolute wreck and I was nearly forced to go redo all of it.
From that, I’ve learned the true value of planning a thorough game design document. I made a 6-page plan for this game, and in the end only about 1 page of it actually ended up in my game. My design document wasn’t nearly as specific as it should have been. I didn’t consider balancing, tweaking, progression, challenge, or reward. I conceptualized characters, enemies, and environments and dabbled with some features I’d like to have. That’s not a design document. Not on it’s own, at least. A truly useful design document, I’ve learned, should contain specifics and detail the utmost details of player interaction with the game.
The importance of having such a clear document, is that then you’ll know what to program your game for. If you want to leave yourself leeway in design, such as for more weapon or enemies, then you know to do it ahead of time, instead of going back and hacking in support for that later. It’s crucial to development time to never have to take steps back. For one, taking steps back is completely demotivating and hurts your development momentum. Notes for the future!
In retrospect, one of the biggest mistakes I made was choosing a low pixel resolution to make spriting easier for me. Let’s be clear—It didn’t make it easier. It made it harder. The main character is 11x12 pixels. With some good pixel skills you can fit quite a bit of detail in there, but alas it’s still only 11x12 pixels. If I went with a much larger resolution I’d have had much more opportunity to detail my game.
Flash is a great platform for making games. It’s well suited for making nearly any 2D game. Flash is very portable, and very developer friendly. Flash game portals, however, are not developer friendly. I’ve found that they often have a very narrow view of what games they want for their sites. Which is a shame, but that won’t stop me from using Flash for commercial games in the future. I simply won’t be aiming to get my game sponsored on a game site at all.(unless it seems like it fits what game portals want)
That concludes my Pocket Protector postmortem. I guess it was fairly short, especially in respects to how long it took me to make the game. I guess that’s due to all of my trial-and-error’ing along the way. That’s a lesson in itself.
Wednesday, July 20, 2011
Website!
The Man In Blue Sweatshirt website is officially up!
Check it out now at http://maninbluesweatshirt.com/
And, that's not all! With this release of epic proportions, there must be game release to compliment it. Yes, Pocket Protector is now released exclusively on my website!
Coming soon: Postmortem on my eight-month journey with Pocket Protector.
Check it out now at http://maninbluesweatshirt.com/
And, that's not all! With this release of epic proportions, there must be game release to compliment it. Yes, Pocket Protector is now released exclusively on my website!
Coming soon: Postmortem on my eight-month journey with Pocket Protector.
Sunday, July 10, 2011
To the Ebay of Flash games!
Pocket Protector's testing phase is over, and I'm now officially calling the game complete. The testing helped immensely, and it led to many significant changes in the usability of my game. So, I'm really glad I took the time to do that.
Pocket is officially up for bidding at FlashGameLicense.(well, currently going through the approval process) Now the real crunch time begins!
Pocket is officially up for bidding at FlashGameLicense.(well, currently going through the approval process) Now the real crunch time begins!
Friday, July 1, 2011
Pocket Protector is almost complete!
All eight beautiful stages are complete.
The shops are full of items.
The enemies are plentiful.
And the hats are elegant as ever!
Pocket Protector, ladies and gentleman, is nearing it’s very final stages of development. It’s been a long time since I started this game, almost eight months ago, and to see it nearing completion is almost surreal. It’s a satisfying and wonderful feeling, to be honest. After all of the time I’ve spent pouring my creativity into this game, it’s almost ready to be called a product.
Here’s a fun little fact I calculated! If I were to have spent the same amount of time on this game at a day job at minimum wage, I’d have made $21,840. Even so, I don’t regret a single minute I’ve spent on this game! It’s been a wonderful creative and learning experience. That said, I am still kind of hoping to get some sort of return on this.(can you blame me?)
Anywho! I’m looking for testers now! Here’s a little criterion, but don’t let it scare you away!
- Must provide detailed first impressions
- Report any bugs found, giving as much situational information as possible.
- Give detailed suggestions to improve the game.(if you have any)
- Must explore all of the various game options and give detailed feedback on how they work both individually and as a whole.(in this case, I mean try all the weapons and spells and tell me how well they worked individually and also how well they worked in comparison with each other, same for spells, etc.)
- Provide a video of you playing, preferably for the first time. Audio is not necessary, but commentary is appreciated.
- You may not under any circumstances share this game's file with anyone else. Sure, your friend can play it, but don't go giving the game file out or uploading it to a file sharing server. I have no way to prevent you from doing this, so please just don't be a dick.
All done! It’s just here to help insure I get quality feedback. If you’re interested in testing my game, email me at jackmakesgames@gmail.com. Tell me who you are, why you’d like to test my game, and how well you’ll be able to comply with my requirements above.
Thank you!
Blue Sweatshirt signing out.
Subscribe to:
Posts (Atom)