Thursday, December 13, 2012

One Game A Month

Inspiration hit me for a new game idea. This one is beautifully small, simple and effective, and will only take about a week to make. This makes it a perfect candidate for @McFunkypants one game a month challenge! While I could use free art and free music, the game would definitely be better if an artist and musician worked with me on it. So I figured, what better way to get to know some new people than working on a short, interesting project? So I am currently looking for one artist and one musician to help me out - if we enjoy working together, then we could consider working together on future projects after this. Production on the game will not start until January, but I'm looking for team members now so I can get to know you before we start! Interested? Below I have some details about the game:

The game is a first person "horror" game. I put horror in quotes as it is more eerie than in your face scary, there are no enemies, and nothing jumps out at you, the scary part is more subtle than that. While the game is first person and 3D (and will be made in stage3D), no 3D modeling is required for this project, as it will be generated from maze-like walls and floors similar to older raycasting games (lands of lore, wolfenstein, etc). The art needed is for wall, ceiling and floor tile textures.

The premise of the game is that the player falls down a pit into a dungeon/basement, and they need to find an exit. The game focuses mainly on exploration, and has one interesting mechanic that I wont spoil publicly. This mechanic complements the exploration core nicely, and creates the eerieness of the game (along with the art and music, of course). There are also pits in the main game that drop the player to a lower level of the dungeon.

The art requirements are drawing 128x128 pixel wall (including doors), floor (including pits) and ceiling (including pits from above) tiles. You can certainly base them off of free textures and modify them or make them from scratch. The tiles will allow gif-style transparency, meaning you don't have an alpha channel, but you can have holes in the walls (or bars which you can see through the gaps). The art style will be up to you, but the general idea is that they get creepier as the player gets deeper into the dungeon. This is only a week project, but variations on the walls will be nice to break up the monotony, any artists should be confident that they could draw a few tiles with many modifications every day.

For the composer, the same general idea is true - we need the music to get creepier the deeper the player gets. This can be done with several songs, or one song with an overlay track that I can fade the volume in to increase the "eeriness." The music style will be up to you, as long as it fits the general theme "eerie." If you can do sound effects (doors opening, falling through pits), that's a bonus, if not, we can get sound effects free online or I could ask one of my Fancy Fish Games team-members.

The goal of this game is mainly for fun and the experience, as well as getting a chance to work together and implement a pretty cool idea (you still don't know the simple mechanic, you'll have to trust me on this!) If you're interested or have questions, reply with a comment or send me an email: davidmaletz at!

Friday, December 7, 2012


Do you ever get the desire to go through your old work and see what you've done and how you've progressed? Have you ever spent time fixing up old prototypes and having fun playing them? The past few days, I had the sudden urge to do just this, and spent a couple hours every day looking through, organizing and playing my old games.

A few things that surprised me:

  1. The quantity of my prototypes, most of which were for testing out ideas that were never fully fleshed out. I have 15 flash prototypes, 11 java prototypes, 9 haxe prototypes, 2 javascript prototypes and 2 C++ prototypes, not including non-game utilities and other interesting bits of code (also not including my older PHP, rpgmaker and qbasic games). That's a LOT of prototypes! Imagine if each one was made into a full game (even something simple for a game jam).
  2. Most of these games died out before they had actual art/ui (yay programmer art). Sure, a lot of them died out "survival of the fittest" style, meaning that the ones that were fun were continued, and the ones that weren't were trashed. But quite a few of the prototypes died out simply because the artist working on it decided to drop the project (even when the artist suggested the prototype in the first place). I have a few interesting but ugly prototypes that never got the time of day they deserved (the best of which I have put into the "In Planning" section of my Games page.
  3. How quickly old code becomes incompatible with new operating systems. Obviously, the C++ ones would have issues, but the other programming languages are cross platform and I would've expected them to work out of the box. This was true for flash (have to give it credit there), haxe doesn't apply as those are all new prototypes, but several of the java prototypes could not run because of issues with JOGL or some strange dependency that made it not work on a 64-bit operating system. Having a 32-bit AND a 64-bit version of Java installed on my machine doesn't help the issue.
In any case, I have successfully looked through old prototypes and ideas, updated and organized my games page: , and decided to make several of my games playable there. I didn't upload the less polished/buggy prototypes as I'm a little embarrassed of them, but just send me an email if you want to try some. Don't say I didn't warn you!

Games now playable:

Assembler Quest (2005) - a first person RPG written entirely in x86 assembly... for those of you who know what that is... yes, I was crazy. Packaged it with dosbox so that it could be playable on newer computers. Dosbox also makes it playable on non-windows OS with a little work, Tim got it working on a mac, see screenshots here:
DayBreak (2010) - My first flash game (not including prototypes), trying to make something small and interesting. Never finished, but it is more or less playable here: (link) . Yes, catgame was the codename for this project!
Ilk Cardgame (2008) - a computer version of a cardgame I invented, with rules similar to M:TG except playable with a normal deck of cards. Finished BETA (fixed up some problems with JOGL, it now works on windows and "probably" works on other platforms - it still has some rare bugs with the AI and networking, but is playable). (link)

Games Previously Playable:

Drawscape (2012) - Drawscape is a physics platformer where you draw shapes to overcome many challenges and puzzles. Play through 22 unique levels as Kami, a curious fox girl with the power to create and destroy. Here's a video of the gameplay: (link)
Previously playable only at Kneoworld, I have now made a dev version of the game available here: (link)
Deus Shift (2011-2012) - A strategic flash game. Was originally Arcane Lands, which was completely redesigned  and released as Deus Shift (and is now being completely redesigned again! (link)
Shadow of Time 4 (2008) - a parody RPG written entirely in javascript... not html5... (link)

Monday, December 3, 2012

The Dark Side of Indie Game Dev

The indie game dev scene is filled with starry eyed, optimistic developers hoping to make the game of their dreams. Recently I've read several articles trying to discourage them and make it clear that there is a dark, difficult side to game dev. And I won't lie - game development is not easy, and has many snags along the way. In this blog post, I will list some of the snags I have found over five years, without sugarcoating anything. It may be harsh - it may sound like I'm saying "you're crazy to want to make games!" However, this blog post is not particularly to discourage you from game dev. Instead, it is here so that you can learn from a game developer who has had more failures than successes, and perhaps avoid or deal with some of the common pitfalls that game developers face.

You are likely to fail. Especially your first time.
You've probably heard this before, but the vast majority of indie game developers fail to finish their game projects. For every success story you hear, there are literally thousands of failures you have probably never heard of. Since you're an indie game dev, you are probably an optimist, so you might think it will be different for you - that you'll be one of the rare few who succeed. This is false, and only by accepting the fact that you are likely to fail can you put in the extra effort and trample over failed games to eventually reach success.

Game development is only fun ~10% of the time.
You have a great idea that you are excited about. Awesome. Starting the project is fun and new, and everything seems smooth sailing. This will not last throughout the whole project. The simple fact is, games take a lot of work, and not all of it is fun. At some point during development, especially if it is a long development, you will grow tired of the idea and the work, and some new idea will come up. The idea will seem so much better that you will want to drop your current project and start that new idea immediately, however, think carefully before you do this. You thought the current idea was as amazing when you started, and likely if you switch projects, the same thing will happen, and you'll just end up with several unfinished projects. Try to remember what made your original idea so exciting, and try to stick with it. While sometimes you do have to drop a project because it's not working out, more often you are just getting tired of the current project and want to start something new. Take a break, get some fresh air, and really think about your project, and your ultimate goals in making it. You'll probably find that you were just frustrated with some aspect of it, and you still really want to finish it.

Game development takes at least twice as much time as you expect.
After five years, I've become pretty good at estimating how long games will take to make. I have a simple formula for determining this: decide how long the project will take. Now double the estimate. That is the actual time the project will take. The fact is, there will ALWAYS be something that you do not expect during game development. Some feature, some bug, some design flaw, something that you overlooked when estimating the development time. Even professional games are almost always over time and over budget, which is the cause of the much hated "crunch time." Don't let this catch you unawares, expect the unexpected, and pad the development time, especially if you are inexperienced. One of my earlier games that I thought would only take me one month ended up taking me over a year (no joke). And nothing kills motivation more than a game taking much longer than you expected - just like with the above point, you start to get frustrated and tired. So, assume your estimate is optimistic, and give yourself extra time. If the game project sounds like it will be too long, don't just shrink the time estimate, try actually cutting features.

Feature bloat - it happens.
Just as you get ideas for new games to distract you, you also get ideas for new features for your current game. If you're not careful, the game can bloat to several times its size during the development process, perhaps becoming insurmountable. Some amount of feature bloat is unavoidable as you find gaps in the game design that must be filled, but always try to "keep it simple, stupid" (KISS - a very important acronym for all developers to remember). The simplest form of a project can be just as great as something heaping with features.

If you're working with a team, an argument will occur.
Even if you're working with close friends, everyone will have different opinions, and arguments will occur, especially when the game hits a snag. If you are not talented at leading a team or you're working with people you don't know and trust, this could destroy your team. I strongly recommend listening, something I still haven't learned perfectly. Listen to your team, and try to keep discussions calm and productive - even if there is some major crisis going on with the game. Again, take a breather if you need to. And, always make sure you build trust among your team, so that when an argument DOES occur despite all your efforts to stop it, you are able to work through it without anything falling apart.

There WILL be bugs!
Don't kid yourself thinking that you write perfect code. There will be bugs, and more. Games need a lot of playtesting, debugging, and polishing before they are ready to release. A good game with bugs or a bad UI will be unplayable. If the development of the game takes a month, then you'll most likely need another month for playtesting, debugging and polishing. And this stacks with the "game development takes twice as much time as you expect" rule, so that means that what you originally thought would be a one month game will likely take four months to make! However, don't skimp on debugging and polishing just because you are overtime or don't enjoy it, as it can make a huge difference for the game. For example, the average sponsorship price for one of my games (Drawscape) went up four times from just the polish and debugging! Twice the work yielding four times the reward (or more)!

Even if you finish the game, it might still die.
The completion of the game isn't the end of the project - some would say it's only the beginning. You finish the game, post it online, and maybe a few people play it. It might even get a bad rating. Why didn't it get the amazing reception you dreamed it would? Unfortunately, you can't just have a good game, you have to have good marketing as well! You need to network, have a great website, and market, market, market! Random strangers on game portals will not give your game much of a chance, especially if it already has a low rating - they may play for 30 seconds or a minute and not see what makes your game truly special. You need to have a following who really play your game and spread the word, and press contacts who will review it and encourage strangers to really play it. You need to "sell" the game to the public (even if it's a free game). It's also possible that your target audience is very niche. There's not much you can do about that except try to help that niche find your game, and move onto your next project.

Many projects will fail.
You will have abandoned projects, incomplete projects, and projects that were released and not well received. The fact is, not every game you make will be a big hit - especially your first few projects. I've finished five games (with many more incomplete), and I only consider one of them a "success" (and even that one was by no means a big hit). You can't assume your game idea is so great that it will "make itself" and instantly succeed. You have to be prepared for tough times, roadblocks, failure, failure, and more failure if you want to have any chance at eventual success.

Have I discouraged you from making games? Then don't make games. If just me (or anyone else) telling you not to make games keeps you from making them, then you're not cut out for it. There is an interesting story about this called the violin prodigy story: . If you truly have the burning passion to make games, then don't let anyone else discourage you from making them, and use failures and negative game dev stories as examples to learn from. If you don't have the passion, then you might want to consider doing something else. I love game development and wouldn't prefer doing anything else, but it often seems like any other kind of programming work (corporate apps, etc) would make me a lot more money than game development does. But game development is not about making tons of money, it is about doing what you love, and sticking with your passion no matter what gets in the way.

(all images are copyright their respective owners)