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.