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):
- Picometers (pm)
- Nanometers (nm)
- Micrometers (um)
- Millimeters (mm)
- Centimeters (cm)
- Meters (m)
- Kilometers (km)
- Megameters (Mm)
- Gigameters (Gm)
- Astronomical Unit (au)
- Kilo Astronomical Unit (kau)
- Parsec (pc)
- Kiloparsec (kpc)
- Megaparsec (Mpc)
- Gigaparsec (Gpc)
- Teraparsec (Tpc)
- Pentaparsec (Ppc)
- Exaparsec (Epc)
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.
We’re hard at work on Tasty Planet 2. This is roughly what we’re aiming at for the visuals (click to see full size):
This isn’t in-game. It’s just a rough mockup that Kris did in Photoshop but it should give you a good idea of what the game will look like. (Ignore the seams in the grass.)
You can see that we’re changing the design of the grey goo a bit. We haven’t animated it yet, but the idea is that the center mass with the eyes on it will lead the rest of it, so it will look like it has a trail of translucent goo behind it.
I'm gonna eat you!
I’ve been working for a couple weeks on a sequel to Tasty Planet. We haven’t finalized the story or setting for the new game, but we’ve picked a general direction and things are moving along. Here are some features that we have in mind:
- Larger scale in levels. We want the ability to go from really small to really large in a single level instead of spread across multiple levels.
- Many more levels. I’ve been working on tools to speed up our ability to generate content.
- New physics system. This will make object interactions feel better.
- 2-Player Cooperative play. Should be super fun for parents who like to play the game with their kids.
- New visuals. Kris has started experimenting with different visual styles.
I’ll be posting more as development continues.
This is an animated logo that Kris did for The Three Musketeers: The Game. We didn’t end up using it because it uses Flash and I was worried that in-game Flash support was a bit flaky. I really didn’t want to risk having the game crash for some people because of our company logo.
Dingo with Hat Logo (It was supposed to be used at 800×600 size)