Today is a guest post by Simon Butler about the artwork / visual iteration of Tic Toc Body Pop. The game is getting some great reviews here and here we’re hoping things continue to build up on the promotion side of things, please check it out if you haven’t already on the App Store
Before I begin I guess I’d better introduce myself. My name’s Simon Butler and I produced the artwork for Tic Toc Body Pop. I originally conceived the project after watching ‘Hole in the Wall’. Although I don’t particularly rate the game show, I did think the basic premise would work well as a video game, particularly one that utilizes touch screen controls.
The art style
The surreal, weird style of the artwork was originally intended just to be a distraction for the player throughout the game, with lots of odd things happening in the background as well as having random objects popping in from the sides (and above) to knock you off course. There was never any reason behind any of it, it was all just there to put you off! I drew inspiration for all this from a point in time around 15 years ago when myself and several other ‘like minded’ friends would sit around the kitchen table on an evening and try to ‘out do’ and offend each other with some of the most bizarre drawings you can think of (for example: imagine an elderly lady wearing a gas mask, naked with the legs of a donkey, riding an armour plated marmot and you start to get the picture). We were all into David Cronenberg (Naked Lunch, eXistenZ, Videodrome), John Carpenter, Clive Barker, Hayao Miyazaki animations, manga – all amazing work that served up weird and wonderful imagery and a limitless well of creative inspiration. Music was also very inspirational, especially the more ‘avant garde’ stuff out there like ‘Steroid Maximus, Mike Patton, John Zorn, Peter Thomas and Herb Alpert to name a few. I’m still influenced by all of the above today, but I think a lot of the darker elements within my style have maybe been filtered out during the Tic Toc development process. I’ll maybe save that for the sequel!
It wasn’t until later in the development cycle that we decided to explain the Tic Toc imagery in each level as Tic Toc’s dreams. I think adding this element of explanation definitely makes the player feel more comfortable in their surroundings and it certainly made me feel better knowing there was a reason for everything we were showing.
The art process
The first thing I decided to do was sketch out a few rough ideas to illustrate what a typical level in Tic Toc would look like. I produced these 3 sketches before moving on to a video mockup (see Simon’s previous blog).
Once we were all comfortable with how the project was going to pan out, it was time to start work on the designs for the individual levels. I really enjoyed this part of the process as I was basically just plucking random ideas and scenarios out of my head and putting them down on paper. As long as the level theme was weird enough, it would suit being a Tic Toc level! My target number of designs was 50, enough to fill the first version of the game and a few updates. I’ve attached a few comparison pieces below.
The whole level design process (including roughs and final assets) took around 2 months to complete. A typical level asset directory consists of a 1024×768 static background, a separate animation directory containing the level background animation elements, and we have an ‘objects’ directory for level obstacles (circular saws, bombs, lasers etc). Everything was illustrated digitally using a Wacom Intuos3 tablet in conjunction with Coral Painter and Adobe Photoshop. I rarely use pen and paper (aside from the odd little doodle) and find the purely digital process to be a lot more efficient. The conveyor belt was modelled in 3D using 3DS Max and rendered at the required angle. The final model is actually the same one I used when I built the original video mock up, it just received a bit of a texture makeover!
The level HUD design was also a simple process which went through minimal changes. We stuck with a similar colour scheme that was introduced in the original mock ups. The size was altered and we ditched some of the original icons which were replaced by the new ‘speed up’ and ‘slow down’ buttons. The figure Guide Monitor was scaled down slightly and given a change of colour towards the end of development to give the player a little more room for manoeuvre. We also decided to make the monitor slightly more transparent so the player would be able to see Tic Toc more clearly if he ended up in that area of the screen.
While the tech for Tic Toc was being developed, we tested each level using a faceless ‘mannequin’. Shortly after this process had started, I decided to start work on giving this little guy a bit of personality. To be honest, Tic Toc’s face didn’t take too long to come up with. I drew a lot of inspiration from Pixar, Disney and studio ghibli features, all of which use friendly, wide eyed, larger than life characters, something I wanted to include in our (yet to be named) Hero. The decision to use multiple unlockable costumes was something we all decided would be a good idea quite early on in development and after coming up with head and facial design it was just a question of deciding which ones would work best. Again, this was quite a straightforward process. Sticking with the random dream theme, we were able to design a hand full of off the wall, crazy outfits (with more to come) that really suited Tic Toc’s personality!
A selection of costumes from Tic Toc’s wardrobe.
By November 2010, we were all very happy with the direction the game was heading. Most of the levels had been built and figure tech was pretty much there. So the final phase of the artwork was the frontend design. At this point I was thankful we had come up with the whole dream theme as I thought this would be great to base the design work around.
Using Tic Toc’s bedroom as the main menu seemed like quite an obvious solution and I think it was the right decision. As it was a bedroom, using a wardrobe to link to the outfit selection screen also seemed like an obvious choice. You’ll notice that the TTBP logo is quite similar to the original rough. I wanted something fun and cartoony and I think this style suits the game really well.
As we have 30 levels in the current version of the game (with more planned in future updates) we thought it would be best to orgainise every 10 levels into level ‘sets’. As each level is a dream, we decided it would be a cool idea for Tic Toc to drop off to sleep when you press the ‘play’ button. When this happens the player is taken to the set selection menu. Here are a few early roughs of this menu.
After pressing a set, the player is then taken on to the actual level selection screen. For this I wanted something pretty simple and easy to understand. I also thought it would be useful to show a little preview of each unlocked level on the level buttons.
As you can see, the original version of the level selection screen uses much larger level numbers and padlocks, both of which obscure the preview image. The final version works a lot better.
So there you have it. There are a few other bits and bobs I’d like to write about, but I think I’ll leave those for another time. It might be quite cool to chat about some specific art techniques relating to some of the weird characters featured in the TTBP universe in a future blog so watch this space! I’ll finish up with a montage of various character concepts which you may find interesting. Thanks for reading and I hope you’ve enjoyed the ramblings of a first time blogger.
I’ve been doing a fair bit of GL ES coding recently for our upcoming more graphically advanced iPhone titles.
It’s been good fun (on the whole!) even though integrating GL ES with our multi-platform render backend has possibly exposed that our long established flexible render interface doesn’t allow for certain optimisations without introducing certain restrictions (we did encounter the same thing on PS2 but it’s probably a topic for another day).
One nice and simple method for working on optimisation of usage of an API is to use wrapper functions. In terms of graphics API programs such as PIX, gDebugger and other 3D analysis/ripping tools are (for the most part) intercepting the function calls from the application and then interpreting the data themselves in a similar way.
We’ve been doing a similar thing when debugging API usage in the past and it seems a popular technique as I saw John Carmack using a similar simple GL wrapper in his Wolf 3d code (and he had a nice additional idea I’ll mention below).
The idea works by having a private header file in your own middleware or in your game which you include in every file you would use GL or other wrapped API from (or just include it in a global header if you wish).
Inside the header file you’ll have a structure like :-
// Wrap settings, uncomment these to enable.
// helper macros
# define DO_ERR_CHECK_GL(x) CheckGLError(x)
# define DO_ERR_CHECK_GL(x) (void)(x)
// wrapped implementations
// wrapping enabled, implement each function to be wrapped
static inline void _glDepthFunc(GLenum func)
lLogSys(“GLES”, “glDepthFunc(func=%s)\n”, GLenumToString( func ));
// call the actual function
// Use preprocessor to force any references to the unwrapped function to cause a compiler error (idea from Wolf3D code, nice way to catch!)
#define glDepthFunc ERROR_USE_WRAPPED_VERSION_OF_glDepthFunc
// wrapping disabled, use pre-processor to point to actual functions
#define _glDepthFunc glDepthFunc
This implementation is done for every function that you wish to wrap in the particular API.
In the above example we can perform whatever logging we want about each function call, using helper functions we can translate things like enums to human readable strings for output to HTML or other log file. Texture data can be intercepted in glTexImage2D calls and then stored out for future reference in the log (by associating it with the correct texture ref), likewise for shader programs.
Also above we perform a call to an error checking function if the relevant #define setting is set at the top of the file, this CheckGLError function takes the string name of the wrapped function it Is called from, performs a glGetError, checks its validity and then logs / spawns a debugger depending on other current settings.
The possibilities though aren’t limited to that..
There is the ability to add redundant call checking by storing the previous value that was passed to a particular function, in the above case we can track the current internal GL setting for glDepthFunc (this works on the assumption that no other piece of code could somehow set this and break our redundancy checks – in our case we know that all our code is wrapped). Some functions are harder to track redundant state sets for but if you focus on making the code re-useable you’ll find several functions in APIs have similar usage / internal state patterns .
Another feature I added to our internal wrappers was a GL call limit, at the top of each wrapper function a call (again to a function hidden by a #define MACRO meaning it could be easily disabled and compiled out of the code). The function that the macro called would return a bool of whether to continue execution of that wrapped function. This allowed me to have a ‘stop GL functions after xxx have been called’ function, I was able to trace using a simple interface in-game where certain rendering issues where introduced and also look at draw order very easily.
Related to that is overriding of certain states, because you can stop any state being set you can force things like texture sets to not go through (or to keep the texture set to a 1×1 dummy texture to test texture bandwidth impact on your framerate) or perhaps to override the colour of each batch passed to the renderer (I’m ignoring shaders in that example but again you could override a shader if you wished).
Implementing this system wasn’t something that took very long though and it can be very useful depending on what stage of development you’re at. It’s important to spend time working out how to minimise the effort needed for each wrapper function, I think the redundancy checking could be wrapped up nicely through some well thought out template usage and the whole thing could be done via more pre-processor macros to minimise typing errors (and to improve readability).
Hopefully this idea will come in use for your API debugging / logging / optimisation work!
Things we’ve been enjoying this week
- A great post with links to all you need to know on the Kinect ‘hacking’ people have been doing. I got the code compiling on Win32 when it was first being ported to libusb-win32 but haven’t had chance to do much with it since (other than hook it up to our engine). Looking forward to seeing interesting stuff from this, markerless motion capture already starting to emerge.
Just a bit of a news update, You Are The Ref 1.1 update is out today featuring Game Center (and AGON as fallback), Retina Display, an Art Gallery and more.
Also we’ve been working with Microsoft the last few months to bring our hit title QuizQuizQuiz to Windows Phone 7 and that will hopefully be available very soon to you all.
This post has two audiences – the lovely followers we’ve gained in recent years as we’ve started on more of our own projects and the new readers from iDevBlogADay , which is an indie developers weekly blog initiative we’re lucky to be part of.
Essentially this means I’ll be trying to keep up with writing a new (and hopefully interesting) blog post every Saturday. I did debate for a bit whether to have a separate site for these posts as some people may be glad to see only a rare monthly post from me!!
We’ll be taking the opportunity to make some improvements to the site and we’re trying our FeedBurner for our RSS feeds now – please subscribe! Also if you aren’t already be sure to follow us on Twitter and Facebook.
WHO ARE WE?
Some of you may not have a clue who Four Door Lemon Ltd are (apart from being a really weirdly named British company!).
We’re a five year old games developer based in Bradford, West Yorkshire in the North of England. We started out as 2 guys, grew quite a bit with remote contractors at one stage in 2008 (while having a core team of 5 in the office) and we currently have 7 people in the office.
It’s been a very interesting journey so far and we’ve been involved in a huge variety of projects across pretty much every gaming platform. Internally we are fairly code orientated but the last year or so has seen us performing a lot more design and working more closely with our art guys (who are mostly external contractors we have had close relationships with for many years).
When we started out we aimed to earn enough money from work-for-hire and licensing out our engine to produce our own titles for 6-12months. This money never materialised due to various reasons (not helped by the financial crisis) but we survived and then ended up falling into self-publishing on iPhone (starting with QuizQuizQuiz and more recently You Are The Ref) which has led to us starting on similar fun projects.
We see our future being a healthier split of our own work across a large amount of digital distribution platforms and client projects.
WHAT’S COMING UP?
I’ve got a list of topics for the blog but looking at other iDevBlogADay posts I’m not really sure where exactly to pitch it or whether people have specific queries that could coincide with stuff we’re working on.
Feel free to post a comment on this post or to contact me on twitter with any suggestions for posts!
We’ll be enjoying the lovely sights of Paris next week while attending the Paris Game AI Conference which we’re also proud to be sponsoring.
Please get in touch if you’d like to meet up with Simon while there or at Game Horizon or Develop Brighton in the coming weeks!
Game AI Conference 2010 Press Release