Wednesday, January 30, 2013

I Can't Escape - A One Month Game Experiment

When I joined McFunkypants One Game A Month challenge, I knew that I wanted to accomplish two things:
1) To experiment with interesting game designs I wouldn't normally pursue.
2) To connect with new talented individuals.
I figured that worst case, it'd only be a month, and best case, I'd have an interesting game and know new people I could work with and trust. In this sense, "I Can't Escape" turned out to be a best case scenario!


When I designed I Can't Escape, I wanted something very simple at its core - something that could be feasibly finished in a single week! Even though the challenge gave me a whole month, it's always better to underdesign than overdesign - more can always be added, but game development almost always takes longer than you expect. Even a simple "one week" game idea might end up needing the whole month! I also chose a genre I had never explored before - I Can't Escape is my first horror and atmospheric game. It was interesting to see what I could come up with in this new territory.

At its core, I Can't Escape is exactly what it seems: you explore a creepy underground maze, stumbling around pretty much randomly without a map, and fall down pits until you reach the end. I wont say exactly what you can find in the levels, but there is no battle system, no shooting of zombies, just simple exploration with a simple goal - to escape. In order to escape, all you need to do is climb a ladder on the first level. The "horror" part is more subtle than most horror games I've played. Instead of enemies jumping out at you, there's an overwhelming sense of being watched and followed (there are literally eyes in the walls watching you - this is one of the most common events you can stumble upon). This builds the anticipation of something just around the corner, but that tension is never dispersed by having that something actually jump out at you.

Aforementioned eye staring at you deep in the dungeon.
The game is designed to make you feel lost and trapped. The levels are incredibly large and maze-like with no map to guide you. It wont take long before you have absolutely no clue where you are. The game is also designed to make you fall deeper - you're "supposed" to go up, but instead somehow you always end up going down into darker and scarier levels. With subtle effects like the movement speed slowly increasing, the anxiety rises as you realize that it's very unlikely you will even reach the first floor again, let alone escape. Eventually, you reach a level where you are trapped behind locked doors, and you literally can't escape. The light then slowly fades out, and the single word "END" appears.

The game taunts you with the possibility of escape, it even starts with you landing right in front of a ladder, with only a locked door keeping you from freedom. Along the way, you will find keys that unlock doors, and sometimes even find ladders you can climb, bringing you closer to the top. But, despite your best efforts, you still eventually fall down deeper and deeper. Sound like a metaphor for real life? Hopefully not! I won't answer whether it is possible to escape or not, as there are several rare events you can stumble upon in the game, but don't expect escaping to be easy!

A ladder on the first floor with no pit blocking it? Is it real? Did the developer just create this image as a joke??
This was an experiment for me, so I've released it for free on Newgrounds: http://www.newgrounds.com/portal/view/610205 , and I encourage everyone to try it! I also released the source code here: https://github.com/davidmaletz/CantEscape . The code is not particularly clean (lots of hacks happen with short deadlines), but if you can read it, perhaps you can answer some of the questions I've kept quiet on, and maybe even add an easy way to escape! It's too early to say how people will receive the game, and I've certainly had comments from people who didn't get it, but I've had far more comments from people who it "scared the pants right off," and that is very encouraging for me as a developer.

I really enjoyed the experience of working with Chase Bethea and Josh Goskey (this was the first time I worked with them on a project, but not the last), and I really appreciate the effort they put into the game (and of course, my lovely wife Natalie helped too)! For a one month project, I'm very impressed and proud of the work we did!

I've already moved on to my February game, so I doubt I will go back and make many changes to this game, but feel free to leave comments and let me know what you think about I Can't Escape!

Thursday, January 17, 2013

Progress Update

Here's a list of all the cool things I've been working on since my last blog post:

  • Realtime Clouds and Atmosphere - I've been working on this project for some time, it's a flexible algorithm that accurately renders and simulates dynamic & volumetric clouds and atmosphere. It's not a hack or approximation, it computes real single-scattered lighting through the clouds from a directional light source (the sun, or moon at night) and the atmosphere. It doesn't use particle effects either, it renders directly from a 3D texture, removing popping artifacts when flying through particles and making it very easy to modify and simulate. This is pretty computationally expensive, it wouldn't be possible without the power of new graphics cards - however, a few years from now, it'll probably run realtime on commodity graphics cards as well. The sunsets are especially awesome, when the sun lights high clouds from below with a reddish light, and I didn't plan or explicitly code that, it just did it since it was accurately modeling how the clouds would be lit from the sun and atmosphere!

    Right now, I've been thinking about where I want to use it, but my dream is to one day make Aero Empire with this technique. Don't get your hopes up too much if you're an AE fan, as I haven't started work on the revised AE yet and don't plan to any time soon, but I do have plans (and by the time I finish AE, the clouds might run realtime on most computers haha!).

    Of course, you have to see the clouds in motion to see the power of this technique, so here's a video:
  • I Can't Escape - As stated in my last blog post, I joined One Game A Month, and this is my January Game. I Can't Escape is a 3D, first person horror game being written in Flash's Stage3D. I have never made a horror game before, which was part of the reason I wanted to try it as my January project. The game focuses mainly on exploring a creepy dungeon with retro graphics (think old raycasting games), and the "horror" element derives from the atmosphere and a sense of being lost in an incredibly large dungeon. Most of the code for the game is done, I still need to do a few minor things, but I'm mainly waiting on art at this point as the artist I'm working with is somewhat behind. The game still needs a few more sound effects too, but the game's pretty close and there's still two weeks left, so I'm confident we'll get it done in time. You can check out the current version of the game (will continue to be updated) here: http://fancyfishgames.com/ICantEscape/ , and the game's also open source, you can view the source code here: https://github.com/davidmaletz/CantEscape.
  • Obey - Since signing up for One Game A Month, game ideas have been flooding my mind. Obey is a choose your own adventure / visual novel (with some RPG elements) that focuses mainly on the story, and the many choices you are presented with during the game. It takes place in a future dystopia, where an AI tyrant rules the world. It has multiple endings, and I've already drafted an outline for the entire game, as well as the introduction. I do want there to be some nice still art to go along with the story (and I think I know an artist who'd be good at this), but for now the main task on this game is to finish the story. Once I finish the story, I'll easily be able to make this game in a month, and so I'll schedule this game for a month after I've finished writing.
  • The Final Battle - Another One Game A Month idea, this one was spawned when reading the epic Last Battle in A Memory of Light (the last book of the Wheel of Time series, great series btw). The Final Battle will be an RTS of epic proportions, where you command armies of 10,000+ units in an all out "final battle." Every unit will have it's own little AI script, and the AI scripts will all run in parallel on the graphics card using OpenCL (I like utilizing the graphics card to do computation that would be impossible on the CPU). Each unit will also be displayed as a small, maybe 6x6 pixel sprite, which I will draw myself (it doesn't need animations or detail, so I can handle that haha).
  • Havencall - So, what about Havencall? Well, there hasn't been a lot for me to do code-wise lately on Havencall. Right now, the scenes and art take priority, which Natalie has been working on (she's been making some awesome scenes, you can see some of it here: http://www.indiedb.com/games/havencall/news/art-update1). There's still over a month of coding left for me to do in Havencall, but I plan to spread that out over the next few months, and hopefully release Havencall by September as planned. I certainly haven't forgotten about Havencall, and I'll still be able to release it on time even with One Game A Month.
That's all of the updates that I can talk about, and I have a feeling that this will be a great year for me with all my plans for One Game A Month. You can see a list of my One Game A Month plans here: http://david.fancyfishgames.com/p/one-game-month.html , which I update from time to time. Soon, the world will be flooded with awesome games made by me haha!

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 gmail.com!

Friday, December 7, 2012

Nostalgia

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: http://david.fancyfishgames.com/p/games.html , 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: http://pinterest.com/pin/279504720595243083/
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: http://agbeat.com/real-estate-coaching-tutorials/the-violin-prodigy-inspiring-story-about-passion/ . 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)

Tuesday, November 20, 2012

Early Prototype Completed

An early version of Havencall is running, with movement and basic gameplay complete! We've been working hard to complete the early prototype, and also recorded a video to share our progress. Here are some of the features already in the prototype:

Movement: The prototype scales and moves our protagonist, Aura, between layers to give the feeling that she is actually walking through a digital painting. You can only move along static paths, but those paths allow you to go anywhere of importance.

Interaction: The prototype allows you to click objects to interact with them, and can pathfind to move you to the object. The cursor will change to denote where and what kind of magic you can use at the moment. Clicking and holding when that cursor is up activates the magic.

Animation: The prototype uses the VIDE animation engine, and can support deformed image animations. Aura was animated in VIDE, along with the cursor charge and clock hands animation. Eventually, we plan to do a lot more animations to make the world come alive, including flora & fauna, and other characters you can interact with and talk to.

Sound: The prototype has many "fake 3D" sound effects, which adjusts the pan and volume of the sound effects automatically based on the position of the player.

Of course, an image is worth 1,000 words, and a video is worth 1,000 pictures, so check out the video and see all of these features in action:


We're still early in production and nothing is finalized yet, but we're definitely making progress, and I hope to have more to show soon! But first, it's turkey time - have a great holiday everyone!

Thursday, November 15, 2012

What is an Indie Game Developer?


It is clear that independent game development isn't what it used to be - it's now a lot easier for anyone to create and publish a game. The number of indie game developers has been increasing dramatically every year, and crowd-funding of games has become more and more effective. I've heard a lot of people wondering if all these developers inundating the scene are actually indie at all, or if there are even any "indies" around anymore. They seem to be asking: what happened to the penniless, sleepless independent developer working from their garage and suffering for their dream? Why is there so much money involved now? Some independent developers have been able to make thousands, even millions, have teams behind them, and may even have real office spaces (the horror!). Some seem to be wondering: "how are they even indie anymore?" A "true" indie couldn't dream of charging money for a game or making anything remotely "traditional," right? I disagree.

Who's the "true" indie dev? (From EGW 2006)
The game I am currently developing (Havencall), while it has an interesting story, is a point & click adventure game, and it is not particularly weird or experimental. And I'm not going to deny it, I do want to make money on it so I can pursue my goal of making game development my full-time job. I even plan to eventually run a kickstarter to help fund the game, despite the fact that a lot of people have been looking down on that route. So I began to wonder: was I wrong to want money for my games? Could I truly call myself indie even if my games were not wildly experimental? What does it even mean to be an independent developer?

I eventually started wondering if I should make Havencall more weird or experimental in order to fit in as a "true" indie.  But then it struck me: that would defeat the whole purpose of being indie in the first place! And that was when I had my answer. Indie means just what it sounds like: being independent; it means making what you want to make and not letting producers, money, notions about the market or anything else get in the way of that. If I had changed Havencall to fit into the indie community better, I would have ended up compromising my independence, just as if I had a producer who forced me to change the game for money. Being indie is all about the spirit of making the game you want to make, not the game others want you to make, or the game that you think will make the most money or get the most recognition. Being indie means being true to your own personal vision, and not letting anything get in the way of that, no matter what the size of your budget, your team, or your workspace.

Next I thought about kickstarter, and how so many indie devs were pushing campaigns and fighting for funding goals. Some developers seem to get so caught up in funding and how to please their backers, that they lose their vision and indie game spirit. However, I see nothing wrong with trying to reach out to fans and get funding from kickstarter or sales in and of itself. Personally, I will be looking for the funding to let me work on my game full time, as are many other game developers just like me. As many of us know from experience, working on games part-time in off hours is slow, and games can take years to finish that way, and when game projects take years, all sorts of trouble can occur (I know this all too well from Aero Empire). Wanting to make money on your games doesn't make you any less indie, as long as your true passion remains in the "making games" part of things and not the "making money" arena.


So, if you ever start thinking solely along the lines of: "oh, this game would make me lots of money, I should make it" or "I should add microtransactions so I can release the game for free," stop and consider if that is really the game you want to make. Do the microtransactions ruin the gameplay you dreamed of? Is a game that is likely to bring in lots of money really the idea you're passionate about making? Are you doing that sequel because you really want to make it, or because you're fairly certain it will be a success? If you come to the conclusion that you're making the game that you really want to make, then to me, you're indie. Whether you work from your garage or a million dollar office space, if you stay true to yourself and your vision for your work, then you're an independent developer.