This is has become a new motif in my daily routine. Like the repetitive “dah-dah-dah-DUHN” of Beethoven’s 5th symphony, I keep reloading a web page to check how many people have clicked a button to say, “Yes, I would buy Jumpsmith if it were on Steam.” How has this new habit crept into my life?
Jumpsmith is a difficult-yet-forgiving platformer with truckloads of interweaving mechanics. Level editor features are unlocked by playing through the huge main quest alone, or with friends. You can create expansive worlds with your controller, and swap between testing and editing with a single button. It took many hard, rewarding hours to code the game engine, create pixel art, design 300+ levels, and finish production.
I first uploaded Jumpsmith to itch.io about a month ago, but I consider this to be a starting line, not a finish line. Many people do aggressive marketing long before release, but I think there’s something to be said for having a completed product to sell as soon as you get a customer’s attention.
Steam’s website is flooded with potential customers. Greenlight submissions get hundreds of views and comments, sometimes within hours or minutes. Most of the games will never get into the Steam store. Knowing this, I think of Greenlight as a tool for exposure, not a golden ticket.
In less than one week, over 1,300 unique visitors have seen Jumpsmith’s Greenlight page, and it’s yes-vote ratio is 4% better than the average top 50 game. There are “Buy it now” buttons in the trailer and in the description. A scout for IndieGameStand.com saw it, loved it, and featured it on their front page!
I still hope that Steam choo-choo-chooses Jumpsmith. I’m still many sales away from recovering what I’ve spent on controllers, running my generator, and going to IndieCade East, not to mention what I could have earned at a real I.T. job last year. However, certain opportunites may not have arisen if I had rushed the Greenlight campaign. If I do get the coveted “Your game has been Greenlit!” email, I’ll be able to upload Jumpsmith right away.
Here’s Jumpsmith on Greenlight:
Get Jumpsmith now:
Today, I’ve decided to do a “Pre-Mortem” on Jumpsmith because while the game is complete and available right now, there have been more people in space than there are people who have heard of Jumpsmith.
First, let’s look at some numbers:
Yep. 7 copies (so far) of a $10 game for 14 months of work (so far). Sounds like my marketing guy (me) has been slacking off. Luckily, my game designer (also me) has an ace up his sleeve. (Hopefully).
As the proprietor of a mostly unknown one-man game studio, one must think about what compels people to tell their friends about a game. Word-of-mouth seems to be the best solution to the visibility problem. It worked for games like… Minecraft.
Why did people tell each other about Minecraft? There are many reasons, but I think that the biggest reason was that players can make stuff in the game. I think it’s easier to inspire someone to passionately say “Check out this thing I made” than it is to inspire them to say “Check out this thing this goofy-looking nerd from Maine made.”
I realized this over a year ago while I was watching Minecraft: The story of Mojang. I decided to start making a game where you could make stuff. I wanted to change the formula a bit, though. I wanted to have a paper-thin yet definite separation between playing and creating, and I didn’t want resource collection to be part of the gameplay.
The first button that I programmed into Jumpsmith was the “Toggle Level Editor” button. Right away, you could instantly swap between moving a character and placing square tiles. I also made button guides right away, so that the player could see what all the buttons did in the level editor at all times.
I knew I was on the right track when I first showed off a build of game at a local game developer meeting. A few kids were glued to my laptop for hours, making horrendous, nearly impossible levels, and sadistically challenging each other to complete them.
Over the following months, I continued to bring the latest builds of the game to the meetings. Developers and gamers ruthlessly played the game, made levels, broke stuff, told me what sucked, and what was awesome. I listened closely, and tweaked the game. I added local multiplayer, which enabled more people to test the game at once, and opened another dimension of enjoyment to the game.
Around October, I talked my friend/former bandmate/former roommate Tyler Quist into doing the soundtrack for Jumpsmith. Many of my game development hours were greatly enhanced by listening to his band, Jaw Gems, and their hip-hop beats with space keyboards just seemed to magically meld with the surreal-yet-retro Jumpsmith universe.
In December, I decided to push for a January release, and I started working about 50 hours a week on finishing the game.
In January, I decided to push for a February release, and continued to work about 50 hours a week.
On February 26th 2015, I FINALLY put up a build of the game. I only told members of my dev group, so I could find and fix minor problems. Over the following weeks, I’ve put out two patches. I added some requested features, fixed bugs, and continued to polish the game. I think this was a good move.
Now, I’m finally ready to start reaching out to press, YouTubers, Steam, etc. I plan on doing more blog posts soon about my battles with buggy video software, Greenlight, annoying video software, tech support, and horrendous video software. Sure, 7 sales is not a very impressive number, but I’m hoping that players will start sharing their levels, and making videos of their levels.
If you want to get Jumpsmith, click here.
Found Time Games on Facebook
Found Time Games on Twitter
For many years, lighting effects have been almost standard in games. There are many tricks that developers have used over the years. If you play Super Meat Boy, you’ll see shadows change as platforms in the level appear, disappear, and move. In Monaco, they used ray tracing to shade all the areas that are not in a player’s line of sight. In Limbo, there are layers of fog that partially obfuscate the silhouettes of the game. These methods are awesome, and they can make a game look very polished and professional. However, they tend to require certain capabilities from your graphics library. Today’s blog post is about how to fake some 2d lighting with very simple tricks- no shaders, no raytracing, no alpha blending. Just pure, solid, pixels.
If you think about it, a perfectly dark room would be… well…. black. While making a playable game with a 100% black screen might be a fun challenge, we’ll probably want to make the players and the space around the players have lighting. It would be possible to do this Dragon Warrior 1 style, where the player would be at the center of a 100% lit rectangle, and the rest of the area on the screen is black. The problem with this method is that it looks pretty unnatural to have a perfectly straight line between lit and dark areas.
Lucky for us, there’s an old pixel art method that we can use to “smooth out” transitions. It’s called dithering. Wikipedia defines dither as “an intentionally applied form of noise used to randomize quantization error, perventing large-scale patterns such as color banding in images.” Yikes. In the context of this post, think of dithering as gradually increasing the number of black pixels. This is what dithering looks like:
If we make the screen all black except for the area around the player, and then use dithering to smooth the transition of the visible area, we’re most of the way there. This is pretty much what I did in the underground levels in Super Pooper, only I had an alpha-blended border instead of a dithered border:
However, how are we supposed to handle multiple light sources in the same room? The lighting is not very dynamic if you are just drawing the exact same black rectangle with the exact same dithered hole all the time. Also, if we just pasted two of those rectangles on top of each other, the illusion would be quite broken when they intersected.
Never fear, though. I found a sweet way to fake this and make it look awesome. Every frame, make a black rectangle. Next, you’ll need a dither pattern that you can draw onto the black rectangle. The pattern needs to be made up of solid pixels, and they need to all be the same color. Any color is fine, EXCEPT black. I use an ugly pinkish color, with the RGB value of 255, 0, 255. Every frame, draw the “visibility holes”, i.e. dither patterns, onto the black surface in the appropriate areas.
At this point you should have a big rectangle of pixels. Each pixel should be either black, or the other color. Now, tell your game to not draw the pixels of the non-black color on that surface of pixels. In SDL and SDL2, this is called a “Color Key”. Bam! Now, you can have cleanly interconnecting visibility holes in your black room.
You can take it another step further if you use a few different sized dither patterns. This gives you a bit of a flickering effect. In Jumpsmith, I have 5 slightly different dither patterns that the game cycles through every frame.
But…. what if you don’t want the whole room to be dark? What if you want the room to be relatively lit, but with some dark corners? Of course, it is possible to just draw a layer of darkness over everything, but there is one more trick that I used in Jumpsmith that is simple and easy to emulate.
The game has a feature that I call “Doodads”. These are animated things that can be put in a room. The players cannot interact with them, they do not affect the gameplay, but they do add some visual ambience to the game, and they keep the rooms from looking super bland and static. They were really easy to implement, the game just grabs six 32×32 pixel squares from the tile sheet, and cycles through them. I used them to make little fluttering flags, waterfalls, and pistons.
One day, I realized I could make a doodad that was just a dither pattern of black pixels. The pattern would just move up and down a few pixels each frame. When I want a room to feel semi-lit, I just put rows of dither doodads on the top and bottom of the screen.
So, if you want to have some neat lighting in a 2d game and you don’t want to bother learning shader languages, you can do a few lighting effects with a basic 2d software renderer. Dithering, color mods, and simple animation can make a basic game look pretty awesome.
If you have any questions or comments, you can leave a reply here or contact me on Twitter @foundtimegames or email me at firstname.lastname@example.org
Notice: You can get Jumpsmith here ….You can troll your friends in local multiplayer, create levels with your controller, use custom tilesets and characters, and play levels created by the community.
Notice: You can get Jumpsmith here
It’s really important to me that Jumpsmith works with multiple joystick models, and remembers the button configuration of those models. I’m programming with SDL2, which does have its own struct for joystick data. However, I’ve found it is best in the long run to create what is called a “Wrapper Class” which has an SDL joystick struct as an attribute. This way, you can add more methods and attributes to your joysticks as your game develops. Using these wrapper classes, I was able to whip up a button mapping UI in about an hour. Here’s my story:
A few nights ago, my Logitech Xbox controller started to fail. The OS was suddenly sending the game “Unplugged” and “Plugged In” events for the joystick, even though the USB was firmly plugged into the side of my old trusty laptop. My other gamepads were working fine… it was time to run to the store.
Jumpsmith only requires 2 buttons to play, but if you want to make levels with a controller, you want 8 buttons. While I was looking around at Video Game Exchange in Augusta, I realized that an SNES controller had the exact right amount of buttons. They had one with a USB connector. Jackpot!
Every joystick model that is manufactured has its own button configuration, name, and a unique GUID. The button assignments tend to be pretty random. For instance, if you press the A button on a Retrolink NES USB controller, it tells the game that button 1 was just pressed. If you press A on a Yobo SNES USB controller, it tells the game that button 2 was just pressed. On an Xbox contoller, A is button 0. A few months ago, I manually entered all of the data for the 3 joystick models I owned into a little sqlite3 database. With a new model in my arsenal, I figured it was time to suck it up and make a menu that allows players to configure their own joysticks.
In the Jumpsmith engine, I have a wrapper class for joysticks, and a separate class for joystick models. When a player plugs in a controller, the game compares the joystick’s GUID to the models that it knows. If the GUID is known, the joystick object copies the attributes of the matching model. If the GUID is not found, it defaults to interpreting the new joystick as if it were an Xbox controller, and it creates a new joystick model object.
The button mapping UI turned out to be really simple, since I had a healthy codebase. It just asks the player to press the button they want to use for jump, sprint, start, select, etc. Then it stores their choices in their joystick object and in the appropriate joystick model object. The models are saved whenever the game is closed.
UPDATE: You can get Jumpsmith here
Jumpsmith is in the late polishing stages right now. I’m planning on selling it on jumpsmithgame.com and submitting it to Steam Greenlight in January 2015. If you have any questions or comments, you can reach me at email@example.com or on twitter @foundtimegames … also, you can leave a comment here.
UPDATE: You can get Jumpsmith here
I’m happy to announce a new feature I’ve added to the Jumpsmith engine – arbitrary particle systems. I’ve been doing some research and looking at a ton of games, art, and movies, and I was trying to think of some cool things that I could implement to provide a little more visual spice. The game already had particle systems, but they only were being used when something exploded or crumbled on the screen. So, I gave every room an array of 10 regenerating particle systems that could be activated and placed anywhere on the playable area of the screen, and they can be set to behave like fire, smoke, dripping water, sparks, dust, glowing dust, crumbling stone, or a water fountain.
If you aren’t familiar with particle systems, they are a kind of data structure that has been used in computer graphics for many years. Think of a particle system as a thing that has many little objects that move around on their own. For many effects, each particle has an x and y position, a velocity, and a lifespan, each of which are randomized within certain bounds.
Example: You want to make a little puff of smoke on the screen. You could set up a particle system with 10 particles, and make all of them move either 1 or 2 pixels up towards the top the screen every time the screen updates. You could also make them come out of a random location within a 5 by 10 pixel rectangle on the screen, and make each particle disappear after 10-20 screen updates.
Of course, it would take some programming to get that all to work, and to work efficiently. Luckily, if you’re making a level in Jumpsmith, you don’t have to think about those details. I made a slick user interface that lets you set up particle systems with your game controller or keyboard. Of course, if you’re trying to make your own game, I suggest checking out this book to learn about how to program your own particle systems.
I’ll keep you posted every week with more updates about the game… I’m working many hours in hopes of releasing Jumpsmith within the next two months. Please let me know if you have any ideas or suggestions.
UPDATE: You can get Jumpsmith here]]>
UPDATE: You can get Jumpsmith here
It’s been a busy week at Found Time Games… I’ve been working on the community website for Jumpsmith. Here’s a screenshot of what I have so far:
You’ll be able to download, rate, and share game levels, characters, and tilesets. If you’d like to try your hand at making a character, you can use this blank character template and upload it once I add the upload functionality to the site. Please let me know if you have any questions. My email is firstname.lastname@example.org
On a side note:If your car gets stuck, you can connect two winches to a tree and turn your arm into a tow truck!]]>
1) Valgrind is an amazing tool for C and C++ programmers. While it has many capabilities, my favorite way to use it is to check my game for memory leaks. Even a basic 2d game engine can get complicated really quickly… Jumpsmith loads a bunch of data from the hard drive, and valgrind can see if any objects should have been freed from memory when the game closes. If you are just getting into programming in C or C++, you should set up valgrind right away. It’s free, and it can save you from a lot of trouble. Here’s the command I use when I do a leak check with valgrind on a command line:
valgrind -v –track-origins=yes –leak-check=full –show-reachable=yes ./game > valgrind_out 2>&1
If you run this, you’ll want to replace ./game with the path to the executable for your game. The text file that it spits out will be called valgrind_out. Your game will be slow during the test, but you’ll get a detailed report of exactly which lines of code left a memory mess.
2) Sqlite is a serverless, zero-configuration, transactional SQL database engine. It is nearly ubiquitous… all Android and iOS devices have it installed by default, as well as Mac and Linux. It is a pain to use CSV (comma separated value) files for game data. Super Pooper used CSVs, and it sucked when I wanted to add or change features. I learned from my mistakes; all of the joystick data, game worlds, and player profiles of Jumpsmith are stored in sqlite databases. As I’ve evolved the game mechanics, it has been really easy to update the game world files with a nice little SQL statement. Also, if players want to make wacky scripts that edit Jumpsmith levels or create procedural content, most scripting languages have a sqlite3 API. Sqlite3 is public domain, so you can use it for commercial software.
3) Simple DirectMedia Layer is an open source gaming library. It provides a layer of abstraction between you and the user’s OS. You can use SDL functions to create a window, get mouse, keyboard, and joystick events, play sound, load images, do threading, etc. It has been used by many games, such as:
-Mark of the Ninja
-Super Meat Boy
Note: I made this list by searching the Games directory on my Linux laptop for SDL files. Some of these games have other versions that do not use SDL.
SDL2 is the latest major version, and it runs on PC, Mac, Linux, iOS, and Android. That’s right- you can write a game in C or C++, and then recompile it for 5 major systems, and probably not have to change a line of code. I’ve seen a video of a PC game that was recompiled for iOS, and SDL interpreted the screen touches as mouse events, and the game was playable without changing any code. Of course, if you want to get a little more in-depth with handling mobile-specific stuff, SDL can handle events like Low Memory, App Terminating, entering foreground, etc.
I think that making your own engine with SDL can be really beneficial in the long term- Jumpsmith will be released on Windows, Mac, Linux, and Steam OS, and I won’t have to pay royalties to a game engine company like Unity, which can be expensive.
UPDATE: Jumpsmith is available now!
Game porting guru Ryan Gordon has done a few talks where he discussed these tools and several others, you can check them out here and here. I hope that this information is useful to you on your next game!
When I was creating a platformer engine back around February of 2014, I made a function that renders a little floating message on the screen. The message slowly floats upward, and erases itself after a couple seconds. I think I set it up originally for error messages, or for debugging, I don’t remember. At one point though, I got an idea: “What if I made the game display a random wise-ass comment every time the player dies?”
My friend, William Kinrade, and I used the engine to create a thumb-melting platformer of insane difficulty called “Meet Meat on the Street” for a cyberpunk game jam. Needless to say, anyone who played the game would get to see plenty of death messages. We had a blast coming up with a big list of snarky discouragement. We mined a thesaurus, movie quotes, song lyrics, and even TV episode names to populate our list of death idioms and taunts. Some of my favorites were “Should have had life insurance”, “Always look on the bright side”, “Try a Different Strategy”, and “Again, with feeling”.
I didn’t think much of it at the time, but those messages happened to be a favorite feature for everyone who tried the game.
When I rewrote and polished the game engine for my upcoming game, Jumpsmith, I was sure to keep the taunt messages. I’ve given myself very specific guidelines of what is required for a taunt. I decided that it has to be a phrase that has a word that rhymes with or has alliteration with “fail” or “lose”, with the appropriate substitutions. Some of my personal favorites in this incarnation are “Ahab and the White Fail”, “The Moody Lose”, and “Encounter at Failpoint”.
Also, this time around, the taunts are read from a text file. Players who pick up Jumpsmith can make their own lists of taunts. This goes along with the philosophy of the rest of the game: I want people to be able to customize their experience as much as they’d like. It’s super easy to make levels, add custom tilesets, and add custom characters. My goal is to encourage players to be creative, and to give them as many tools as possible to have an amazing gaming experience.
Follow me for updates, humor, and random observations:
UPDATE: Jumpsmith is available now!
Facebook: Found Time Games]]>
The first thing I do is add a checkpoint. While designing a new level, I play the heck out of it, and I end up falling on many spikes and jumping directly into many fireballs. With a checkpoint, I don’t lose any time running back into the test area.
Next, I try to think of a new way to use the mechanics. The shooters, which are little cannons that launch fireballs and other various objects, can be set to shoot whenever a player jumps. I’m going to use that feature in this room, so I’m going to make some spike tiles that obstruct the player’s path across the room. They’ll have to jump to get over the spikes, and that will trigger the shooters.
I think it’ll be cool if the shooters in this room are shooting towards the player, so they’ll have to go “upstream”. In this screenshot, I’m using the directional pad to tell the shooters to launch fireballs to the right, towards the checkpoint. Notice that the level editor tells you exactly which buttons to use on your game controller to make the level.
To shake things up a bit, I’m going to make the top shooter launch a spike boulder instead of a fireball. The spike boulders will shoot up and to the right, and gravity will make it fall down in a nice arc.
Time to test the game! In Jumpsmith, you can press ‘M’ or the back button on your controller to instantly swap between editing and testing a level.
The test went well, but I still want to add one more object to really tie the room together. I haven’t put any nice oriental rugs in the game, so I’ll use a spring. The spring is going to be interesting because it’ll allow players to get the effect of a jump without triggering the fireballs and spike boulders. As a bonus, it’s fun to see the spike boulder get launched off of the screen by the spring.
The basic idea of the room is done at this point. If I was making a game just for myself, I could probably call this room done. However, I’m making this game for other humans. They might find this room to be too hard, so I’m going to raise all of the objects two squares so they can just run underneath it and get to the next room if they get frustrated.
Of course, I still want to reward the players who can get by the trap, so I’ll add a coin and make a wall that is just high enough to keep out players who skipped the obstacles. I’ve also added another spring, so people can get the coin without triggering the fireballs.
The final step is to pretty up the room. I can change which graphic is drawn to each tile without affecting how players interact with it. At this time, Jumpsmith tilesets contain 49 possible graphics for each kind of square. Also, there’s nearly 150 different tiles for foreground art. Most of the foreground art is set up to interlock and/or tesselate; that’s how I made the big torn banners on the top of the screen, and the columns at the bottom of the screen.
That’s it for now! I hope you enjoyed this. Jumpsmith will be available soon for PC, Mac, and Linux. You’ll be able to make levels of your own, and have up to four people explore them at a time with local multiplayer. Be sure to follow this blog, twitter @foundtimegames, and Facebook for updates!
UPDATE: Jumpsmith is available now!]]>
So, how does one come up with a good mechanic?
Some people who are smarter than me have said things like:
“A good video game presents a series of interesting choices for the player to make.” -Stephen Totilo of Kotaku.
“As a designer, you want to explore each mechanic and make sure it can be enjoyed in 3 or 4 different ways” -Edmund McMillen, creator of Super Meat Boy and Binding of Isaac
“Mathematicians talk about beauty. They seem to agree that the shortest theorems that carry the deepest consequences are the most beautiful.” -Mark Ten Bosch, creator of Miegakure
How can these concepts be applied to a game?
Well, one of the first objects that I made in the platformer was what I call a “Shooter”.
First Iteration: The shooters could be placed anywhere on the screen, they would shoot fireballs that would move in a predetermined velocity. Each shooter has a timer, and you could adjust the amount of time between shots, and adjust the amount of time it would wait from when the screen loads to when it does its first shot.
This is a very basic mechanic that is almost ubiquitous amongst platform games. It felt nice to get that implemented, but I knew that more could be done with it. What if I changed the properties of the bullets?
Second Iteration: Bullet types! What if the projectiles have weight? I did make some basic physics stuff already. I made spike-covered boulders that were affected by gravity as soon as they were launched. Not long afterwards, I had implemented springs. If an object touches a spring, it gets launched in a specific direction. What would it be like if the shooters could launch springs? Now you can have one shooter launching springs, and another launching boulders. The launched springs could either be weightless (like fireballs), or weighted (like boulders). The last bullet type that I added was a moving platform. They also can be weighted or weightless.
So…. the shooter can launch 6 different kinds of projectiles. What else can we do to riff on this idea? So far, the shooters always launch objects in a predetermined direction….
Third Iteration: Rotation! I am no genius, I’m just a peasant who lives in the woods and plays guitar. Luckily, math geeks love to explain math on the internet, so I was able to figure out how to rotate vectors by arbitrary numbers of degrees. Now, any shooter can be set to rotate 15, 90, 180, or 270 degrees after every shot. While I was banging my head against the wall, trying to get the math to work out, I stumbled on a really fun way to do rotation….. player position! The shooters can be set to rotate as you move left and right, or up and down.
At this point, you can see how each mechanic creates nearly exponential new possibilities. However, there’s still more that we can do.
Fourth Iteration: How does the shooter know when to rotate, and how does it know when to shoot? In the previous iteration, some shooters were able to rotate based on player movement. In a basic platformer, the basic ways a player can interact with the world are:
So… we had just tried tying rotation to X and Y axis motion…. what if we make it so the shooters only launch an object when the player jumps? What if we make it so the shooters only rotate when a player jumps?
Fifth iteration: Shot and Rotate Triggers. A shooter can be set to shoot and/or rotate based on its timer, on the room’s timer, whenever a player jumps, whenever an object collides with it, or when a switch is activated.
I’m hoping that people like Stephen Totilo will enjoy the game, because he’ll be able to make decisions about rotating and firing the shooters as he plays. Maybe Edmund McMillen will appreciate seeing a basic shooter mechanic get “juiced” in multiple ways. Perhaps Mark Ten Bosch will appreciate the multitude of wacky rube-goldberg consequences that can come from this single object in the game.
You can judge for yourself very soon if this is a good mechanic or not, I’m hoping to release this game in the next few months. There is a big metroid-vania-esque world that you’ll be able to explore, and you will be able to make and share your own worlds very easily.
UPDATE: Jumpsmith is available now!]]>