Blocks That Matter: the tools
Hi everybody,
It’s time for a little tech post around the tools we use to make Blocks That Matter.
William wrote 2 successive articles, so I take the keyboard this week and we are going to talk a little bit about how we make BTM.
> Flixel as the root framework
I love Flixel, it’s a really “simple and funky” framework that wrap Action Script 3 and Flex functionalities to give you some useful base to make Flash games.
Moreover, we already used this framework to power Tuper Tario Tros. and Greek & Wicked experiments.
For a programmer, it’s really easy to get the spirit of Flixel. It’s maybe not the most optimal framework, but it greatly eases the game conception, and that’s all we need.
If you are looking for more complex frameworks to build flash games, you can take a look at Flashpunk or the Alkemi Flash Bitmap Renderer.
> Xna as the glue to get the game running on XBox
Since we wanted to experiment the Xbox Live Indie Games channel, we have to use the Xna framework. The framework is only available through the C# language… and as you may have guessed, Action Script 3/Flixel is different than C#/Xna. So we use the work of Ben Baird who ported the Flixel Framework to Xna. Ben already shipped 2 games on the XBox Live Indie Games channel, both of them powered by his Flixel port.
Thanks to his work, we saved weeks of development we could have spent porting the Flixel framework to Xna, and we can directly work with a framework spirit that we already know pretty well.
> Editing levels
As you may know, Blocks That Matter is a kind of spiritual sequel to our very first Deep Water Experiments: Tuper Tario Tros.. In TTT, William edited the level by writing in a big text file that looked like this:
Editing a level in such a simple file format is a quick way to have a “level editor” running since any notepad or spreadsheet application allows to build a level… But from a Level Designer point of view, it’s a little bit tricky to imagine what the level will look like and feel in game.
I was looking for an existing level editor and found a very good one : Ogmo Editor. But Ogmo Editor is only for strictly pure 2D games representation. Since we use a kind of isometric rendering, we need to be able to sort some sprites.
So for BTM, I decided to build a very simple level editor that would be an ingame one, allowing us to create a level entirely with a gamepad.
This allows us to make quick iterations when we build the game.
The editor is ruled by a unique resource file at a time. This file contains description for all actors, sprites and various parameters to tweak the game. Here is a simple example of the content of a minimal resource file.
Then when we launch the game with such a resource file and here’s what we can do:
As you can see, we kept the editor really simple, all the stuff is done with the gamepad, except the parameters tweaking system which uses the keyboard. A virtual keyboard could be used, but it will be a pain.
There are few editor features shown in this video:
- a cursor is used to put or remove elements from the level
- a layer system is displayed on the right of the screen, the layers are all displayed by default, but we can choose to mask the non current layers
- a library of blocks is displayed on the top of the screen, the blocs in the library depend on the current active layer (blurred in this video, we want to keep some secrets about the blocks)
- the cursor can change the nature of the block he’s painting by navigating in the current bloc library
- auto adaptive ground blocks visual depending on the surrounding blocks
- some visuals (like the herbs sprite) can be chosen randomly during the painting process
- we can test/edit the level (the player stays in position) or play/edit (the player starts from the spawn point if there is one)
> Sounds
To ease the sound integration into the game, we use a Microsoft Tool named XACT (for Cross Audio Creation Tool) that allows Yann to constitute a database of sounds we can play in the game thanks to the use of dedicated parameters in some actor setting in the editor. Friendly names given to the sounds allow the identification in the database.
Here is what the tool looks like:
And that’s all for this week!
See you soon.
@Nicolas:
I don’t think so :]
Better than Little Big Planet 🙂
@z0rit0:
Yep, I think an ingame editor is really motivating for everyone 🙂
We will see what we do with this editor, if we activate it later or something or if we keep it for us (yeah, that will be sad ^^)
@Misuuu:
Merci ! C’est le rush en ce moment :]
Tain les gars, ça déchire ! continuez comme ça !
Well for Dino Legs I also coded the editor myself.
I thought about the text editor solution but I thought it was better to have something integrated in the game. More convenient for me to design the levels. And also it allows players to create their own ones…
At the time I was not aware of things like Ogmo Editor. Maybe I would have given it a try…
Hi Lucca,
Yes you’re right, making AS3 within the timeline in Flash Editor is a pain :]
I hope that framework like Flixel or Flashpunk will reduce your pain! (with the good code editor, like FlashDevelop, it’s just the heaven^^)
Hi !
very interesting post, as a flash coder, i’ll have look right now to the Flixel framework (i’m killing myself making AS3 inside Flash editor)
Can’t wait to see and try the first playable demo of your BTM 🙂
Good luck !
@Garry:
It’s funny how many similarities there are :] Can’t wait to see your platformer comming to XBLI. Do you plan to include this level editor in the game?
@z0rit0:
Glad you liked the article!
How did you proceed with Dino Legs levels? With a good text editor like us for TTT?
Very interesting article! I wish I had knew all this when I started Dino Legs development!
I’m definitely waiting for BTM!
Hi Shaah,
As I was saying before, we don’t think the editor will directly come with the game release.
We are thinking about releasing the editor later, when it will be really user friendly and when we got the “technology” to share data between players and creators.
Thanks for your comment and your interest 🙂
Nice post, this game looks good!
Will the editor be in the final version of the game?
I’m only using plain XNA so we’re probably just fraternal twins 🙂
I have been fiddling with the platformer for quite some time now, but became serious about releasing it as a XBLI game recently. I started working on the in-game editor the first week of January if recall correctly. It’s on hold for now, I’m busy fixing Kazz.Ed and planning my return in France (this week end!).
Funny, even my editor cursor is looking similar to yours :]
Hehe hello Garry 🙂
This is funny! Do you use the X-Flixel port by Ben Baird? If so I think we are twin brothers separated when we were born :]
When did you started this XNA platformer? BTM was started the 2nd week of january (so the editor was already live when we came to the GGJ :), just to reassure you!).
And NO, Kazz.Ed is not a TTT ripoff :]
Hello Swing Swing!
Interesting read, I started experimenting with building a platformer for XNA at around the same time at you, and came up with the exact same solutions. If you were not using XML instead of Lua for resource files, I would have swear you stole my codebase during the GGJ last month 🙂
That wouldn’t be unfair though, as it is the code behind Kazz.Ed, which is but a shameless rip-off of Tuper Tario Tros ^^
Hi gludion,
Yes you’re right, the editor is not super user friendly for now 🙂 We were wondering about including such an editor in the game but we really want to offer the best game as we could to the most common player: a player that never build levels 🙂
But, in the future, if we manage to turn the editor in a better user friendly mode, and if we have the technology to make a community system with some portal to share your homemade levels, then we will include the editor in the game, via update or something like that.
The adaptativeblock visual is funny t osee in action, and it saves a lot of time to William :] And it’s not a complicated thing to do programmatically!
As for the any tile-based game question… yes, the editor can take a parameter in its resource file to indicate the thickness of sprites (here we use a 64pixels thickness, at the beginning of the development it was a 16pixels tile thickness that was used).
this in-game editor is a brilliant idea!! I’m wondering if it can easily be adapted to any tile-based game.. The only drawback I suspect is that it may not be super user-friendly if published with the actual game.
I also love the adaptive block visuals.