Tony Polinelli
Tarwin Stroh-Spijer

contact [at]

6/25 Easey Street
Collingwood, 3066
Vic, Australia

+61 3 8060 5321

Archive for the ‘Games’ Category

Wednesday, July 22nd, 2009

We might start throwing up some tests of games we’re working on. I hope it will be good to get some feedback – but keep in mind, this IS in development, so go easy ;P

So – whats deadsun? Thats the codename (hah how mysterious!) for my latest game, Tarwin is working on a few other things. It will hopefully be release on the iphone too (hence the format).

The sun is dead, and post apocolyptic radiation is pouring out of the sky. You need to gather it to your cities to power them. In this test, you can play with the mechanic of collecting energy from the black-holes which expel it. There will be more advanced levels to come, which involve protecting the cities, tba.

Use Keys 1-8 to flick between the levels.

NOTE: please view this on its own page (not with all other blog posts) as it probably will run slow otherwise – we are working on fixing this weakness of our blog.


Monday, April 27th, 2009


After only a day or two playing in hxcpp i’ve got my first little test to show – Jellyroids!

This gametest compiles (using haxe) out to flash & C++ (exe in the cpp folder for windows only – i dont have a mac or linux, so cant test as yet).

Running the software rendered c++ version is a little slow – ~200fps on my comp, opengl is ~1500fps. Whereas flash clocks in at 100fps (maxed out). Prerendering the explosion animation (currently vector animation from a swf) will make it MUCH faster for c++ (stop the slowdown on shoot), as i feel its vector animation code isnt anywhere as optimized as that in flash.

Overall, its fun to see how easy its been to get out a simple test in hxcpp.

download the game test here

cheers – Tony


to get it to work you need to change a few small things in the neash 0.9. realease.

There are two issues with the current release of neash that need fixing. Just change the following lines:

1/ in neash.display.MovieClip:
add in some stubs for functions (just copy in the following lines)

public function gotoAndPlay(frame:Dynamic, ?scene:String):Void { }
public function gotoAndStop(frame:Dynamic, ?scene:String):Void { }

public function stop(){}
public function play(){}

2/ in neash.display.DisplayObject:
make getRotation method look as follows:

public function GetRotation()
return mRotation * (180.0 / Math.PI);

Saturday, April 18th, 2009

Its finally time! The Scarygirl project has been in the works for about 2 years, in production for about a year and a half, and in my nightmares for quite a while. So, we are slightly excited to see it out in the wild… and not on our todo lists :P

We have been surprised by the reaction so far, 200,000+ plays in the last 3 days. We’ve had to upgrade servers twice, and are rapidly making some fixes to bugs and improvements to gameplay.

As a bit of background, the project is based on the concepts and designs of Nathan Jurevicius. He is a comic artist from Melbourne, Australia, but living in Toronto. The character Scarygirl has had quite a journey over the last 10 years, but is finding her feet in this online game (Funded by Film Victoria & Passion Pictures), soon to be released graphic novels, and an upcoming feature film. We had the opportunity to work on the project due to our friend Suren at Renmotion, and his contact with Nathan.

The project has stretched our skills and through its arduous process, we’ve learned a lot about planning, designing and developing a game. TouchMyPixel is only two people (Tarwin & myself) so the project was a huge workload. We have a background in Flash development, design, and smaller advertising style games, but not a larger scale game of any sort. Scarygirl, in its essence was only planned to be a 9 month project (sorry Sophie), but I think, in our excitement of making a “proper game”, not what people generally see a flash game to be, we overshot the timeline a little. We tried to give the game a depth which most Flash games don’t have, as it seems most flash games are focussed on being small, fun snippets of a game. We wanted to produce a full experince. I think everyone on the project felt this way, and wanted to push themselves and the project.

The game is quite artwork driven, which is obviously one of the major requirements (being to promote Nathan’s artwork). This challenged us with the task of designing a world which would well reflect Nathan’s irregular style while keeping farmiliar game mechanics. We spent a lot of time finding ways to faithfully display his artwork. For instance, we wanted the character to be able to walk over irregular surfaces, surfaces we could quickly mockup in Flash to match to the artwork as needed.

Our first stage was conceptualizing what each level would entail (or even if there were “levels”). Nathan had given us a basic ideas for some levels, and a pre-release of the graphic novel for story reference. Then it was up to use to sketch out some levels. We wanted to incorporate adventure game elements to highten the journey aspect, but also keep with traditional platform style gameplay. From sketches of characters, we would decide how they would fit into the world and react to the player. After producing mock levels without artwork (see non-graphical demo), we handed over level designs to Nathan to have them beautified. At this stage we often had NO IDEA what a level would look like, which gave us the joy and sometimes suprise when we finally saw what a level really looked like; we may have just drawn a small brown patch for tree which would come back as a beautiful peice of art. This was wierd, and made level design hard, as we really didnt have much of a concept of what we were designing, or more to the point were worried that our concepts was wrong.


Progression of level design: 1. sketch  2. level in Flash  3. artwork overlay  4. final product

After getting the graphics and adding them to levels, we found that the game ran at about 1FPS. Which was a slight issue. This brought us to the stage of optimizing, refactoring, and rebuilding all of the levels to work with graphics. In the end all of the level graphics are pre-cached as tiles of bitmaps (starting as vector to save download), as the level might be up to 20,000 x 20,000 pixel in some cases. The bitmaps then have effects such as noise and glows applied to more closely replicate what Nathan is currently doing with his art. Some levels such as the peninsula (Escapade) have multiple levels of background and foreground. We then started adding the animated characters and enemies and found they too slowed the game to a carwl. So all of the animations needed to have each frame pre-cached as well, and kept in a frame cache in memory. Every sprite then works off the same frame information. With all of this caching some levels started to take up to 600mb of memory… which was the next issue. After overcoming the many trials of technically getting the game working, gameplay testing and debugging proceeded for about five months.

As i stated earlier, we’ve learned a lot about planning and developing a game, and think we’ll fair a little better in the future. As for Scarygirl, a standalone version might be on the horizon. We’d also love to look at other platforms too, such as iPhone; not sure if i want to learn Objective C too quickly though.

Well its good to see it released. We are still be making some notable tweaks, and are taking users comments into account, so the job still isn’t over yet, but there’s light at the end of the tunnel.


Tony – TouchMyPixel

Friday, April 25th, 2008

Rendering a vector for every frame of a repeated animation (like in most games) take a lot of CPU. It takes even more CPU to have lots of complex characters on screen – many the same sprite.

cacheAsBitmap in flash is good, but only if you have static objects but recreates the bitmap data of an animation every frame, making it run even slower. The best solution is to cache each frame of an animation as a bitmapData, and then switch between them each frame. This works well until you have multiple instances of the same sprite – You dont want to pre-render the bitmap data and keeping it in memory many times, so it is best to keep a library of animations, and then reference the cached frames for each instance.

Another advantage of this technique is it seems to make use of Flash’s new multi-core support. On a dual core CPU it can, if you push it, take almost 100% of resources. Trying it on a quad-core seemed only to take up two CPUs though. I guess this is both a blessing and a curse as you’re more likely to grind a users system to a halt, even if they have multiple CPUs.

Animations copyright Nathan J. –

Monday, April 14th, 2008

I’ve always wanted to use a Joytick with my Flash games.

A while ago I was working on small game for Lorial – in-store advertising for Biotherm – through a great company Eness. It was a simple “catch the falling objects with a timelimit game” made in Flash, but needeed to be controlled using a joytick as it had to be simple and easy to use for anyone walking through Myer.

After a little research I found the amazing program AutoHotKey. This lets you specify macros to do things like using a joystick as a mouse or keys, or pressing a combination of keys and starting a program. Using this amazing peice of software (Windows only sorry) and hacking around with some of their joystick input exampels it was easy to map joystick movements and buttons to the arrow keys and “A” on the keyboard, which were then read by Flash.

On a recent game I’ve been working on (Scarygirl) I’ve found that user testing on the keyboard really gets in the way of the gameplay itself, especially for those not used to games. It was a lot easier to hand them a Playstation 2 DualShock controlller attached via a USB converter and have an AutoHotKey script running that converted the D-Pad and buttons to input. The hardest part of this is finding which button on the controller relates to what input into windows. The easiest way I found to work with this was Start->Control Panel->Controllers and just writing down a list of buttons as I pressed them.

So yeah. Easy. And fun. Some games are just so much better with a good controller – just never let me catch you playing an FPS on a console!

Sunday, April 6th, 2008

We’ve finally nearly got our 40gb of MAME running- productivity boost! It took a while to figure out, but we finally have PS2 controllers to work – conected with a USB adapter. To run MAME with USB controllers on XP i’ve found:

  1. connect controllers & test that they work in the Control Panel > Game Controllers Panel.
  2. get MAME to create a .ini file
    You need to run ‘mame -cc’ this can be done at the command prompt, or by making a .bat file
  3. Edit the ‘mame.ini’ file (should be created next to your mame.exe)
    Change the line ‘joystick 0′ to ‘joystick 1′ – this enables joystick input
  4. Press tab when in MAME to get the key setup options.
  5. Rock out!!

Our Friends:

Powered by haXe / poko cms | Copyright 2008-09 TouchMyPixel