Here’s a two player co-op trailer that I put together. Kris was too busy working on other stuff, so I had to record this footage by myself. I controlled one goo by mouse in my left hand, one goo with the ASDF keys in my right hand and I set the ‘Q’ key to activate recording.
Development is almost done at this point. All the levels are complete, all the sounds are in, all the in-game graphics are done. Kris is working on the comics and I am working on pulling together the user interface (as well as doing PR stuff).
Update: Thanks for the Tasty Planet 2 name suggestions everyone, the name we went with was Tasty Planet: Back for Seconds. The game is now available.
We aren’t too far off from releasing Tasty Planet 2 so we really need to come up with a final name. For a variety of reasons we want to name it “Tasty Planet: Some Subtitle” instead of “Tasty Planet 2″. So far we haven’t come up with anything amazing. The game has you traveling to different time periods and eating them, so we have been trying to come up with a play on words involving eating and time travel.
“Tasty Planet: Snack to the Future” (a play on the movie “Back to the Future”) was one of our favorite ideas but we found out that another game already used “Snack to the Future” (and put a little trademark symbol on it), so that one is out.
A few other names that I don’t mind (but don’t love either):
Tasty Planet: Snack Time
Tasty Planet: Snack in Time
Tasty Planet: A Morsel in Time
Actually one of my favorites ideas is “Tasty Planet: A Link to the Repast”… Pretty funny if you’re familiar with “The Legend of Zelda: A Link to the Past”. Unfortunately most people will not get it.
We could also go the Die Hard route – “Tasty Planet 2: Tastier Planet”.
Or how about Tasty Planet: Too Tasty?
What do you think of those names? We would love to hear your suggestions!
Tasty Planet 2 is really coming together. I took some screenshots to show everyone what it is looking like (note that the HUD elements are not in there). Usually when I take screenshots to release to the press I spend a lot of time trying to capture the perfect situation (sometimes I even play the game in slow motion to make sure that everything is just right). Not so with the screenshots – I just quickly grabbed a few from different levels (the goo’s eyes are even in the middle of a blink in one screenshot – the horror!).
There are still a few tweaks that we need to do, but overall we’re really happy with the look. What do you think?
During development it is extremely helpful to be able to enter “cheat” codes. Often I want to quickly get to a certain part of a level to test out a new feature – so I need the ability to grow the goo quickly to a certain size or to increase the game speed. To do this I implemented a console screen in development mode, which allows me to type in commands. These commands are actually processed by the scripting language Lua, so they can be as simple or as complicated as I need them to be.
In addition to cheat codes, I can also quickly implement rarely used or complicated editing features instead of going through the trouble of adding a graphical user interface. Using Lua makes this particularly easy because the console commands act as a true programming language. I can query the status of certain game elements, store things in variables… anything that I need to do.
Having a console makes many aspects of development of much easier – that’s why so many games have consoles built in.
The game is really coming along. A lot of the art and levels are done. I’ll be posting some new screenshots and maybe a video soon.
Often times I want the creatures in Tasty Planet to follow a path. For example, if I wanted a car to follow a road, in the correct lane, and then make a few turns along the road, I could define a path for it to follow. I added a path creation feature to the level editor a few weeks ago to help me quickly define paths.
The art here is all old, but you can see a few test paths that I have created. The curve will go through the red points and be guided by the blue points (so I can sharp turns or smooth turns). If you’ve ever used an illustration or drawing program, it is similar to that. In Tasty Planet 1 I didn’t have a path editor, so I had to define the paths by manually entering coordinates into an XML file… not fun, and virtually impossible to do anything other than straight paths with occasional turns.
On a side note, the little ants that you might be able to make out in the screen shot are actually highly explosive… You see, I was implementing an explosion feature and I didn’t have any levels with objects that are actually supposed to be explosive, so I made the ants explode on contact with anything they touch… Not for the final game, but highly entertaining.
Tasty Planet is a game of scale. The player eats everything from the tiniest things to the biggest things in the universe. In Tasty Planet 1 the current size and goal size of the goo are displayed in the HUD. The game picks the most appropriate unit of measurement to use from the following list (some are never used because the goo never gets to the appropriate size):
Astronomical Unit (au)
Kilo Astronomical Unit (kau)
As you can see, the smaller units are all metric system, while the larger units are commonly used units in Astronomy (no lightyears because they are so close to the size of parsecs).
My main concern with these units is that a large portion of players (those from the United States) are more familiar with inches and feet than with centimeters and meters. That said, I think that I’m going to use the same units in Tasty Planet 2, but I’m planning on displaying the full name of the unit, instead of just the abbreviation. That way, even if some Americans might not know what a “km” is, I think they are more likely to have an idea what a “kilometer” is. Similarly, no one knows what a “pc” is, but they will probably at least recognize “parsec” from episodes of Star Trek.
Here is an image of a ruler tool that I added to the level editor, it lets me measure the size of objects so that I can easily set them to a realistic size. As you can see the mushroom is about 7.77 centimeters in diameter (about 3 inches).
The level editor is used to design and build all of the game’s levels. In Tasty Planet 1 the level editor was extremely basic. It had no copy/paste, no undo/redo, and much of the level data actually had to be defined manually in XML files. I had built a pretty good level editor for Three Musketeers so I decided to reuse it for Tasty Planet 2, as I had done with the animation editor.
The editor has all of the important features that we need to make levels quickly. Here are some of them:
Creation of all the different object types that we need
Rotate and scale objects
Cut, copy and paste
Unlimited levels of undo and redo
Zoom in and out so we can see small details or the whole level at the same time
In Tasty Planet 1 the animations were very simple. Usually they consisted of only two frames. Due to the quantity of objects that we wanted to put into the game we were limited by time and memory constraints, so we really couldn’t do any more frames of animation. Our constraints haven’t changed much for Tasty Planet 2 – we still want to put as many objects as possible into the game without using up a huge amount of memory, and without taking years to develop the game.
But we still want to make the animations better, so we’re taking a slightly different approach this time. We’re using an animation editor that was created for The Three Musketeers: The Game, with a few modifications to support interpolating between frames of animations. What this means is that we can split a cat up into head, body, feet, and tail, and then move these pieces around smoothly to give the illusion of a more complicated animation. A lot of 2d games (and TV shows, actually) do this nowadays – a good example is PopCap’s Bookworm Adventures, or more recently Plants vs. Zombies.
Here’s the editor:
It was originally used in Musketeers to enable us to create the animations of all the different types of clothes that d’Artagnan and the computer controlled characters could wear. I added a bit of functionality to do the smooth frame interpolation and now it works well for doing the Tasty Planet animations. It’s kind of clunky, and there are a lot of functions that we aren’t using anymore, but it does the trick.
In Tasty Planet 1 we actually didn’t use an animation editor. The animations were so simple that it was easier and faster just to enter the data by hand. Deciding when to build a tool is an important skill for indie game developers – unlike big game companies we don’t have dedicated tools programmers. Time spent building a tool is time that could have been spent building the game, so the tool better be worth it.
Over the next few weeks I’m going to do some posts about the tools that we’re using to make Tasty Planet. I’m not talking about the commercial packages that we use like Photoshop and Visual Studio; I’m talking about the editors that I have created specifically to help build Tasty Planet 2.
In Tasty Planet 2, as in most other games, we need to know when objects are touching other each other. When the grey goo is rolling towards a cat, how do we know that the goo ball is actually touching the cat (so that we can consume to defenseless little creature)? In Tasty Planet 2 I’m using the Box2D physics system to answer this question, but we still need to tell Box2D what size and shape an object is. Enter the collision editor:
It’s a simple editor that lets us choose the object to edit from a list on the left (the taxi is chosen in this case), and then we can add circles and polygons using the buttons on the right. The green lines overlaid on the taxi show the collision area – if another objects green outline touches this object’s, then we know that they are colliding. If the object is complicated, we can use more than one shape. In the case of the taxi we are using an 8 sided polygon.
This isn’t all that different from Tasty Planet 1. One improvement is the use of convex polygons (in Tasty Planet 1 we were simply using rectangles). But the main improvement comes from the fact that we are using Box2D to detect and resolve collisions, so objects will behave in a more natural way when they collide with each other.