Hi everyone, sorry for the lack of updates recently we’re planning to update the site soon so watch this space!
In the meantime please see below for couple of roles we are hiring for.
Four Door Lemon Ltd are looking to add to their experienced coding team with opportunities available for all levels of experience.
We are looking for people not afraid of getting involved in any section of the codebase, who enjoy gameplay development as much as technology and are always looking to improve both individually and as a team.
Successful candidates will have
• Strong programming skills with a C++ focus.
• Proven experience or suitable education and sample work.
• An interest and knowledge in more than one area of game coding.
• Good organization, communication and technical skills.
• Passion about quality, the team and gameplay.
The roles are fulltime in-house though there is some flexibility depending on exact requirements.
Please get in touch via
Also posted up at gi.biz
Apologies for the short post today, we’ve had a crazier than usual few weeks here at Four Door Lemon. Todays blog completely slipped through my Outlook task list with everything going on so I’m going to be stepping back from the iDevBlogADay schedule.
We have recently being doubling up our team from 6 core staff + contractors to a team of 13 as well exploring new platforms and gameplay possibilities. This process has been very exciting and it has been great fun finding people to fit in with the team and the culture of the company.
We’re on the look out for further work at the moment and the Develop Conference in Brighton will be part of that process following on the back of another trip we’ve had to Paris AI Conference and Game Horizon this year – both of which were great events once again.
Before the end of the month we’ll be announcing two new releases on iOS/Mac as well as updates to Tic Toc Body Pop and You Are The Ref. One of the releases is going to be initially an iPad 2 only release with some very cool fancy 3D shader graphics coupled with an awesome gameplay mechanic, lots of fun challenging levels and some of the most atmospheric audio I think we’ve had on the iOS device so far.
Please continue to follow the blog and track us on Facebook from the links on the side of our site.
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’m taking what may seem a bit of a lazy approach to a blog today by talking about our latest release which came out this Thursday 9th June. I’m going to try and cover the history of the game which is possibly a bit longer than people would imagine. Hopefully people trying the game will realise that a lot of effort has gone into us trying to get everything right with it that we can.
The game idea was originally conceived by Simon Butler (see his website here and get in touch with him if you need some great artwork), a great artist and friend who we’ve worked with for many years.
The original text description had a few major differences to the final game
- Possibility of two figures to fit through holes at once
- Pickups that come along the conveyor to provide the speed up / slow down abilities
Coupled with the description Simon had also produced a mockup video which we’re showing here for the first time
Compared to a shot from the game as it is now
You can see the UI was a bit more complicated than it is now and at this stage we didn’t have the awesome art style that Simon developed along with the Tic Toc character. It certainly had the craziness aspect and the Abraham Lincoln character popping in was great but we decided to drop (for now) from the full game.
This original video + text description were sent across on 14th July 2010, we discussed the ideas for a few months before having original prototypes around the inverse kinematics we were going to use to help the control system only be driven by the ends of the limbs.
Simon had the first 50 levels of the game put together very quickly and we had what seemed like most of the final assets by November, the implementation was still in a very early phase at this point due to other project commitments. We were however talking regularly about the plans and design for the project.
In January we started showing the game mockups around to people and getting a bit of feedback we also started working out the interface elements and arranging the game structure. We wanted to be familiar and try and emulate what Cut The Rope / Angry Birds (and many other games before them on other platforms) have done well in terms of the sets of levels and the simple advancement method that still encourages replayability by giving you a gold/silver/bronze type achievement status per level.
In early February the implementation was working well and we had a nice data driven system for putting all the levels together, we also integrated the music for each of the levels (each level has its own short loop to match the level theme). We also established the logo for the game and introduced the concept of the unlockable costumes.
At this stage we also killed off the initial idea of walls that rotate to provide an extra challenge as with the obstacles we had on later levels the game was fairly hard as it was!
During March / April we performed a LOT of tweaking of the levels, our main fear during this time was making it too hard a game as many of you will know when developing a game it’s easy to start mastering it and then tweaking it to challenge yourself but then anyone new to the game faces an impossible task.
We integrated OpenFeint (who have been great to work with) and finished off essentials like the app icon, below is only one of the many pages of icons that Simon produced before we got to the final app icon.
May and the game is pretty much done, we’ve also been working on reducing the size of the game significantly and Phil performed his research into the simple but effective methods mentioned in the last blog post I did. We switched to zlib at the time as we wanted to keep the graphics lossless while we tested and evaluated other methods further which is why the game upon release is a fairly large 149mb.
I do believe that this could be a concern for us in terms of selling a lot of copies with it to start with and we do plan to reduce this down in the future (and also make some slight tradeoffs for <20mb lite versions if we choose to release one) however with the effort put into the art style I felt we should show it off the best we can upon release and try not to trade off on that.
Speaking of the artwork I’m going to leave it for another blog post but we have a lot of in progress art images that would be great to show, some of these show the subtle tweaks we made to the menus and level graphics which I believe have left us with a very polished feeling game.
At this point we were ready for submission, our final hurdle was some approval problems in terms of our OpenFeint use causing some concern with the Game Center features we were advertising, we got this turned around in about a week and ready to launch 6 days later. This delay unfortunately pushed us into WWDC/E3 week but we felt that we should still get launched.
We’re expecting slightly slow sales to start with but our marketing push has begun and we’ll hopefully see more of this coming online the next few weeks. From that the game should pick up a bit and get up the charts, if it doesn’t we’ll be pushing out a Lite version and trying some different tactics.
I hope you’ve enjoyed this brief (and hopefully interesting) look at the development of Tic Toc Body Pop and please try the game – available for 59p/99c for a limited time .
Click the icon for a link to the App Store.
Also a big thanks to our programmer Lewis for his pretty much solo work on most of the project and Gary, Phil and the rest of the team for their contributions in either tech or feedback.
Things we’ve been enjoying this week
- Tic Toc Body Pop – oops mentioned it again 😉
I was hoping to discuss our new title announcement in todays blog but unfortunately we’re waiting on the app review so we’ll be announcing early next week instead.
Credit for the topic of todays blog goes to our awesome long-serving coder Phil Jones (@logicstorm) who did the work on the system, some brief tests and produced the graphs for the team.
Our internal 2D framework is predictably focused around sprites. We have a sprite bank tool that imports various image files (both for single images and series of images making up animations), it then analyses, splits and packs these.
The build process
- Removes blank space from any sprite (and stores an offset to compensate for the blank space)
- Breaks down each sprite into cells (varies per platform but likely 64×64)
- Each of these cells is then stored in sprite pages (again varies but 256×256 on iPhone)
- Cells that are identical to ones elsewhere in the spritebank are only stored once (so an image of flat colour repeated elsewhere or a static part of an animated image won’t be duplicated in the pages)
- For a frame of a sprite animation (or for a static sprite) we then store a list of cells that make up that sprite and the offsets to render them at.
- We then compress each of the pages and store to file.
This system has been used by us very successfully over the years and has helped us package up lots of assets into some of our NDS games while performing real-time streaming + decoding of more complex animations.
The original compression method we used was LZSS , this decoded very fast and had pretty good results for us on NDS.
We still use the same sprite framework on our current 2D games pretty successfully, we’ve found however that we’ve needed to get the size of our sprite banks down a bit further and with increased CPU power available to us Phil investigated using JPG / Zlib / PNG and a combination of these (NOTE: No actual PNG tests were done but we compare to the source asset in PNG form).
The only change we need to make is by applying a different compression method in our sprite bank tool (we already supported uncompressed so it’s just a case of storing the type of compression used for each sprite page), on use of a sprite at runtime we lookup the sprite page needed, load it from file, decompress to RAM and then pass to GL/DirectX for use.
As mentioned most of the test was only across a single large image file , the graph below shows the compressed sizes of the sprite banks versus the source PNG. For the alpha in the image for JPG encoding we tried two methods PNG stored alpha and zlib alpha.
We did produce some data across a full project to show that these results are pretty similar across a more varied data set.
JPEG is obviously lossy unlike our other methods used, the above graphs are produced at 75% quality level. We did some testing at various quality levels to show the jpeg artefacts introduced versus the source.
Below 80% the results aren’t too great for a high quality asset and it isn’t great introducing some of these errors in our very pretty artwork.
Let us have a look at how the quality compares to file sizes to see how much tweaking the level could improve things.
Decoding time is very important to us (though can be hidden by precaching during loading screens / streaming). The impressive speed of Sean Barrett’s stb_image versus libjpeg/libpng is shown in this chart. It also shows that perhaps we should have considered zlib previously in our sprite system (though the NDS might have a different performance profile with zlib versus lzss).
Across the size and decode speed results then jpeg rgb + zlib alpha is a massive improvement on our current LZSS. We’re looking at using 85%-90% for our jpeg compression quality level for final game assets.
Further things to try
- We didn’t try any of the pngcrush tools, we have used this before as a separate process and it has gained 30-40% savings on some alpha PNG images . We could have also tried this on a pure PNG spritebank storage method, it should beat the source PNG assets by a fair bit.
- Vector assets! We’re aiming not to be using purely bitmap assets for much longer, especially for some of the artwork on current projects (which would adapt well).
Things we’ve been enjoying this week