I get lots of people asking me: “Why don’t you just use Spine or Spriter?” And that is a very valid question. I think it comes down to preference. There are pros and cons to building your own sprite editor, and there are pros and cons to using Spriter/Spine. I like the artists to be able to hook up visual effects, sound effects, camera shakes, etc, right in the editor, and see the actual final result, running in the actual game engine. I also want to extend the standard skeleton/bone editing with Verlet-physics bones, for things like headbands, braids, things hanging from belts, etc. These are all things I could simply add to my own system, while I’d have to import the animated character from the sprite software, and attach these effects in a separate home built editor otherwise.
The way the old sprite system worked is that each animation had it’s own skeleton setup. This may sound weird, but our previous sprite system had to handle all kinds of sprites, not just humanoid characters. Of course the downside of this approach is that there is no way to interpolate between two animations. So instead of throwing away the sprite system we have now, I decided to build a puppet system in tandem, and in the engine we’re able to use both.
The puppet system has a more traditional skeleton setup, and will likely be used mostly for characters in the game. You create one skeleton for your character, and then you attach animations to that skeleton. This approach makes attaching a different skin very easy, allowing you to re-use animations and skeleton setups between characters. In Shellrazer the characters varied so widely in size and anatomy that this system would probably have been overkill, but for a future game we’re planning to use more similar characters.
The last week I’ve mostly been working on iterating on the puppet editor, adding more precise keyframe control, bone animation, as well as a nice big horizontal time bar like in Spine. This week will be more editor work, as well as getting the puppet system integrated into the engine.
That’s pretty much it! Hopefully next week we’ll be able to show the first animated character in this new system. Until next week!
This week I’m going to talk about something that I’m working on right now: localizing our game to multiple languages! (to be exact: French, Italian, German, Spanish, Portuguese, Japanese, Korean, Chinese and Russian).
Localizing a game isn’t always easy, but it’s all about preparation! My ‘Waanderful’ engine (as Jesse likes to call it) has a built in localization system that we’ve used for N+, Scrap Metal, and now Shellrazer. It’s pretty straightforward, really. It simply links a number to a line of text. Each language we translate to uses the same numbering, so to start the game in a different language, all we have to do is load different lines of text linked to the same numbers. In the game and editor code we only refer to lines of text by the number, or as we call it a LocStringID. Here’s an example of the localization file for English:
First, there’s a number (LocStringID), then a line of text, and at the end there’s a comment or context for this line of text. Whoever is translating your game usually like to see a context of where the line of text is used in the game. If you were to use Google Translate (which wouldn’t know the context), you might get ‘back’ translated as the body part, not the menu option!
We sometimes use C++ string formatting to replace specific parts in the line of text with something that is calculated in the code. For example, string 00104 above has a %d token. This gets replaced in the game code by a number. In line 00149 there’s a whole lot of tokens going on! the ‘\xFFFE’ part is referring to a specific character, in this case character FFFE hexadecimal. Our font rendering code uses our own generated bitmap fonts, and we insert a little image of a gold coin as character FFFE. Below is a screenshot of our editor, with string 00149 entered in the test area, and the %d replaced by the number 10.
Each language can have it’s own font as well. The screenshot above shows characters that will probably fit French, Italian, German, Spanish and Portuguese, but Japanese, Chinese, Korean and Russian will need their own fonts because of the vastly different characters used. Our font system also allows for multiple font textures, which we’ll likely need to use for Chinese.
So, how do we get these lines of text translated? In our game data directory, each language is represented by a directory with it’s own unicode text file called localize.dat, which holds all the strings for that language. I created a little tool that can export and import to and from Excel, which is a file format that most translators will be able to use.
For N+ and Scrap Metal, Microsoft took care of translating the localize.dat files, but this time we’re on our own (which is probably why it took us until now to bite the bullet!). We chose to use icanlocalize.com for translating our files. We’ve only submitted our files yesterday, so it’s still very early, but so far I’m really happy with the process! You basically upload your file, say how many words need to be translated, and which languages you want to translate to. After you’ve filled in all the fields, you define a duration of bidding, and a duration of the translation work to be completed. During the bidding phase, translators can bid on your project (per language), and you can look at their profile and see if you think they fit your project. It’s really a lot easier than I remember it being on our previous projects!
I can’t wait to see the translated text in the game. (And I hope I won’t have to fix too many screens due to differing string lengths! :) )
That’s it for this week, hopefully we’ll be able to deliver a fully translated Shellrazer to you soon!
Last weekend was the weekend of the annual Full Indie game jam. Both Jesse and myself (Nick) went and had a ton of fun jamming. Jesse joined a team with two of his friends and they created the fantastic game Coalin’, which he will talk about in a bit. I decided to lone-wolf it, and create an audio toy I’ve been itching to create, but never got around to. So this week we’re showing off what we’ve created in 48 hours, we hope you like it.
AudioJam. That’s the little audio toy I made. It’s not really a game, but whatever, I had fun jamming it out, and it actually works! It’s not complete by any means, but it does what I wanted it to do, and provides a nice basis for future development. So basically what I wanted to create was something like PureData. I’m not particularly fond of the puredata interface, so one goal was to improve on the interface, as well as learning about audio programming in general. So in a nutshell, the idea is to have small abstract audio processing blocks which you can link together into a ‘circuit’, with the goal to output sound. Maybe a screenshot will be more explanatory:
This little schematic creates a wobbly sound, controllable by three midi controls on my midi keyboard. This is what it sounds like:
I also added a midi keyboard and envelope generator, thought they are both very basic and probably need some fixing.
Here’s a sample sound:
So in the end, I am pretty happy with the results. It’ll be a good platform to play around with some audio filters, effects and mixers.
Next up is Jesse’s game Coalin’. Take it away Jesse!
So as Nick was saying we had the Jam last weekend and it was super fun. I worked with some good friends of mine Aaron Cox and Graham Jans, two guys that I’ve always wanted to make something with but it just never got done due either to my own flakiness or some other thing. Anyways we set out to make a list of over 48 game ideas up to the jam’s date an then picked #49 on the day of the Jam!
So our game was called Coalin’ It’s a 2v2 game where you control little shoveling guys and race your train against the opponents. you use your shovel to break apart ore and collect coal and ferry it back to your train. You can only hold 3 objects at once so you don’t want to clog up your inventory with useless bits of cactus! You can also whack your enemies with your shovel to knock their inventory out of them.
In the screen below you can see that there’s also bright yellow chunks of uranium! Bringing those bad boys to your train results in a much bigger speed boost so they are usually a high priority for both sides.
A big part of the game is jumping up onto the train to use it to traverse across the screen faster. The battles become quite heated when you are on top of the enemies train, bonking him with your shovel to keep him from cashing in that coal!
The teams are named the “Brown Back Attacks” and the “Green Idle Sides” based off of my ridiculous animation naming conventions. Once your train hits the edge of the screen you are awarded with a big explosion! We also didn’t kill ourselves by staying up the entire length of the Game-Jam and although we worked crazy hard, we still got a decent amount of rest and cranked out a wicked cool project.
The game came together really well and I had a blast working on it. I’ve never used unity before but having all the tools ready to go right away and having your team familiar with them really made progress fast.
This week I’ll talk a bit about the tech behind the turn based game prototype we’ve been working on (see an earlier devblog).
Turn based games are interesting programming exercises. They seem so simple to build. After all, it’s just like a board game, right? There is a world state, and then everybody modifies this world state in turn, and done! In our game things are a little more complicated than that though, because we’re adding fog of war, visibility ranges, playback systems, local (hot-seat) and online play, AI players, etc.
The fog of war makes it look like the entire world is dark, and only the parts you’ve discovered will be opened up. The visibility ranges affect how far each unit can see, and when the unit moves, the fog of war is updated. Tiles that were visible at one point in your exploration are marked as ‘discovered’, and will be visible forever after. If they aren’t currently visible though, they will be slightly darker. This adds an interesting extra level of complexity if the terrain can be altered. Imagine I walked one of my units around the globe and on the way it discovered a nice grassy area. Another player also discovers this grassy area, and starts building on top of it. The first player shouldn’t see the terrain changes if the terrain isn’t currently visible!
Since this is a turn based game, the delay between taking turns can be relatively large (hours or days). Also, because it’s asynchronous, the world state can change quite drastically between your last turn and your current turn. This makes it really hard to follow what happened in the enemy turns, so we implemented a playback system that can play back the moves made by the other players (but only the parts you can see of course). Basically I keep the world state as the player last saw it, and all events that happened since the player’s last turn.
I really want to make this game a good online game, and I believe for strategy games, it’s really important to prevent cheaters from gaining the upper hand. Our online server was designed from the ground up to prevent cheating as much as possible. This means that for online games, only our online server has the full game state. Every client requesting the game status will only see their limited version of the game, and the game won’t transfer any information about enemy units that are invisible. This makes hacks like adding huge spikes to the player models so you can see their location through walls, map viewers based on intercepting network messages and clearing the fog of war a lot harder, because the required information to cheat just isn’t there. clearing the fog of war on a client would simply show a big planet of undiscovered tiles.
Alright, that’s it for this week. Lots of work to be done on the http server, but things are slowly starting to work!
The banner is a re-use of the space game we were working on before, because well, this dev-blog is about a planet. Pretty space-y, right?
So as you’ve seen in previous blogs, we were mostly working on the contract work for the last little while. But we’ve also been working on a new prototype. I’ve always been partial to strategy games, and while having enjoyed working on real-time strategy games such as Homeworld 2, Warhammer 40,000: Dawn of War, and Dawn of War: Dark Crusade, I’ve always wanted to build a turn based strategy game. so I figured, why not try it out? At first I wanted to build a strategy game on a regular grid, but then I saw this demo, and was sold on the hex grid on a planet. Well, it’s not exactly a hex grid, really, there are a bunch of pentagons to make the rest of the hexagons fit. We decided to give it a go, and here’s a screenshot of the prototype so far:
Currently the turn-based engine is working, and it’s playing back the moves of other players, updating the fog of war, etc. Currently I’m figuring out how to build a web-server to be able to play online games, and I’m trying to figure out how to do a proper AI. I found this awesome dev-blog from Checkmark Games, and I will likely follow a similar route to get AI working. I really like that he’s using a genetic algorithm, by letting AI’s duke it out, and based on the results the variables for the AI’s are tuned. It reminds me of the Homeworld 2 AI programmer who had a similar script running every night he went home. Good ideas!
There’s lots of work to do before it actually will start being a lot of fun, as is usually the case with strategy games. We’ll probably talk more about this in a later dev-blog!
That’s it for this week. For everybody attending PAX Prime, go check out the Necrodancer booth! Jesse will be there drawing some stuff up, so go say hello to the one and only Drawbarian!
VANCOUVER, British Columbia – July 26, 2012 – Independent development studio Slick Entertainment is proud to announce Shellrazer for iPad, iPod Touch, and iPhone, released on the App Store today for a temporary launch sale of $0.99 (regular $2.99). RIDE YOUR GIANT WAR TURTLE TO VICTORY OVER THE NASTY GOBLINS!! You are a Klang Clan […]
Welcome back, followers of the fearsome! Earlier this year I wrote a bit about our sprite system in Devblog 57. After seeing cool sprite editors in action like Spriter, Spine, as well as seeing the amazing Rayman Legends making of video, I thought it was time to upgrade my little sprite system! I get lots […]