Thank you to everyone who submitted; the position is now filled.

Important: if we have contacted you but you didn’t hear back from us on Friday, April 27th, e-mail us! We’ve had some server troubles and might have lost your e-mail.

We are starting work on a Facebook puzzle game and are looking to hire a freelance artist to handle its visual development and content production.

The game is aimed at a casual audience and requires a clean, crisp, and colourful aesthetic. The project’s timeline is slated for April 16th, 2012 – November 30th, 2012, and the position requires the following:

• Technical proficiency in Flash and Photoshop/Illustrator.
• Concepting and visual development of overall game theme.
• Production of various environments and characters (with swap-able body parts/accessories), as well as additional work on UI and visual effects.
• Commitment to meeting deadlines and responsiveness throughout the work process.
• Availability for future additions to the project beyond the initial scope.
• PayPal account for accepting online payment (in CAD currency).

Being familiar with videogame development and local to the Greater Toronto Area and is a plus, but not required.

If you’re interested, post a direct response below or e-mail us at work@incubatorgames.com. Make sure to include a portfolio link and highlight your cute and original illustrations and production artwork. Judging by past experience, we will not be able to respond to every entry, but we will definitely check out each submission.

Thanks for your time, and we’ll be sure to update this post once the position has been filled.

Pipelines in virtual reality.

Project VRP is our third title developed for Science Alberta. The game takes place in a virtual reality setting where the player must manage various types of workers in order to design, build, and maintain a proper pipeline.

Here’s a trailer of how it looks in action:

Project VRP was created using Unity3D and can be freely played right here.

Below is a short case study of the project’s development:

The Overview

Following a successful completion of The CO2 Connection, we discussed various possible projects with the Science Alberta Foundation. In the end, Project VRP won out and the other proposals were slotted in for a later date.

The game required an extended pre-production process as well as a more complex feature set, so the timeline was set at 8 months with a budget increase of 25k over the previous titles. An iPhone port was also scheduled as part of the initial contract.

The Challenge

Project VRP was aimed at a slightly older audience than our previous Science Alberta games, and as such it needed a more mature look. In addition, its numerous scientific concepts were quite advanced but still needed to be conveyed through a single overarching experience.

The fully-3D environment not only allowed for some extra visual flair, but more accurately represented pipeline layouts.

The specific goal of the Project VRP was to showcase various types of jobs associated with pipeline production and upkeep. This extended to environmental challenges and acts of nature that had to be reflected in the main gameplay as well.

About half-way through development process, a change in priorities also took place. It was deemed that some scientific concepts needed to be explored in more depth, with the principles of corrosion, welding, and soil composition taking centre-stage.

The Solution

The Kelvin mascot was a central connecting theme between all the SAF titles, so we suggested a virtual reality environment to balance the cuteness of the Kelvins. This move allowed us to use darker palettes along with a more high-tech, industrial aesthetic.

Fairly early on in development, SAF ran a focus group with some grade-schoolers to gauge the effectiveness of this approach. The responses were overwhelmingly positive, with not a single complaint or request for alterations.

The codex let the players browse through a listing of all the units and their respective icons.

The goal of showcasing numerous professions was tackled via a list of individual “worker units,” each one possessing a single ability vital to pipeline construction and maintenance.

The difficulty in representing such a vast number of workers was tackled by separating the units into small groups, initially hinting at which workers should be used for which tasks, briefly introducing each group at the start of every level, and letting the player peek at a codex that contained info on the entire cast.

A bit of randomization was also added via weather effects that slowed down production and tied into real-world emergencies. This core game was then playtested with another group of grade-schoolers, and their feedback led us to add some extra polish to the tutorials and include a few additional visual effects to make the mechanics more intuitive.

The minigames not only tackled some subject matter in more depth, but also served to punctuate the ending phase of each level.

When development of the game was temporarily halted due to a change in focus, we worked with SAF on how to best incorporate the new goals. It was eventually decided that adding minigames to better showcase some of the jobs would be the best solution, and these were seamlessly slotted into the end of each production phase.

To minimize the costs of the delay and the extra features, the iPhone port was removed from the feature-list. This covered the majority of the work, and in the end the budget was increased by only 7k.

The Results

The final version of Project VRP was very well received by the sponsors, with SAF inquiring into possible future ports to iOS and other mobile devices.

We are finishing up art tests with the most promising submissions, so the ad should now be considered closed.

Thank you very much to everyone who applied!

Here’s what’s required for the job:

• Strong artistic foundation and ability to create a unique and eye-catching style for the entirety of the game (level assets, UI themes, etc.)
• Technical proficiency in Photoshop/Illustrator and asset-production for various resolutions.
• Commitment to meeting deadlines and responsiveness throughout the work process.
• Availability for future additions to the project beyond the initial scope.
• PayPal account for accepting online payment (in CAD currency).

Being familiar with videogame development and local to the Greater Toronto Area and is a plus, but not required.

If you’re interested, post a direct response below or e-mail us at work@incubatorgames.com. Make sure to include a portfolio link and highlight your cute and original illustrations and production artwork.

Judging by past experience, we will not be able to respond to every entry, but we will definitely check out each submission and contact the most promising individuals with a demo of the game.

Thanks for your time, and we’ll be sure to update this post once the position has been filled.

The end result looks quite good, though, and I’m happy with our decision to use 3D models. We debated going with 2D “cutout” sprites — as is the norm with many tactics games — but eventually chose against it. A fully-3D environment allows us to properly implement dynamic lighting, and the 3D animations come out much smoother than simply using a handful of 2D frames. Our initial concerns with the animations not being as expressive as  in 2D also proved unnecessary, which will be even more evident in our next showcase!

First up, a series of character illustrations and our initial HUD mockup:

All of the worker images will be present in the game, so they had to be a bit more polished than a typical piece of concept art. The main challenge here was using the original Kelvin design to create a standardized “virtual reality” look, all the while making the workers look distinct.

And now for a couple of in-game screens:

As you can see the HUD has changed quite a bit, and we now have an actual map/model renderer. It was tricky developing the proper shaders to get a look similar to games such as Tron and Darwinia because we’re limited by the eventual iOS port. Still, I’m quite happy with the map’s glow-y, pulsating highlights, and we plan on adding various other visuals in the future to make the virtual world really come to life.

Milky Tracker is software used to make module music

In a module file each instrument is stored as a single sample while the music is stored as sequenced data. You can think of it as a piano roll, where each notch plays back one of the samples at a specified frequency. Mod’s have many advantages over MP3 audio for games on iOS:

• File size does not scale directly with the play time of the music.  Each instrument in the song is stored once as a sample and that data can be reused over and over as the note sequence is processed.
• Seamless looping and loop points.  Many songs benefit from a loop back to just after the intro or  infinitely looping an ominous ending phrase.
• More control over playback.  If the timer is low, you can increase the speed of playback without affecting pitch to create an organic frenzied feeling.  If Mario gets on a Yoshi you can dynamically mute/un-mute an extra drum channel.
• Fine grained optimisation.  With an MP3 you have to deal with the quality of the entire audio clip as a whole when adjusting for quality.  With a module file you can decrease or increase the fidelity of specific samples to get the best quality for your memory and size constraints.

Unfortunately, many existing and popular solutions for playback on iOS come with licensing fees, but there are alternatives that will do the job. Chibi XMPlay, a lightweight module playback library created by Juan Linietsky and myself, is one of them.

It’s used for playing a type of module file known as XM (eXtended Module) on limited platforms like the iOS or Nintendo DS. Best of all it’s completely open source, licensed under new BSD, and free to use for both commercial and non-commercial applications.

Using ChibiXM Play

Chibi XMPlay was written with portability in mind.  As a client it’s your responsibility to populate memory, file i/o, and mixer function tables for the OS you’re using.  Lucky for you, I’ve done this work already for Trudy’s Mechanicals.  I’ve also added functionality to the wrapper to play sound effects which is possibly useful as a low latency alternative to Apple’s numerous methods.  To use ChibiXM do the following:

1. Make sure you have the “AudioToolbox” framework imported
2. Download the ChibiXM source w/Objective C wrapper and include it
3. The following code will play an XM file (provided ‘song.xm’ is part of your project):

If you just want to see ChibiXM in action here’s a complete XCode project you can compile and deploy that shows some graphics and let’s you switch between some songs with a touch.  Note that the project was created in XCode version 3.13 of the SDK.  To compile under the latest just go to Project Info and change Base SDK to 4.x

Just a few games that used module based music solutions! Ah, memories.

Where To Go From Here?

The wrapper is a simple way to play module music and sound effects, but I encourage you to look further into ChibiXM’s capabilities.  It has functionality to share a pack of samples among many songs and other goodies that allow easy programmability and control over music playback and mixing.  It’s also pretty easy to extend if you wish to add DSP effects to playback.

Here are some links to help you explore this approach to putting music into your game:

Chibi XmPlay – Berlios project page for Chibi XmPlay
Milky Tracker – Multi-platform tracking software that can create XM modules
ModArchive – Massive repository of tracked music
IndieGameMusic.com – Website designed to connect game developers to game musicians

Follow me on twitter! @infey

** UPDATE **
Dave Rempel points out that you may run into an issue if you load many songs into memory at once using xm_song_alloc() as the ChibiXM built-in software mixer (which the iOS code uses) has a statically sized pool of memory for storing samples for all songs currently loaded. The easiest way to avoid running into the issue is to only load the songs into memory you absolutely need for playback. However, if you wish to change the size of this buffer based on the requirements of your app you can modify the size of this buffer in xmplay.c, line 113:

Its been a while since I’ve written a post on the simple scripting language.  While steadily working on Trudy’s Mechanicals,  I’ve recorded and released an album with my band Bacchus and integrated the simple scripting language into our internal projects. So without further ado, I’ll be looking at the virtual machine (VM) that the script’s compiled output will run on.

The reason I’ve skipped ahead is that I can’t start outputting assembly until I’ve designed the virtual machine (VM) that it will run on.

In the past I’ve designed stack based VMs exclusively, so this time I decided to try a register based VM.  Register based VMs  are predominantly RISC based, with fixed size instructions and simple addressing modes.  Register based VMs have the advantage that each instruction can do more than a stack based one, but stack-based assembly has the advantage that it  takes up less space.  There are exceptions to both of these cases.

An example of the size/complexity trade-off can be seen in the following arithmetic example.

int x,y;
int z = x*y + 1

Stack-based assembly (JVM inspired) output would be roughly:

1. LOAD X (1 to 2 bytes) – push x on to the top of the stack
2. LOAD Y (1 to 2 bytes) – push y on to the top of the stack
3. MULTIPLY (1 byte) – remove the top two items from the stack, multiply them and push the result
4. INCREMENT (1 byte) – increment the value on the top of the stack
5. STORE Z (1 to 2 bytes) – pop the top value from the stack and place it into the local variable z

Register-based assembly (ARM inspired) output would be roughly:

1. MULTIPLY reg[tmp] = reg[x]*reg[y] (4 bytes)
2. ADD_IMMEDIATE reg[z] = reg[tmp] + 1 (4 bytes)

As you can see stack-based assembly would be 5 instructions, with a size between 5 and 8 bytes.  Register based assembly code would be 2 instructions, with a size of 8 bytes

The Virtual Machine

In physical computers each additional register has a significant manufacturing expense.   The only cost of adding more registers in a VM is decreasing the number of bits used for opcodes or decreasing the number of registers that can be specified in a single instruction.

Like LUA 5, I found that 6 bits (64 opcodes) is more than sufficient for the number of instruction types I wanted my VM to contain. The virtual machine I’ve designed has 256 registers, available to a function at a single time.  Each register can hold either a 32-bit integer or a floating point value.

Each 32 bit instruction falls into one of the following four categories:

In addition to the 256 general purpose registers, two special purpose “registers” are required for the VM to execute:

• PC – program counter.  A pointer to the next instruction in memory to execute
• BP – base pointer.  A pointer to the location in memory, where the 256 registers start at, for the currently executing function.

List of Instructions

Below is a table of op-codes that I’m currently supporting:

Arithmetic

• MOV_IMM -  dst register = 18 bit sign extended immediate
• MOV_CONST – dst register = constant_pool[18 bit immediate]
• ADD – dst register = src register 1  + src register 2
• ADD_IMM – dst register = src register 1 + 10 bit sign extended immediate
• SUB – dst register = src register 1 – src register 2
• MUL – dst register = src register 1 * src register 2
• DIV – dst register = src register 1 / src register 2
• FADD – dst register = src register 1  + src register 2  (treated as floats)
• FSUB – dst register = src register 1  – src register 2 (treated as floats)
• FMUL – dst register = src register 1  * src register 2 (treated as floats)
• FDIV – dst register = src register 1  / src register 2 (treated as floats)

Compares / Jumps

• CMPEQ – dst register = (src register 1 == src register 2) ? 1 : 0
• CMPNE – dst register = (src register 1 != src register 2) ? 1 : 0
• CMPLT – dst register = (src register 1 < src register 2) ? 1 : 0
• CMPLE – dst register = (src register 1 <= src register 2) ? 1 : 0
• FCMPLT – dst register = (src register 1 < src register 2) ? 1 : 0   (treated as floats)
• FCMPLE – dst register = (src register 1 <= src register 2) ? 1 : 0  (treated as floats)
• JNE – if (dst register != 0) {  pc += sign extended 18 bit immediate }
• JEQ – if (dst register == 0) {  pc += sign extended 18 bit immediate }
• J – pc += sign extended 26 bit immediate

Operational

• CALL – call the function [ 18 bit immediate] retrieving parameters starting at  register’s index
• YIELD – interrupt execution
• RETURN – return the value contained in the destination register of the callee, and resume the exection of the caller
• RETURN_I – return an 18 bit immediate, and resume the execution of the caller
  

nb.  this is in no way a final list

Calling Conventions

In stack based languages, the arguments to a  function  are taken from the top of the stack. However, in a register based machine, there is no notion of a “top element of the stack”.  When we CALL a function we need to specify where the arguments should be retrieved from.

The CALL opcode has a register and an 18 bit immediate value as its parameters.

The 18bit value specifies the index  into a table of functions (internal to the VM) to invoke.  The register parameter specifies where in the current register set that the arguments reside.

Would compile to:

The table of functions contains the following information:

• code pointer – code to execute for the function
• number of arguments – the number of arguments that the function requires
• register count – how many registers this function requires (I’ll use this later to check that we don’t exceed memory limits)

When the CALL is executed it shuffles the arguments 2 register indexes up and stores the current BP and PC below them for later use.

?*,?,1 , 2, 3 (inside caller)
?,?,BP,PC, 1* , 2, 3  (inside callee)

* represents where the current BP is pointing at

PC is now set to the code pointer found in the table of functions
BP is set to point to the first argument to the function.  This has the advantage that all arguments start at register indices 0 through N.  This also places the constraint that the caller must not have any useful data placed in registers higher than the ones being passed as arguments as they may be overwritten by the callee.

When a RETURN instruction is encountered within the callee, the old BP and PC are retrieved so that execution can continue from where it left off in the caller.   If a return value is specified, it is place into the position of the first argument inside the caller.

?,?,BP,PC, 1* , 2, 3  (inside callee)
?*,?,return value, ?,? (inside caller)

Implementation

The software implementation of a VM is usually a combination of  a loop and a switch or jump table:

Constant Pools

There are two types of constants contained within the VM:  32 bit constants and string constants.

• 32-bit constants are used when a number (int or float) cannot be represented with the number of bits provided by an immediate value.  To get over this limitation, MOV_CONST moves a 32-bit value from the constant pool into a specified register.
• Since strings are immutable in the language, the string pool is used to store the actual character representation of them.  When strings are placed into registers by the language,under the hood it is not a string pointer copied, but the index of the string within the string constant pool

Wrap Up

You can download the current version of the VM here.   Next time I’ll be bridging the gap between the last two posts and starting to output assembly code to run on this VM.

As always you can follow me on twitter at @igtristan

The position is now filled.

Thank you to everyone who responded to our ad; we received over 120 inquiries! Apologies if we couldn’t get back to you personally or provide more time for an art test.

Overall this was a pretty positive experience, so we plan on posting similar ads in the future if we need extra help.

Thanks again.

We are starting a new contract project with Science Alberta and are looking to hire a freelance artist.

The title screen of Kelvin's Space Ranch showcasing the Kelvin mascot.

The game is titled Project VRP and is a continuation of the Kelvin series, but aimed at a slightly older audience (8-12 year olds instead of 6-10 year olds). It takes place in a 3D virtual reality setting similar to TRON and other iconic “cyberspace” visualizations. Its levels are procedurally generated, but need to be enhanced with various 2D artwork.

Here’s what we require:

• 2D illustrations of the Kelvin mascot clad in various work uniforms. These will be used in-game and need to emulate the existing Kelvin concepts.
• Large-scale illustrations of the setting and its contents to be used in-game and as promotional material.
• Futuristic UI components and icons for game-navigation and general polish.

References for these will be supplied by us, but a relatively large amount of creative freedom will remain with the artist.

Basic experience with 3D modeling/animations, game development and video editing are a plus, but not required.

An in-game shot of Kelvin in his overalls tending to a futuristic farm.

Our preference is to work with someone local to the GTA, followed by other Ontario residents, but we will consider all applicants. Work on the project will begin immediately, and we’d like the artist to be available (at least partially) until the game’s completion on November 1st, 2011. All payments will be done via PayPal in CAD currency.

If you’re interested, post a direct response below or e-mail us at work@incubatorgames.com with the following information: a link to your online portfolio highlighting any applicable pieces, a resume or a brief bio, and a rough working fee (preferably based on previous work examples).

Thanks for your time, and we’ll be sure to update this post once the position has been filled.

Luminous Arc starts off with roughly 150 text boxes. Such quantities are pretty common throughout the entire experience.

Verbal diarrhea is never necessary, though, and with Trudy’s Mechanicals we’re taking multiple steps to avoid it:

1. Dialogue sequences are often optional. If the player doesn’t want to listen to a character, he can simply choose not to initiate the conversation.
2. Colourful tid-bits are non-blocking. This means that if an enemy or an NPC wants to deliver a bark-style one-liner, it simply fades in and out. The text itself is aesthetic and doesn’t hijack the player’s interface, leaving him free to navigate the UI or issue battle commands.
3. Cutscenes are short and to the point. Characters don’t prattle on if they don’t have anything interesting to say, and the player never needs to wait too long before he’s back in the “driver’s seat”. A skip option is also implemented as it’s an expected standard for those who are not interested in the story or might be replaying the game.

This less-is-more approach means that our script is much, much smaller than that of a typical tactics game. As a result, we’re taking extra care to make sure the language itself feels unique and interesting.

Here are some examples:

Slang

Planescape: Torment is famous for its cant, Victorian slang that adds personality to its setting. Seeing as Steampunk has its roots in a romanticized Victorian era, we decided to take a similar approach with Trudy.

A few examples of facial expression that accompany the text of Trudy's main characters.

Although it’s tempting to go overboard with jargon, it doesn’t help if the script can’t be understood by most people. Consequently the use of slang is somewhat conservative and the words we picked often have current-day connotations.

Here are some examples:

• Barker – A gun. Not immediately obvious, but easily grasped given proper context.
• Nibbed – Arrested. As in nabbed, or kidnapped. The word doesn’t have a strict association with the police, but its sentiment is easily understood.
• Lushery – A public drinking den. Lush isn’t a common term for alcohol, but this one was just too amusing to pass up.

Names

Naming characters in a fictional setting is a bit tricky. You typically want to steer clear of popular current-day names that might break the suspension of disbelief, e.g., Mike Smith or John Brown. On the other hand, something truly alien might prove too difficult to vocalize internally, while symbolic names like “Black Lightning” tend to come off awkward and hokey.

Of course we could’ve simply used Victorian era names, but I wanted to differentiate Trudy from typical Steampunk pulp.

Unlike the lead stars of the game, NPC dialogues are not accompanied by "talking heads". This is to save on production costs as well as prevent NPC barks from taking up too much space on the screen.

Our solution was to use old Greek and Slavic names.

The result is not entirely alien, but it’s enough to stand out. Characters are given names such as Renatus, Tatjana, Darko, Milos, Daria, etc., which keeps the naming conventions consistent and adds a bit of flavour to the world.

Proverbs

Finally, proverbs are my favourite trick for imbuing a setting with a sense of culture and history.

Proverbs are usually quite short, but they convey words of wisdom that often speak volumes about an entire society. In keeping with our naming approach, I picked out a couple of Greek and Slavic proverbs suitable to our script:

“Gray hair is a sign of age, not wisdom.”

“As long as a child does not cry, it does not matter what pleases it.”

“Eat and drink with your relatives; do business with strangers.”