End of the Year

We're coming fast to the end of the year - a time to reflect on how things went and plan ahead for the future. And it was quite the year for me - I joined One Game A Month and released four games - doubling the number of games I have released. I also attempted my first crowd-funded project - Rhythos RPG Builder, and while it failed, I learned a lot from it and have the beginnings of a very useful toolset for future games. I'm also over halfway done with Deity Quest (a larger game project I started after One Game A Month), and I even submitted Deity Quest to the IGF. It's been a busy year, and while I'm still not able to work full time on game development, I've made some big strides, and have even bigger plans for next year!

Projects Completed in 2013

I Can't Escape was my first One Game A Month, and by far my most successful one in terms of popularity and number of hits. Since I knew I wanted to participate in One Game A Month at the end of last year, I had actually started planning I Can't Escape in December of last year - so while the actual development didn't start until the beginning of this year, I had done the planning and team recruitment for the project in advance, and that extra planning definitely made a big difference. The actual gameplay for I Can't Escape was deliberately small, making it possible to complete in a month's time, and that simple gameplay made it easier to break player expectations and create the eerie atmosphere that made the game so successful.

A Different Color was my second game, and also had much less time for development since my original idea for February ended up being too large to do in one month. The goal for this game was to make something simple that had a strong message, based on some of my own experiences in life. It was short and didn't reach as many people as I Can't Escape, but those it did reach seemed to like it a lot, and many people seemed very touched or saddened by the story. There were also people who didn't like the message or misunderstood it, but that's expected for a game like this. I certainly touched upon some very sensitive subjects with this game, but that was my goal.

Trip Through Time was my third game, and in my opinion a failure. I was trying out new genres without the proper time or research, and the game mechanics didn't turn out as fun as I thought they would. This happens a lot in game development - sometimes when you finish that early prototype, you have something immediately fun, but more often it ends up not being as fun as you imagined or requires a lot of tweaking and redesign. With enough time, tweaks and improvements, perhaps I could have made this game a success, however, sometimes it's best to return to the drawing board and move on (which is one thing One Game A Month helped me learn). Deus Shift (2011-2012) took me over a year to complete and was redesigned from the ground up three times (with lots of scrapped code and assets). While the game is now fun and well balanced, it took way too long and is still missing some important features (like a good tutorial or campaign mode). Would it have been better to have scrapped the first Deus Shift prototype and tried out three new games ideas instead of redesigning it three times?

Rhythos! Arcade BETA was my fourth and final One Game A Month, and perhaps my most ambitious in terms of gameplay features. It was a redesign of the game that I postponed in February, and is basically a twitch/rhythm-based RPG battle system with a ladder of enemies to progress through. Rhythos was my second most popular One Game A Month, and as you may have guessed, what spawned Rhythos RPG Builder. I wanted to create a full RPG using this battle system but obviously couldn't do it in a month, so I planned to crowdfund an open source RPG Builder to allow myself and others to make RPGs with this battle system.

Rhythos RPG Builder was then created, and I fixed up an old tile map editor I had worked on in the past and added the Rhythos battle system to it. However, the kickstarter did not reach it's funding goal, and work on Rhythos has been postponed indefinitely. The reason could be that I didn't market the editor enough, or simply that it was what I wanted, and not what other developers wanted (a lot of comments were that people wanted a more traditional turn-based battle system). Finally, I think that it's tough crowd-funding an Open Source project, as if the project is successful, everyone gets to use the editor, not just the backers. If I had a strong community behind Rhythos from the start, I could have overcome this problem, but I jumped into crowd-funding the project a few weeks after Rhythos! Arcade BETA and without any strong plans. This was still a good learning experience however, and I do want to go back to Rhythos RPG Builder eventually.

Ongoing Projects in 2013

Deity Quest was started after Rhythos RPG Builder failed. I had gotten far off track from One Game A Month, and I wanted to develop one of the larger game ideas I had. Deity Quest mixes up the elements of pokemon, rpgs and dungeon crawlers and has an interesting 6 vs 6 battle system where you support your followers with items and spells. There's a lot of depth and strategy to Deity Quest's battles, but it is also accessible for casual players as the battles can be largely automated. If completed (which, at the rate I'm going it should be done by March of next year at the latest), Deity Quest will be the largest game in terms of features and gameplay length that I have ever made. With all of the base framework done (and several iterations of testing, tweaking and balancing the core), along with over half of the gameplay complete, I'm confident that I will finish this game early next year (and then have time to balance, playtest and get another beta out before March).

And what's the deal with Havencall? Well, right now, the ball is in Natalie's court, as all of the base framework is done and I need assets before I start adding content to the game. However, she's been getting a lot of art and backgrounds done, and even though we have to keep pushing the release date forward, she's promised now to have all the art done by March of next year, and the game will hopefully be released a few months after that!

Future

So, what comes next? Well, hopefully Deity Quest and Havencall will be released and successful. The more successful games I release, the further I get in my goal to one day make this a full time indie game studio! I've certainly been learning a lot and improving in both game design, programming and marketing my games (while I don't like marketing, I have to at least know how to contact press and let people know my games are released). And of course, I always have new game ideas - two of which have complete design documents and are planned to begin production next year! Both of these games are pretty big in scope, and I finally have a design that fits my epic These Falling Stars world and story, so look forward to that!

Deity Quest BETA Release!

We finished the BETA of the first part of Deity Quest! I am now sending out the windows, linux, android and flash version of the game to BETA testers (mac version coming soon). The game is nearly feature-complete at this point. It is just missing some final art, music/sounds, and the options menu. While the missing assets are finished, I want to balance and tweak the game and make sure it runs smoothly - which is why feedback from this BETA is so important! If you haven’t messaged me showing interest in being a BETA tester and want to help out, now is the time to do so (you can email me at davidmaletz@gmail.com).

Over the past week I’ve added a lot of final menus and tweaks, including saving/loading and the main menu. I've finished up all of the features, and added a short set of instructions at the beginning of the game. It doesn’t explain everything though, so there’ll still be some hands on learning as you battle and explore menus. You can view details on some of the older updates on Deity Quest's Indie DB Page.

I also added a shop to the game. Originally, I was planning on just having you find items in locations, but sometimes you’d get items you don’t need, and a shop adds a lot of flexibility to the game. If you have no arcane followers, for example, grapes (which recharge mana) are useless and you can sell them to the shop and buy apples (which restore health).

We’re moving fast toward the IGF deadline (Oct. 19th) - and if I can get the first part well balanced and all of the missing assets done in time, we should be in good shape! Look forward to future updates, and perhaps a public demo in the not-so-distant future!

Introducing Deity Quest

In Deity Quest, you play as a deity who has just graduated after 100 years in the Ethereal Academy. Finally, you are ready to claim dominion over your first planet, convert followers to fight for you, and support them in battle with your divine magic. You have high hopes of one day becoming the Overgod of the universe, and won't let your long-time rival beat you to it! Deity Quest has been in development since June, and was partially inspired by Pokemon-style games, dungeon crawlers, and role-playing games.

The basic idea for Deity Quest came to me when I was trying to fix some fundamental problems with a scrapped game design where you would support an AI controlled main character. The problem with that design was that there just wasn't enough for the player to do - however that's where I borrowed some ideas from Pokemon. The problems were solved by having a team of up to six followers you need to support and position, with the ability to gain new followers by converting enemies. The game is similar to Pokemon in that there's a large number of follower types to find and convert, however, the followers are all completely AI controlled, and your job is to lend your followers support using your deific abilities.

Deity Quest is also inspired by dungeon crawler games - you'll traverse through randomly generated areas and dungeons while managing limited mana and items to get you and your followers to the end. You're only allowed 6 active followers and 6 backup followers per area, and if they all die, you're thrown out of the dungeon. Likewise, running out of mana can be a big problem, as without mana, you cannot support followers or convert new followers, and followers that draw mana from your mana pool will not be able to use skills.

Finally, the story and progression are similar to a role-playing game, where you travel to different areas, follow a linear plotline and level up to gain new spells and abilities. The story is broken up into eight parts that span your adventures on the planet Aberos. Will you be able to become the Overgod?

Deity Quest has certainly turned out to be a bigger project than I originally imagined, but I'm excited to see it happen and it's already well underway! Right now, I have completed the battle system and an outline of the story, locations, dungeons and boss fights. This is the groundwork behind the game, and I've also done preliminary balancing for all spells, skills, equipment and follower types. There's still a lot to do - all the out of battle code and systems, like handling locations, dungeons and dialog. My current progress is still an impressive milestone and that is why I've decided to announce Deity Quest now. You can see some example battles in the following video:

Battle System Demo - Indie DB

As a god, you will need to choose an alignment that will affect various parts of gameplay as well as where you start and who your starting follower is. The alignments you can choose from are:

Good - Good deities follow the ideology that every follower's life is priceless, and gives all followers a slow regeneration to help keep them alive. While good deities can convert evil followers, they are harder to convert and require a mana conversion cost of 1 mp every time they draw from the divine mana pool.

Neutral - Neutral deities believe in balance, and that both good and evil have their place in the world depending on the situation. While they give no benefits to their followers, they are able to easily convert followers of all types, and can choose to learn both good and evil spells, giving them more flexibility and options.

Evil - Evil deities believe the needs of the many outweigh the needs of the few, and will not hesitate to slaughter enemies and sacrifice allies to further their cause. Evil deities give all followers an additional 25% damage bonus to help them accomplish what needs to be done. While evil deities can convert good followers, they are harder to convert and require a mana conversion cost of 1 mp every time they draw from the divine mana pool.

So pick your alignment, convert followers to your side, create a balanced team of followers to fight, and support your followers as you head towards becoming the Overgod! I hope you're as excited as I am, and follow my progress on Deity Quest's IndieDB page!

Status & Plans

I haven't released a blog post or a new game in a while, so you may be wondering what happened and whether I am still doing One Game A Month. After the Rhythos campaign ended unsuccessfully, I knew that I'd have to take on more work as for most of this year I'd been focusing on making games (and making nothing on them) and that was starting to catch up with me. I'm not yet in a position to work on games full time, even though I'd really like to. However, that doesn't mean I'm going to stop making games.

I have decided to stop making One Game A Month, however. I have several larger projects that I've been wanting to make for a while that I couldn't make in a single month, even if I worked on them full time. One Game A Month was a great experience and helped me release several great games, but now I want to use what I learned to create bigger, more exciting games. Here are my plans for this year (ordered by priority):

Havencall - Havencall is a point & click game my wife and I have been working on the side for several months, and were hoping to release September this year. I still want to release it this year, and we've been working hard getting all of the assets prepared, although it might not be finished until November. It should be very impressive when done, both visually and story-wise. You can find more information about Havencall on it's homepage: http://havencall.com/. Here's a new screenshot of a scene in havencall, this one from the second world:

A Cabin deep in the woods on the outskirts of the city. Don't get lost!

Rhythos - I also don't want to give up on Rhythos just because the campaign ended in failure, so I'm hoping to finish a demo version of it by the end of this year so that people can try it out and see what makes it awesome, and then attempt another campaign next year. I'm really hoping the next campaign is successful, but if it's not, I'll probably end up releasing a less user friendly/undocumented version of it, mainly for my use (and anyone who can program and figure it out). That way, I'll still be able to use it to make some of my own games, so it wont be a total waste of time. And who knows, maybe it'll still one day get to the point where I wanted it to be since anyone can contribute to the project.

Unnamed Project - If I can, I also want to squeeze in one more game project this year. It's a new project I've been working on the design for recently, based loosely off the original system we developed for Ainsworth. It looks like Ainsworth is going in another direction now, but I'm leaving all decisions about that to Van (the artist working on it) until I get started on coding Ainsworth. However, despite it's flaws, I liked the original system of Ainsworth, and figured out how to fix all of the flaws, but those changes caused the design to be a completely different game. I've almost finished the design, units, spells and equipment for this new game, but it already looks like it's going to be pretty fun. I'll release more details on this game once I start prototyping it, but in short it's a game where you play as a Deity that gives benefits to followers (similar to D&D Deities), and you can convert followers from 128 types to your cause (a little like Pokemon). As for the actual gameplay and battle system, I'll tell you later, but it's pretty interesting and novel.

---

Next year, I have a few larger projects that I'm almost ready to get started on (ordered by priority):

Aero Empire Remake - It's been a long time coming, I've been contemplating making a remake since Aero Empire fell apart. The remake is now mostly designed, and we have decided to make it in 2.5D (2D sprites in a 3D world). It will be similar to the Captain stage of the original Aero Empire, meaning you'll be able to fly and upgrade your own airship, and travel from town to town accomplishing missions and trading. There will be different regions, reputations, economies, exploration and combat (so, one well designed stage instead of several shoddily slapped together). Since all of the art will be 2D sprites drawn by Matt, the artist who designed the airships in the original Aero Empire, you know that it'll be stunning visually - and I have a few tricks up my sleeve for clouds, atmosphere and depth perception in a top-down view with 2D sprites. I'll give more details about this next year, but we're serious about the remake now and have it mostly designed. It's about time we created this game!

Asylum Game (name subject to change) - Partially inspired by I Can't Escape, this will be a full 3D (not grid based) horror game taking place in an abandoned asylum. The rules of time and space will bend in this game, and like I Can't Escape, the game will rely mostly on atmosphere and exploration - although you might not be completely alone in the asylum!

These Falling Stars - An epic RPG I've been wanting to make for a while, and plan to make in Rhythos RPG Builder when it's done. The game is about the rise and fall of nations and heroes, and it's named These Falling Stars because it's about how even things that seem eternal like stars eventually fall. The game has 800 years of history, with three great ages and many nations and people who have risen to power only to fall in the ebb and flow of time. Once again, it seems like the seven city-states now ruling Zythros are on the verge of destruction, and they don't even realize it. Can you stop the inevitable collapse? Is stopping the progression of time even the right thing to do? This game has quite the story, with lots of twists and turns along the way that I'm not going to spoil - so look forward to it!

Those are my plans for the next few years. I'm really excited to get cracking making these games, and am even planning to attempt selling several of them in the hopes of becoming a full-time gamedev. We'll see where my game development career goes, and I certainly have lots of other game ideas I want to make if these are successful! Look forward to more updates on these games, and let me know if you have any questions about any of these games!

Rhythos Development Blog

Just letting you all know that the lack of blog posts here is because I'm mainly focusing on Rhythos RPG Builder, and have been posting development updates about it here: http://rhythos.com/forum/index.php?page=forumview&id=development-updates . If you're interested in Rhythos, check out the updates there, otherwise, I'll continue to post interesting news and updates here!

Rhythos RPG Builder - a Free and Open Source Dev Tool

I'm currently creating a free, open source RPG builder that will be cross platform and support many cool features, including an action/rhythm battle system which you can test out here: http://www.newgrounds.com/portal/view/616768! The builder will have an accessible dual-scripting system and be highly expandable, including a powerful plugin API. The editing capabilities are inspired by RPG Maker and based off of an older tilemap editor I have been developing on and off in my free time for the past year or so. The builder also uses the great 16-bit style graphics provided by the Liberated Pixel Cup/Open Game Art.



I know first hand how hard finishing a project like this can be. I've had experience making game development tools before including VIDE, a 2D animation tool, HTML Tactics, a DOM-based tactics game editor, and a 3d cloud and atmosphere rendering API. I'm also the founder and lead programmer of Fancy Fish Games, with 6 games released so far. I feel I have the skills to make this project a reality as well as the knowledge of what it's like to be a game developer using the tools! With my experience and a large codebase already complete, I am confident I will be able to come though and finish this project, but I'm going to need a little help!


A 2x speed example video of me creating a simple house interior in the Rhythos Map Editor.

That's why I've started a kickstarter page (which includes a lot more details about the project) here: http://www.kickstarter.com/projects/davidmaletz/rhythos-rpg-builder! If you're able to back the project, that's great! But even if you can't contribute monetarily, feel free to contact me if you are interested in supporting the project as a coder or artist! This is truly a community-driven project and any support possible (even just spreading the word to other developers) would be awesome! You can also peruse the current codebase on github here: https://github.com/davidmaletz/rhythos . It still needs integration work and a lot of features before I'll consider it stable, but feel free to check it out and let me know if you are interesting in contributing code!



And of course, let me know if you have any questions, comments, or feature requests - this project is very expandable, and I hope to support a lot of options, features, battle systems and release targets eventually. I'm creating this tool for the community and with the community, so I want to know what you want!

Fun with Bugs!

This will be a short blog post about something funny that happened when I was trying to debug my latest game, Rhythos! The bug report was that if you beat the final boss with no equipment by the timer running out and having more health, the game froze.

Of course, the first thing I do when I get a bug report is I try it out. If the bug isn't reproducible, then it's almost impossible to debug. So, I tried it out, and the game froze, so at least the bug was reproducible. I was ready for this to be a quick fix!

Then, I put some debugging traces in around the end of battle, and ran it locally on my computer to see if I could find out exactly where the bug occurred. But then the bug DIDN'T occur!

So, my next thought was that it had something to do with running in debug mode, or running locally on my computer (instead of embedded in chrome). So, I tried it out on my homepage (which was the same version as the one uploaded to newgrounds), and the game worked fine!

Alright, so the problem obviously had to do something with being uploaded on newgrounds or the newgrounds API. Already I knew this would be an annoying bug to fix. Hoping I would get some error in the flash tracer, I tried the game in firefox (I can't install a debug flash version in chrome because it has a built in version of flash), but the game still worked fine, with no errors in flash tracer.

Baffled, I tried doing the same thing with another enemy. The game worked in chrome on newgrounds. So apparently this bug only occurred in chrome, on newgrounds, against the final boss. To make sure I wasn't going crazy, I tried reproducing the bug again, and once again, the game froze.

The bug was reproducible, it should have been an easy fix! But I was having trouble getting debugging information. Reproducing the bug again and paying close attention to exactly where the game froze, and what commands had been called before it crashed and which commands couldn't have been called yet, I narrowed down the approximate area the bug could occur. Then, with no other information to rely on, I made a wild guess - I noticed that the game would freeze at that moment if somehow the time remaining on the song ended up less than zero.

Of course, given that the song's position should never be greater than the song's length, this shouldn't be possible, but I was looking for something that should be impossible but occurred in one custom version of flash player on chrome. Perhaps chrome's flash player had a bug where the length it returned was a few milliseconds off. So, I uploaded a new version that checked and properly handled if the song's time remaining reached less than zero, and it worked! The bug was solved, and I rejoiced!

As for why the bug didn't occur with other monsters, my guess is that it's because other monsters have other songs. I didn't try reproducing this bug with the flower or lich lord, the only other enemies that have the same bgm as the final boss. I still don't know why it worked on my homepage and not on newgrounds, but the bug was fixed, and my blog post done!

Rhythos! Arcade BETA Development and Future

Rhythos is a game concept I've been toying with for almost a year - the initial idea was to combine a rhythm game and an RPG. Part of my inspiration for the idea was the battle system in Sword & Sworcery, where the beat of the music played a strong role in the gameplay. At first, the idea was pretty vague: basically, you would use the arrow keys to battle in time to the beat. I've come a long way since then, and I'd like to share some of what happened during the development process, and what my plans are for the future of Rhythos.

I had contemplated making this game a long time ago, but never had the chance, given that the idea was vague and could take a long time to make (since I wanted out-of-battle RPG content as well as the music-focused battles). It wasn't until February that I began developing Rhythos in earnest, as part of One Game A Month. I came up with a concrete idea for the battle system, and decided to use free, open source LPC art to speed up the art side of the development. However, after about two weeks I realized that I wouldn't have enough time in the month to complete the game as I had envisioned it, and so instead I created A Different Color as my February 1GAM game. At that point I had already decided upon my March game, and so I didn't get back to Rhythos until April. Below is a screenshot of where I left off in development in mid-February.

This original battle system was a lot closer to a stepmania-type game than it is now, with all actions having to be hit at exact notes, and the closer you get to the note, the better the action performed. When I came back to the game in April, I decided not only that it would take too long to make, but that the system wasn't as fun as I'd envisioned, and could be greatly improved. A big problem with the original system is that it brought all of the focus to the arrow bars, and the character's actual battle below was extraneous, just a visual depiction of how well you did. I knew I had to bring the focus and attention to the battles. After some brainstorming of ideas, I eventually settled upon a battle mechanic very similar to the current one. After having to scrap most of the February code and doing some rapid prototyping for a week, I got what is shown below.

This prototype had no menus, it simply loaded and instantly put you into a battle with a skeleton, the only enemy type. At this point, only the bow weapon type was complete, I didn't even know what I wanted the other types to be. While primitive, it allowed me to see how the basic gameplay felt, and was a big first step.

Here are some screenshots from a week later (April 13th) - I had added spells, evading and defending for both the player and enemy. At this point I felt like I was making progress, since the gameplay felt cleaner and more focused. However, I was moving further from the original idea of a "rhythm" game, and more towards a pure action/fighting game. But I knew I would eventually figure out a way sync the game with the music, and so I just crunched out the basic systems.

After the third week of April, I had decided on all of the weapon types, added the combo bar, and added the UI framework that I would use to create all of the menus and dialogs. I still didn't have a main menu, the game just let you create your character, set his or her equipment, and then fight the same skeleton enemy. Things were finally starting to shape up, but I still had a long way to go, and it was already April 22nd by this point. I was starting to think that once again I had taken on too much, and would have to postpone releasing the game. I certainly wouldn't have time to add the out of battle elements or story elements that I had hoped for, and it wasn't even clear if I could make a well polished battle arcade game with only eight days to go. Ludum Dare 26 was coming up, so I was contemplating putting Rhythos on hold yet again, and submitting a Ludum Dare game as my April 1GAM.

Of course, I didn't stop working on the game while I waited for Ludum Dare to begin, and due to a combination of good progress on the game during those days, and not liking the theme of "Minimalism," I decided to crunch for making Rhythos! Arcade BETA. The "Arcade" subtitle is because it would just be battles up a ladder of enemies rather than a full RPG, and BETA because I would only have a few days to balance and tweak the game before releasing.

Late on April 28th, the game was finally "feature-complete," all of the features I wanted were in and tested, and all that was left was setting stats and balancing the game. I had created a little script that took a pattern of actions and the BPM of the song and automatically synced the enemy's actions to the beat, so the problem of syncing the battles to the music was also solved. The idea was that the player's actions would need to follow the beat in order to deal with the enemy's timed actions. The player wouldn't need to follow the music exactly, but a little leeway and flexibility doesn't hurt.

Fun Fact: It wasn't until around this point that I had finally come up with the name Rhythos! Before, I was just calling it MusicRPG, and without any story elements, I had trouble coming up with a name. Rhythos is actually a portmanteau of the words "Rhythm" and "Zythros," where Zythros is the name of the continent in my other RPG world (and has been used in several games I've made since I was in high school).

The animated stars are a cool feature I probably didn't have time to code, but I added them anyways!

The last two days of April involved a lot of play-testing, debugging and tweaking. I knew two days wouldn't be enough to get everything perfect, but I had the disclaimer "BETA" right in the title, so I decided to just get things as polished as I could. I can't even remember how many hours I played, testing out different weapons and spells, beating the game again and again as I changed stats around. But, I never hated playing the game, which was a good sign - as often after playtesting a game too much you can get very tired of it. That told me that the game had a lot of potential for being fun and had good replay value.

I had my friends and family play the game too, and posted a link on twitter for my followers. Finally, late on April 30th, I wrote the manual and created the Rhythos website. I was quite proud of the game itself, and of having crunched to finally finish this month instead of postponing it. I added achievements and uploaded it to Newgrounds the following day, on May 1st. Since then, it's had positive reviews, although some people complain that the game is too hard, while others complain that the game is too easy. I guess you can't win the balancing game, but at least it wasn't hard enough that everyone found it frustrating (or too easy that it bored everyone). So, all and all I'd say the rushed release was a success, and I've already gotten a lot of valuable feedback for future improvements.

Currently, I have two plans for the future of Rhythos, both of which are probably over-ambitious again! The first is making a full RPG using Rhythos as my battle engine, with a complete story and out of battle gameplay elements. It's what I always wanted with this game. The second is an RPG Maker-like editor for the game - I loved RPG Maker a lot as a kid, and think that allowing others to create their own RPGs on top of this battle engine would be great! Not to mention, a Rhythos editor would make it a lot easier to make my own RPGs. While a full-featured editor would be a lot of work, Rhythos already has a lot of the core functionality needed, and I have a decent sized code-base from a previous attempt to create an RPG editor. So, no promises, but both plans are something I'd like to do in the future if I can find the time.

So, that's the news for Rhythos, feel free to play it on my website or on Newgrounds. Let me know what you think and if you have any suggestions for improving it! And, if you're interested in using an RPG Maker-like editor with this as the battle engine, let me know, as the more interest there is in that, the more motivated I'll be to make it!

Motivation, Milestones and Gamification

One of the things I love most about being an indie game developer is that I have no boss, and complete creative freedom. However, at the same time, being my own boss means that there's no one to push me or motivate me. There's no one to force me to crunch, and no one to stop me from taking a day off. While there's a lot of flexibility in that, it is also very dangerous, as sometimes the crunching, focus and motivation that traditional work environments offer are necessary to push through and finish a game. This post will be about how indie developers can motivate themselves, and finish games without having a boss keeping an eye on them.

Most indie developers I know think that all they need to motivate themselves is the desire to create the games, and the potential money they may earn from the game. However, both of these motivators are fairly weak. The desire to create will certainly motivate you to start a new game project, but it often fizzles during extended game development periods, and can even distract from your current project by enticing you with a new game idea while in the middle of your current one. The desire to create alone isn't enough to actually finish a game unless it is a short-term project. Potential money, as well, can be a very weak motivator - there is no guarantee you will get that money, and it sometimes seems so far off, so distant, that it doesn't really motivate you at all. This is true for anything that only motivates you once the game is released (enjoying others playing your game, fame, whatever).

As game developers, we know a lot about motivation, and how it impacts people. We design games which motivate players to progress step by step until they reach the conclusion of the game. However, we don't often seem to take that same knowledge and apply it to ourselves. Have you ever seen a game where the only goal is to defeat a single boss, and the entire game the player must grind with no direction until they are strong enough to eventually defeat that boss? That's essentially what we are doing to ourselves. We start the game really excited, saying "we're going to beat that boss, and it's going to be awesome!" But then, we have to grind a long time without any further rewards until we are strong enough to actually beat that boss. At times, the grinding may seem endless, futile, like the goal is barely getting closer at all. We might get tired and bored of doing the same old thing, and perhaps have a strong desire to switch to another project. If those other games are similar, we may never complete any games, and never beat any "bosses." This is a cycle that I've seen many game developers (myself included) get trapped in, and it's tough, especially if you are doing game development as a hobby and you are constantly distracted by your regular job as well.

One solution, of course, is to make SMALL games. Whether it be a game jam, or One Game A Month, if the game's development cycle is short enough that the initial desire to create keeps you motivated until the end, then you have your motivation. However, a lot of game developers, myself included, have big ideas that we want to make that just can't be completed in a short time frame. So, how can we, as our own bosses, motivate ourselves (and our teams) over long development cycles?

The solution is to break up the game development into smaller milestones. Each milestone is close enough that you feel motivated to push towards it, and completing each milestone must have a reward large enough to keep you going. We do this all the time in our game designs - instead of just grinding until you are powerful enough to defeat the boss, we add in quests and subquests, each giving you experience and moving you closer to defeating the one big boss, but also giving you rewards and incentives to continue along the way. Gamification is one of those buzzing words you hear a lot nowadays, and that's because by applying these principles of game development to real world situations, we can incentives and motivate ourselves and others. If you're the boss, there's nothing stopping you from gamifying your workplace.

So, what should these milestones be, and what rewards could they have? This depends on yourself, and your game, but typically, you want your milestones to be meaningful and tangible. Obviously, there are big milestones with prototypes, alpha builds, etc, but you can design tangible milestones for "hidden" code as well. Take AI for example, you could code a simple simulation showing it controlling dots instead of actual characters. This requires a little time to code, but doesn't require all of the game assets to be complete, and gives you a meaningful, tangible (and debuggable) milestone. As a very visual person, being able to see on the screen the AI algorithm or even the networking algorithm in action (simulating latency and multiple connections) makes me feel like I really accomplished something, and comes with the added bonus of revealing that "hidden" code and allowing you to tweak and debug it if necessary. By having meaningful milestones, you'll get a feeling of accomplishment, and by having tangible milestones, you'll get a feeling of progress, both of which are important to motivation.

I'm a strong believer in positive reinforcement, so to strengthen the effect of the milestones, you should add a reward (beyond the feeling of accomplishment). The reward depends on what you like to do, and what is reasonable. One reward I like is just a break, or doing something I've been wanting to do but have been too busy to do. This turns breaks from laziness that can strike at any time into a reward that you have to EARN. Money, of course is a good reward as well, if you have money you can dole out to yourself and your team. Work itself can be a reward as well - remember, we ENJOY making games, so perhaps make a reward for finishing something you don't enjoy to make (for me, the UI), with something you do enjoy to make (for me, rendering and procedural content). This spaces out the parts you don't like working on, and gives you a reward that is also productive.

My point here is that when you design the game, also design the game plan. What are your milestones and rewards, how will you keep track of progress and keep motivation high while working on the game? And, you can be fun and creative with this process as well, it's a lot like making a game. Making games should be fun, we just need to stay focused, motivated and passionate about the game throughout the entire development process, and breaking it up into manageable chunks makes it a lot easier to do that.

Where's My March 1GAM?

So, it is April 1st, past the deadline to have released my March One Game A Month, and yet I have only released this website: http://fancyfishgames.com/TripThroughTime/ , and there is no playable version of the game available anywhere. It's about a robot from a post-apocalyptic era who is sent back in time to observe the nature of humans and decide whether or not they are worth bringing back to life.

The trailer of the game, the only footage that I have released.

I'm sure you're all very patient, and are eagerly awaiting while I "look into one release option," but I regret to inform you that this has all been an April Fool's joke in bad taste. I'm not actually looking into release options at all, and have decided, aside from my friends and family, that no one should be able to play "Trip Through Time."

The world is not ready for this game.

This decision didn't come easily, as I really do want to get my games out there. However, I just feel that the world is not ready for this game. You see, in the development of this game, I wanted to have the robot travel all the way back to his "present," the year 397 A.H. (after humans). But, I am also a strong believer that games have to be realistic, and I just didn't know what the future era should look like, let alone the post-apocalyptic era. So there was only one reasonable way for me to add those eras: I invented a time machine, and both myself and my wife (Natalie Maletz, who created the art for the game) traveled into the future to gather reference material.

That's like spoiling the ending of a good book.

Now, the game and it's art was meant to only be loosely based off of the future, however, as people play-tested the game, we realized that the game was actually revealing too much of what we had seen, and I just can't in clear conscience do that to the world. That's like spoiling the ending of a good book.

So, I apologize to all followers and everyone who was excited about playing the game, but I wont be releasing it to the public. Thank you for all your interest, and please look forward to my April 1GAM. I have learned a lot from this game, and it is clear to me now that some things are best left unknown.

MIDI Music in AS3

So, for fun, I experimented with playing midi music in AS3 today, partly to see how hard it was to do, and partly to learn more about sound programming. I may have plans for this kind of stuff for future projects, but for now, it's just an experiment. Scroll to bottom if you just want to see source code.

First, why would I want to play MIDI files in AS3? Well, MIDI files are small (think kb for long songs, not mb), and very easy to manipulate. Since MIDI files contain just information about the volume, pitch, and duration (and a bunch of metadata/instruments that I wont handle, so I'll ignore in this blog post), it's trivial to edit the song, increase or decrease the tempo, and perform pitch shifts or even changing of instruments, and this can all be done dynamically. Unfortunately, for whatever reason, Flash does not support native playback of MIDI files, nor can you access the native soundbanks (instruments) to play the MIDI files from flash. I've seen some as3 projects use sockets to play the MIDI files via an external java applet, and I've seen some as3 projects that load sound bank files as well, but the first method requires an external dependency, and the second method requires loading the soundbank files for every instrument you want (which can be tens or hundreds of mb). However, there's a third option too - dynamically generating the soundbanks, and that's what I wanted to experiment with.

The idea came from as3sfxr: http://www.superflashbros.net/as3sfxr/ (which I found on the One Game A Month website). It allows you to dynamically generate sound effects with a bunch of interesting parameters. You can see some of their example sound effects on the left. However, tweaking with the parameters, I thought I could come up with some interesting instruments. You can control the start frequency and the sustain time to change the pitch and duration of a note - everything you need to play a MIDI file. To get a nice clean tone, I recommend setting everything to the defaults, and then choosing sinewave (which produces a pretty generic sinewave), but experimenting with the settings, you can create a whole set of instruments, like electronic, retro, and even real-world sounding instruments. So, I had my dynamic, tweakable "soundbank," all I needed to do was load a MIDI file and then play the generated sounds at the right times, with the right pitches and right durations.

The Instrument class handles playing a note with specified sfxr parameters. It changes the frequency and duration parameters for each note you wish to render, and then ADDS the generated sound samples to the passed buffer (at it's current position). Adding sound samples together is an approximation of two overlapping sounds playing at the same time. To be fully realistic, you would want to add the frequencies of the two clips (using a fourier transform), not the samples - but that is not only complicated, but also very computationally expensive if we're doing it on the fly, and adding the samples sounds good enough. So, if you learn one lesson from this blog post, it's that if you have two sound clips and you want to generate a new sound clip that has both of them playing at the same time, just add the samples (if you don't know what samples are, that's another topic, but feel free to ask me and I can explain it, or just look at tutorials on WAV files).

Some minor details - sfxr takes a decent amount of time to generate the samples from the parameters, so I had to cache the results for every pitch and duration the instrument came across. That sounds crazy, but computers have a lot of memory, and the same note will occur many times, so it speeds things up many times. Also, sfxr's start frequency and sustain time parameters are very unintuitive - they are numbers from 0 to 1. The static method getLengthFromS in Instrument takes an input (in seconds) and returns a sfxr value from 0-1 (or higher if it's longer than 2.something seconds, luckily I hacked sfxr to allow sustainTimes larger than 1 - I also made some other minor changes to sfxr, mainly to access private methods). The static method getFreqFromHz in Instrument takes an input frequency in hz and returns a sfxr value (clamping from 0-1 is ok here, as frequencies below 0 and above 1 sound terrible anyways). I had to see what the code was doing to figure out the mapping function, but trust me, it works, just trust these methods :P. The static method getFreqOfMidiNote in Instrument takes a midi pitch number and converts it to a frequency in hz and then calls getFreqFromHz to return the sfxr frequency for the midi pitch. This algorithm I found online, 2^((n-69)/12)*440 - basically, every 12 midi numbers is an octave, which means multiplying or dividing by two, and note 69 is an A with a hz value of 440 that's a baseline.

The Instrument class is the most important one, but we also need a way to manage tracks of notes. The Track class has a single instrument, and then an array of note start, duration and frequencies. You can add notes to it by calling addNote (they should be added in ascending order of note start for playback with MIDISound, any order is fine with CachedSound). The renderNote function renders a single note with the track's instrument to the correct position in the byte array. The render function renders ALL notes with the track's instrument to the correct position in the byte array (this can take some time). The prepare function ensures all of the notes are cached for quick playback, and runs asynchronously with a callback.

The Main class uses as3midilib (https://code.google.com/p/as3midilib/) to load the midi song and add the notes to a Track class, and then plays it. This is relatively straightforward, but MIDI files don't give you note duration, instead they have note start and note end events. So I had to keep playing notes in a hash and then when I got the note end event update the duration. I've noticed some bugs with the MIDI loading, the division value isn't always correct (which is why it's 0.6/file.division instead of 1/division), and one file had events at the wrong times, but it mainly works with a little tweaking.

Finally, I have two playback classes. CachedSound takes a ByteArray of samples and plays it in a loop. This can play a rendered midi sound from Track.render, or whatever else you want. But, the render method can take some time, so I also added a MIDISound playback class. It allows you to add tracks you want to play, prepares them all so that all of the instruments are cached, and then will render and play the full MIDI byte array at the same time (it assumes notes are in ascending order of start time to do this). It will also loop, and after the first play it will render from a cached version just like CachedSound.

That's all for this experiment. You can hear an old MIDI song of mine (composed in middle school >_>) being played with a clear sinewave here: http://fancyfishgames.com/MidiPlayer (entire swf is only 17 kb!)

You can hear the same song played using the generateBlipSelect method of SfxrParams for the instrument here: http://fancyfishgames.com/MidiPlayer/blip.html (literally change p.resetParams(); p.waveType = 2; p.decayTime = 0.15; to p.generateBlipSelect(); to in the Instrument class do this).

And the source code plus all dependencies is here: http://fancyfishgames.com/MidiPlayer/MidiPlayer.zip (undocumented, but I explained most of it above). Feel free to experiment with MIDI files and instruments! Oh yeah, the Main.status.text lines are just there to set that one line of text, feel free to remove!

If you have questions, feel free to ask!

Pandora's Box Direction

Recently, sandbox games have gained a lot of popularity. Sandbox games allow the player to be creative, and provide many options for playing and solving problems. This freedom is what makes sandbox games so interesting, but it also usually correlates to a lack of direction in the game. In linear games, the player is constantly directed, with the game difficulty slowly increasing to challenge the player and keep them engaged until the end. With sandbox games, the player is usually thrown into a world and gets to do whatever they want. But without any direction, challenge or "end," instead of keeping the player engaged, the intrigue of the game will slowly wear off and they eventually stop playing. While obviously gameplay evolution and direction could keep the player engaged longer, adding strong direction would only ruin the freedom and spirit that makes sandbox games so successful.

A very successful sandbox game that has very little direction is Minecraft. I recently played the game, and enjoyed it a lot. In the beginning, there was a simple goal: survival. There were many ways to be creative to accomplish that goal - building structures, digging trenches, mining resources, crafting equipment, growing food, etc. Eventually, my fortress became impenetrable by the enemies in the game, and direction was lost. Survival was guaranteed, and from that point on, the game was all about exploring, experimenting in the world, and being creative. The multiplayer aspect improved this part of the game, as you could show your inventions to friends and work together on building projects. However, eventually, without challenge or direction, the game started to get dull. This is not to say Minecraft is a bad game, it entertained me for a long time before it got dull. But, I think with more direction, the game could have been even better and lasted even longer. For instance, I did create a netherword portal and explore it a little out of curiosity, but given there wasn't much there of value and it was very dangerous, I stayed out of the netherword for the most part. I feel like if there was direction, a reason to enter the netherworld, that could have added a whole new part of the game where I had to leave my comfort zone and learn to deal with the new challenges and enemies of the netherworld.

A smaller, less well known game by the same developer, is called Minicraft. Minicraft was made in 48 hours, and on it's surface, it looks a lot like a 2D version of Minecraft. However, Minicraft provides direction throughout the entire game without ruining the sandbox feel. The goal of the game is not to survive, but to defeat the Air Wizard. To defeat the Air Wizard, you'll need Gem equipment, and to get Gem equipment, you'll need to go down three levels of caves, each more dangerous than the last. The game suffers from rough edges and poor balancing due to the short development time, but there is direction to the game and the difficulty increases as you progress, without FORCING the player to do anything, keeping the freedom and spirit of sandbox games.

This form of direction I like to call Pandora's Box Direction (or player-initiated direction). Whether due to curiosity or need, the player is compelled to open Pandora's Box. Like in the myth, when opened, Pandora's Box increases the challenge and difficulty of the game, forcing the player to learn how to deal with that challenge by manipulating the sandbox. Quite possibly, in order to deal with the new threat, they feel compelled to open a new Pandora's Box, helping them deal with the first threat but releasing an even bigger threat. This creates a chain of direction, that always keeps the player on their toes and continues to give them reason to build and modify their sandbox. This chain allows the developer to balance the challenges at each box, but ultimately leaves the decision of when to open the box up to the player. This kind of direction can also create a plot, where at each "box" they learn something new, and are lead slowly but surely to some final confrontation. The direction could be completely linear, but because the player is given freedom of when to open the boxes, and freedom of how to deal with the new challenges, the game retains it's creative sandbox feel. It's like recreating that exciting first stage of Minecraft many times, each time with new enemies, challenges, and resources to keep the player engaged. For example, in Minecraft, mining diamonds could unleash a dragon from underground, who is angry you stole its treasure. Because the dragon can fly and burn wooden structures, players would have to completely rethink their defenses. And perhaps the best way to slay a dragon is to use a magic system, which requires resources unique to the netherworld, opening up a whole new pandora's box.

Sandbox games without direction can still be great games, but I personally believe that the challenges should continue evolving, so the difficulty never bottoms out. A player shouldn't quit the game because they end up finding it dull, but because they have reached some climax and ending. The Pandora's Box method is the best way to achieve this while staying within the open style that sandbox games create. I plan to experiment with this method and hope others do too!

Being Indie is Selling Yourself?

So, awhile ago I wrote a blog post on what I personally felt being indie was. You can read the full post here: http://david.fancyfishgames.com/2012/11/what-is-indie-game-developer.html, but the basic gist was that being indie meant making the game you personally wanted to make, meaning your decisions aren't dependent on investors, bosses, even the market. While this is an interesting definition, it seems that culture of "indie" is quickly devolving into something far different.

What is the difference between a multi-million dollar AAA company, and a multi-million dollar "indie" studio? A lot of people have this idea that a AAA company is a faceless evil, and an "indie" studio is a team of hardworking developers giving their all. Does this mean that the employees of a AAA company aren't hardworking, or that AAA games are soulless? I've played many amazing AAA games that certainly were not soulless, made by passionate developers simply published through a company. Yet there seems to be shame in AAA game dev, as proof, look at the recently trending #indieAAAconfessional. Why should people be ashamed enough that they have to confess to enjoying a AAA game? What is the big difference between being "indie" and being AAA - aren't we all just game developers?

The difference (despite what most people would claim) as far as I can see it is not the amount of money or evil, but the face. An "indie" studio is transparent, you know who works there, and you know their story. This is not true with AAA games. While you can find out who actually made the game, what you typically see is the brand and the company, not the individuals. And because you can't see the faces of most of the people making AAA games, you view it as faceless, soulless, perhaps even evil. Conversely, being "indie" is becoming more and more about selling yourself and your story, with the game itself becoming secondary. Games like "Unemployment Quest" are successful because of the story of the developer behind the game, not because the game itself is any good. Look at most indie games and kickstarter projects, there is so much material on the development and the team behind the game. Most videos for kickstarter projects have a lot more footage of the developers than the game itself, even if there is a prototype and a decent amount of gameplay already.

Now, I'm not saying that all small development teams are pushing their stories, nor am I saying that it's bad to have transparency and individuality. But, I don't think the development stories should be more important than the games themselves, and I definitely don't think that selling your personal story makes you any better than AAA game companies. So, if you're belittling AAA game dev and idolizing "indie" game dev, get off your high horse and start making good games.

Can You Escape?

First off, if you haven't played "I Can't Escape" yet, do so now, it's freely available here: http://www.newgrounds.com/portal/view/610205 . The following post will contain spoilers, and should not be read until you've played at least once.

---

So, at this point, you should have played "I Can't Escape." You honestly tried your best to escape, and found yourself being plunged deeper into darker and eerier levels. This part of the game is designed to psychologically invoke feelings of being trapped and helpless. Even though you had full control and nothing really jumped out at you, you probably felt scared, or a little panicked near the end. Now you wonder, is it possible to escape? You were likely never close to being able to escape, but that was probably because you accidentally fell into some pits, and maybe if you did something different, you could escape. There were even signs of hope in the game, like ladders you could climb. Now I'm going to taunt you and tell you that you can escape, and then show you this video that shows a playthrough where I escape.

Now I recommend you play again, and maybe with the information you were able to gather from the video, you'll actually be able to escape!

---

Still weren't able to escape? Starting to think I'm trolling you, and that my escape was a hack? Well, it was no hack, and anyone can do it, but the video makes it look a lot easier than it is. Below I'll give you a few more hints that may help you.

The first thing you need to be able to do (if you aren't able to already) is to recognize hidden pits and hidden doors. The easiest way is to see them side-by-side and notice the differences:

On the left is a normal wall, and on the right is the hidden door. The cracks of the door can sometimes be hard to see, but there is more moss on the hidden door, making it greener as well.

The hidden pit is still black where the pit is, but it has green moss growing over it which makes it difficult to see. If you move carefully though, you should be able to avoid hidden pits.

By avoiding hidden pits and using hidden doors, you'll be able to explore a level much more effectively without falling. Even though most ladders are blocked off by pits or walls, in the video, I was able to break through a cracked wall by bumping into it, exposing the the ladder I used to escape.

It wont be easy, it may even seem impossible, but if you never give up, you CAN do the impossible - escape in I Can't Escape! I'll leave you with one final hint: It is no coincidence that in the video, I was on the second floor and had to climb back up to the first floor before I escaped.

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!

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!