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!