If one thing is certain, I am terrible at updating my website. I received no less then a dozen emails asking me if I was alive (yes I am). So if you came back daily for six months looking for an update, sorry :(.
There’s several things I’m doing, have done, and in the process of thinking of doing. But the biggest one is Sandbox Hero.
About two weeks ago, Sandbox Hero came out of private beta and into public beta. I can’t be more proud of what has been accomplished so far in this game.
Sandbox Hero is a game about creation, exploration, play, and community. In the vein of other level creation games such as Little Big Planet, Minecraft and Everybody Edits, Sandbox is all about player-creation. Players make their own maps from start to finish (literally), placing obstacles, enemies, and pathways to the exit. In addition to building maps, a large component of the game is playing other people’s maps, where you earn XP and coins to level up your player. It is both RPG and creation toolkit, and soon, some multiplayer components. It is the most ambitious project I have pursued to date.
I wanted to talk a bit about the last few months of production and the way this game came to fruition.
When I first approached this game I was thinking of something very simple… much smaller than what was eventually created. I wanted to make a game based around a level editor and sharing system. I love platforming games, and I love level editors, so why not create a level editing platformer system for the players? The goal was to provide maybe, 8 to 10 tiles and let people do very simple levels with them. In fact I created the editor screen seen below as a mockup of what the final product could possibly look like:
The game was going to take place completely in this editor space. There would be no hub for equipment, levels, etc. Load and save would all take place through this window and it would be purely an editor.
As I developed the engine more, I realized the scope could take this game well beyond what was created. What other features could this game have? How could I build this game looking forward, so I could add even more features in the future? I spent a lot of time on these questions, trying to balance what this game should have or not have all at once while managing time and priority for features. I could go as far as full-multiplayer with real-time everything, or pull back to just simple level code sharing. In the end, I decided to find the middle ground at asynchronous multiplayer and to scale up from there. But even that was not a simple path. The beginning of this game raised many questions I didn’t anticipate for the end-game.
There was five major problems and solutions I had to attack:
1) Building Content Intuitively
Many players have never made a level before. Some players use level editors all the time. I wanted to make a system that worked easily for all experience levels. I spent a lot of time fielding feedback and information on what sort of editing tools players wanted and implementing changes with each version, as players tested new builds. More time has been spent on the editor than anywhere else.
The editor features are very simple if you want them simple, but if you want to dive deep into your creations, the editor is built to be as intuitive as possible. You start with the tools in the toolbar on the far left and pass across the screen to the right, eventually ending in the Publish screen. Everything is meant to be explored left to right.
When building the editor I wanted to make sure that adding new content would be easily done. I went with a top-bar tabbed approach so that new content could be expanded easily. I built a window system to make new editor windows very easy to build. Everything was built for expansion.
2) Sharing and Discovery
Sharing is the most difficult part of this game. I needed a way to facilitate transfer of maps between players in a way that was easy and quick. There were a few ways to do this:
Human-to-human Level Sharing: Copy-and-paste level codes are simple and easy to implement, but they are not great to sort or manage. The game started out with these but quickly moved on.
Kongregate Level Share: Kongregate has their own level share system, which is a very simple and prebuilt system that makes it easy to add level sharing to any game. It works great, but I realized quickly that I need to sort levels in very different ways than what was being offered by this level share. So I realized I had to keep moving on.
Player.IO: Bingo. This was it. Player.IO is a service that provides multiplayer/database services for online games. I needed a database that players can search and filter through to find content, but not have to worry about scaling or crazy management tools. This is harder, but easier on the players to find great stuff. I had to learn how to program in C# to write server code and it added several weeks to my production time, but it was well worth it. Now players could sort and filter maps by type of map, last published, etc.
After realizing that I now had access to a multiplayer database, I started debating multiplayer. After working on Exit Path and other synchronous multiplayer games, I realized that this was a stretch. This game already had a lot of sharing features and some planned asynchronous multiplayer features, so I decided to hold off until later pending success of the game. Going forward it could be possible but I don’t want to say yes or no until I roll out more features.
As the game went through beta I learned a lot about what players wanted. They wanted more sorting methods and categories so they could find levels they liked. Some players like playing automatic levels (rollercoasters) and others wanted levels about exploration and story telling, which are completely opposite ends of the spectrum in level design. I built categories and special lists specifically to their needs and continue to do so.
I made a few maps but realized that people might be making ridiculously big maps. Instead of limiting size, I decided to start optimizing the hell out of the game so that limits could be minimal. I made my own compression algorithm for making maps tiny, and used some other compression algorithms to further compress maps. I spent a few weeks getting maps down to about 15% of their uncompressed size. Load times stay relatively quick for their thousands of tiles.
Secondly performance. Displaying thousands of tiles is incredibly difficult in Flash, especially interactive or animated tiles. I decided to try my hand at Starling, a framework built on-top of Flash that leverages the graphics card for processing. This allowed me to render lots of content on-screen at great performance.
To maintain great animation for the player while maintaing performance I leveraged the Dragonbones framework.
To ensure that UI stayed sharp and flexible, I kept all my user-interface pieces in vector instead of bitmap. This was difficult since Starling is based on bitmap graphics, so I had to build a special wrapper to allow for both traditional vector and speedy bitmap processing.
4) RPG Mechanics
I spent a lot of time on level creation features,only to realize I was neglecting the actual play of maps. The game is user created, meaning there wasn’t a lot of plot or storytelling to offer, so I wanted to offer more sense of progress for the game. I added RPG mechanics which would allow for upgrading weapons and body pieces and allow players to grow in character while playing player’s maps. This also allows for personal expression through dressing up characters.
I spent a lot of time working with my coworker Anthony to build the RPG system for this game. He’s a bit of a data genius as well as very experienced in building extensive RPG systems. It took a lot of wiggling of numbers, stats, and information to build the system that currently exists now (still continues to be wiggled). The moment you add more jumping abilities or faster run speed it breaks many other features. Making a flexible weapon/item pickup system was difficult due to all the possible parameters the player could have. I narrowed it down to the following parameters:
Attack: Amount of damage to enemies
HP: Amount of damage a player can take
Dash: Amount the player could dash
Jump height: Height the player can jump
Jumps: Total number of jumps the player gets
Run: Speed the player could run
Each weapon and item changes these attributes.
An early realization is that some maps would be far easier to beat if a player was high level versus low level, and that some level designers wouldn’t want this to happen. In an effort to allow for self-balancing, enemies scale in difficulty with the player, so the player has to continue to get better skill-wise and item-wise to continue to compete well on levels. In addition, I offer a Pure mode to level creators so that they can set everyone back to level 1 temporarily if they want to.
5) New Features and Tiles
Most of my games are built as to a very specific experience, meaning that I have no plans of updating them once they go wild. In this game I knew I would want to keep working on it even after it launched. I had to ensure that I built all the systems to allow for expansion. New tiles are easily added through a built-in catalogue that I can add to very quickly New features , weapons, items, and enemies follow a similar system. Backgrounds, midgrounds, and music also had to have special systems added to them for simplicity in creating new content for each. The way levels are saved to the server account for
Being careful about being future-ready extended the production time but will speed up adding new content in the future.
Release and Future Of Sandbox Hero
The game went out of private beta a couple weeks ago and so far has been living up to my expectations, being warmly received. Players have been incredibly supportive of the game, providing bug reports and feature requests far faster than I could ever keep up with. The maps players are creating are phenomenal, and we are constantly surprised by the quality of content. Quizzes, Rollercoasters, Stories, Deathtraps, and more can all be found from a single game. I am extremely happy working on this project and seeing what the players will continue to create and share with the world.
The artwork by Jimp made this game really shine. Jimp has worked for years with me on games and he did not spare a detail for this game. I could not be happier working with him.
Sandbox Hero continues to be developed and will continue to be a work-in-progress. I really enjoy this project and love the community that has started to form around it. I will continue to work on it and give it the support and love I feel the players who help create it deserve.
If you read my previous blogpost I was working on a button pushing game. This game has been cancelled due to proximity and style to the vein of Cookie Clicker, which released before it could ever see the light of day. It was an unfortunate coincidence, but I’m going to use some of the material I was planning for the button pushing game in another project.
I’m currently working on a quick game which should this month. Its a small single-player game with no name yet, but it should be enjoyed by those who liked my minigame compilations of years past.
On Kongregate I helped create a metagame for the site called Kongpanions. A play on the word Companions, they are small, often cute creatures you are rewarded for beating and completing challenges on the website, specially through the Badge system. One step further, you can use the Kongpanions you have collected on the site in games such as Sandbox Hero! Its a fun system and rewarding to both developers and players alike.
Otherwise, I have a HUGE surplus of game ideas and concepts ready to unfold.
And in my personal life I’m watching the olympics, riding my bike, rock climbing, and playing video games (specially Papers Please, Legend of Zelda: Link Between Worlds, and Pokemon X).
I’ll try not to write updates once every six months any longer (sorry again), there’s a lot of great stuff coming up and I can’t wait to share it.