Gaming Your Way

May contain nuts.

From script to code and back - just to discover coding again

Hi folks,

most regular readers will have noticed that we've jumped onto the Unity wagon after it finally came out for the windows world and so I think it's time to write down a few of my thoughts ...

What it is:
an easy to use development platform for 3d games (although easy, well, I'll cover that later)

What it is not:
Simply put: easy.
And it is not flash.

The best part of it is, that you can do a decent 3d based game with it quite quickly, that is if you know how to code unity (I might have twittered once or twice that the docs are not one of the strong points) and (what's more important if you or someone in your team) can do low poly 3d.

I really can't stress enough that it is NOT flash, not at all, when you get started with Unity all is nice and straight forward, but once you hit the point where you really would like to do a quick tween for the main menu, or use a fancy drop shadow on your font ... you'll probably start cursing and wish you could use a timeline and some keyframes.

One of the really big letdowns for me was to discover that a quick, easy and nice UI is not going to happen fast in Unity. You can get away with it if you don't need dynamic text to appear, but I need to do a lot of stuff with that, because nearly all of our games are prepared to be played in at least two languages.

How does all that relate to the title?
When I first got in touch with flash (6 I think) AS was really nothing more than a scripting language, coding for the best part was ... shit and most of us messed with onEnterFrames per movielclip. Then AS2 hit the light of the day and with AS3 it came very close to real coding ...
But when I entered the Unity world it seems like the old distributed scripts came back to haunt me. You've got the choice of using a set of different languages: javascript like, c#, boo and some others.

JS on the one hand is easy to use, ridiculously lose typed and commonly used. I really don't like lose typed coding, so for me it was c# ...
Anyway something that commes very close the the old MC based onEnterFrame is Update ... so a script that would move the object 1 "unit" (since we have no pixel) to the left would be:

function Update () {

(or something very close to that, I said I use c#, oh and I'm sure I saw some other methods to do the same)

Save that as a ".js" text file, add that to a cube on stage and viola (there you have the back to script part covered).

I hope you won't be doing that for a complex game, but ... thinking back ... I knew people who did that with flash  ** shudder **.

As I already mentioned, I hate lose typed coding and as I used c# for some years now for coding anyway it was a logical choice (that and the fact that I could continue using Visual Studio).

Oh and did I stress that there is NO timeline?

Everything you want to have animated either needs to be coded (ie for dynamic text) or already be animated in a 3d app ...

Oops, I think I need to get back to work ...


ps: just to have something to look at a screenie of the menu (the start of a camera move) of my "test" game to see how I get along with Unity, if everything works well, I might be able to invite for a private beta test on Friday (give me a shout if you want to) ...

(the text for the menu was a big lesson in cheating, it uses GUI.Button, btw)


Thank you for wasting my time

This is going to be a rant post - yeah!

If your following us on twitter, you might have noticed my tasks for yesterday:

"Quick update on the CMS then coding on the first unity game"

Well, I didn't get to the unity game part, thanks to some weird flash (bug) that wasted 5 fucking hours of my time and still is inresolved. Here's a quick rundown:

For our new german site I wrote a simple flash based menu/header which reads in an XMl and takes two params. The xml reading was all done, but I needed to pass the params from the page to the header. I decided to use loaderInfo.params for the sake of a quick and dirty solution and then it all went down the drain ...

Testing params in THE IDE doesn't work, so I published a HTML page withit (I did mention that so far the menu worked very well?).
But opening the file locally in FF 3.0.8 did do nothing ... no menu generated from xml, it just showed the background shape.

OK, lets try in IE (6, 7, and 8) and it worked just fine, params passed, menu displayed.
Chrome worked, too, same with Opera...

FUCK! Why doesn't it work in FF?

Next thing I tried was to upload the whole lot and tried it from the server - and look it worked in FF, too. ONE FUCKIN TIME! After the file was chached it quit working just like it did offline. (All other browsers still worked just fine).


K, let's add some outputs to the loading process - and viola the problem was quite easy to nail down ...

Here's a stripped down version of the code: (I used a document class and a single frame with a few vector shapes on it and some textfields with an embeded font only)


* ...
* @author nGFX
* @version 1.0

package {
    // skipped imports

    public class Preloader extends Sprite {
        public function Preloader() {
            stage.scaleMode = StageScaleMode.NO_SCALE;
            stage.showDefaultContextMenu = false;
            stage.quality = StageQuality.HIGH;
            trace("init preloader");

            this.loaderInfo.addEventListener(Event.INIT, this.initDisplay);
            this.loaderInfo.addEventListener(Event.COMPLETE, this.initApplication);
            this.loaderInfo.addEventListener(ProgressEvent.PROGRESS, this.showProgress);            
        private function initDisplay(e:Event):void {

            trace("init display");
        private function showProgress (eProgress:ProgressEvent):void {
            var fPercent:Number = Math.round((eProgress.bytesLoaded / eProgress.bytesTotal ) * 100 );
            trace("Loading: " + fPercent.toString());

        private function initApplication (e:Event):void {
            trace("init application");
            this.loaderInfo.removeEventListener(Event.INIT, this.initDisplay);
            this.loaderInfo.removeEventListener(Event.COMPLETE, this.initApplication);
            this.loaderInfo.removeEventListener(ProgressEvent.PROGRESS, showProgress);
            trace("loading language")
            Locale.loadLanguageXML("de", onLanguageFileLoaded);
        private function onLanguageFileLoaded (bLoaded:Boolean):void {
            trace("language done")
        private function initMenu ():void {
            // some code here


As you can see there's no magic added to that code.

Running the swf through a a html page using FF showed the following:
- init preloader
- init display

... and nothing more ....

Self reflection ....

Hi all.

Back on coding CE again (at least for a few hours today) after spending a good deal of time coding and designing the backend for MYW, writing a tiny versatile CMS and doing some 3d for X.

So today I'm  going to ask myself why the hell I have done a few things in CE the way I did them (I bet you are a lot wiser now).

Let's raise the question if it is worth to add the extra amount of work needed to draw a hard line between the game's "engine" and the game's UI - for your average flash game.

You may have noticed that neither Squize nor me tend to make out lives overly easy when it comes to games, for some odd reason we both tend to try to give out very best for each and every game (even if it is a pain in the back) - well call that stupid.

Give me a good reason to split game and game (play) UI ...
The best reason I can come up with is: reusability, and it is also the least used one.

In most cases I can come up with there seems to be no reason to really split things, because the game is a one-of-a-kind thing. Even for games that share a good deal of similarites (like Wintertales and LogiMotion), a whole lot of things need to be rewritten in order to reuse the engine.

That leaves the reusability inside a single game. !?


Inside a single game? Yep!

A good deal of our games either uses an ingame editor (although not usable by the player)  or uses an external editor to generate the level data. Mostly, but not always they share the same visuals. For instance the editor for Logimotion uses smaller tiles than the game itself (so have room for the tools and don't have to scroll the map). That is a good reason to split things between the UI and the "engine".
Another good reason is when you have a stupid designer and you just code - you know those guys tend to be smart and change the size of the assets as often as you should change your underwear.

So why question that and not do it all the time?

Well, it takes a good deal more planing to really split things up. in an ideal world, the "game" knows nothing about the UI, but it still has to control it (ie. update the score, display infos). In my case this is done using callbacks.
A good example might be a game we did (but still isn't playable online): CC

(CC game, using 40x40 tiles)


(CC editor, using 32x32 tiles)

As you're meant to be able to play the game inside the editor (without leaving it), the engine had to cope with different tile sizes and environments.

So whenever the game needs to comunicate with its surroundings I provide a callback method, if I would have made it "the right" way, I should have used an interface for that, but ... hell you can overdo it too.

To make it easier and not having an endless number of callback methds I used only a few and gave them params (which are stored in the game's class as constants: like:

public static const UPDATEUI_INFO:uint = 0;
public static const UPDATEUI_BTNPLAY:uint = 1;
public static const UPDATEUI_ITEM:uint = 2;
public static const UPDATEUI_WIN:uint = 3;

Whenever you finish a level, the game would just call the callback provided for UI updates and pass the parameter needed.

And is it really worth the extra work?
Not always.

I like to spend that extra piece of work for games that require and editor or might have parts in it that seem to be a good start for reusing it in a second game. Sometimes you notice halfway through the project that you need to change something to make the game work again (ie. different tile size, or different UI), sometimes (like I did for CE) you notice that the game will be a one of and you cause yourself a good deal of fuzz for "nice code" only.

Well, lets get back coding CE.



(Update on that):

So that's finally done. My own personal "get away from my beloved 3ds max and start with c4d" tour.

Basically I was a Max user since v1, so it's quite hard to forget about all the nice things it offers, though the deal for c4d was just that tiny amount better (price/what has the software to offer) so we switched instead of upgrading Max to work with Vista.

Now at first c4d was a shock. Nothing worked like it "should" a lot of things where at a different place or worked just plain different due to the very different background/history of the software.

As always it was so utterly depressing to not be able to do the easiest scenes, what should have taken just a few minutes to set up, now took a whole day.
When coding I and getting into a new language, I basically recode a very simple app, this helps to see the differences but I still can compare the code with other languages ... when I first started with AS3 I wrote this (you may have seen it).

Now there is something similar for me with 3d ... and this is the story (and it has pictures, too) ...

Lets start with the inspirational image:
It's one of my all time favs. An image from Magnetic Scrolls' "Jinxter" (if you have never heard of either the company or the game ... have a look here or here).

Lets start with creating the "guard"
The low poly mirrored mesh.

The smoothed (final) model.

Next to do on the list was the arc ...
The arc with some additional stones, so far it wasn't all that hard ...

OpenGL Display.

Now modelling seems to work quite well, on to scene composing (more images are comming).

Final scene layout.

Preview rendering, way to bright.

Added some trees behind the camera, better now ...

Final mode rendering, earliest scene layout, just some basic textures applied. The trees behind the arc need redoing, the cliff in the background is a joke and the plants in the foreground, well, I don't like them. Sky needs work.

Final mode rendering, sometime inbetween the image above and the final layout. Some ferns update, added some ivy to the walls, remodeled the cliff and added the two statues, still some work needed on the nature part. The sky seems ok now.

The final image after a good week worth of work. Most of the plants have been replaced, redone. Done.
Get a larger version here.

Scene stats:
- 29.045.199 polygons
- 1 light (sun)
- 91 objects, 231 plant instances
- rendertime 1600x900 px: 2h26m.
- postwork: none.

And while I'm at it ... we have new shiny pong clock :).


Writing a blogpost about GYW posting on twitter ...

So ... thanks tothe blessings of web 2.0 (and the machinery of stupid terms) we're able to give you even more insight into the hard work that we call game development.

No, not only can you see what we're doing on your beloved develpment blog, but now have even more updates aorund our daily work (that is, if we can remember to do so) on twitter ( - so come on, be a follower.

And tomorrow we may be able to take over the world .... Hahaharharhehehehihihohoarghlphzgmph.


Where have the days gone to?

So I have rencently finished a bigger update on a client's website, dealing with all the nasty and ugly shit one would rather like to avoid (to name just one: css - what was wrong with the good old table layout? OK, I know what was wrong, but dealing with all the browser's shitty problems to make it look nearly the same is just ... well, shit)

Meanwhile Squize was hammering out post after post so I didn't felt too bad being quiet.

Now today I actually have something to post, so here we go ...


This is a single frame from the X menu/background animation I've been doing. It'll take a while to render so I have to set up the network renderer on Monday to get the 30 seconds movie out to an flv file (which then will be played in the X menu) ...

If you're a fan of that game already, why not use that image as wallpaper? You can grab the 1024x768 version here.
Bigger Versions are rendered tonight and will be posted later this week - and maybe (if rendertimes for hi-res vids aren't that high there might (really just might) be a screensaver ... we'll have to see).


Half of the fun ...

What has been done on Calisto Eclipse so far:

  • the main menu is done, all the neat rollover effects are in place
  • you can reach the two highscore screens (one for the action and one for story mode), alas the backend for that isn't working yet
  • the medal screen is in place and the medals are defined, same as above the backend isn't done yet (more on that later)
  • parts of the API for handling medals and scores are layed out (yet again ...)
  • the game working is layed out and waits to be coded
What's need doing (in no particular oder):
  • transition between the menu screens and the game
  • the game :)
  • finish the API for medals and highscores
  • the backend for medals and highscore (oh there's so fucking much to do on this bugger, but maybe I can give away some more infos soon)
  • ingame help
  • ingame newsfeed reader
  • even more backend stuff ...
  • even more of that oh so boring backend stuff ...
what a boring post. damn.

I post an image next time, promissed.


Meanwhile at the other side of the screen ...

So what was his task again? Playing tetris with parts of the station that was meant to be built on Calisto?

What the heck.

Anyway it seems easy enough.

"No worries," they told him. "this is just a simulation right now."

"See, each of the modules has one, two, three or four air locks. The problem is that they can't be moved on their own. So all you have to do is to make sure that there are no unused airlocks. Once you have a closed set of modules, they can be filled with air and moved away from the landing site."

"Erm ... yes?"

"Yes, the orbiter is releasing new modules in a set interval, so obviously the landingsite would become a junkyard if we don't move away the modules fast enough. That's why we have this terminal, you coordinate the dropping position and make sure they connect to closed stations, before the buffer space is filled up. You can even swap parts of unfinished stations in order to build bigger ones - bigger stations are easier to move, so you'll get a higher scoring."

"OK. What is this other mode? It reads Action mode and Story mode?"

"oh, yes, easy ... Action mode is the test mode, you simply keep going until the buffer space is full, the release rate gets higher every stage. Story mode ... well that is the real deal. You're going to bring the station down to Calisto's differnt landing sites, there are different tasks waiting for you, ie. build a station with a specific size, or fill the all the empty space on a landing site - we'll give you instructions along the way."

"K. I think I get that."

"Fine, see you in the orbit then, Commander."

... That's what Calisto Eclipse is all about.


The good, the bad, the ugly ...

long time no post (but Squize has pretty much made it needless).

What happened so far ...

After a few days off from nearly everything except gaming (on my new shiny plasma) I finally got back to work on Calisto Eclipse. I decided to go the hard way and rewrite most of the menu code (before I even started coding on the game) and ended up with something I might just call the "ScreenFramework".

Basically I usually use the same style for coding:
1st there's a Singleton main controler class through which I can access all the low level stuff, because I hate having to post around references or "crosslink" classes.
This class also provides access to the ScreenFramework (name might change to something catchy), the SF class allows an easy way of switching screens using a predifined "transition".

So to get from "mcScreenMenu" (currently active) to "mcScreenMedal", it's just this (pseudo code):
SF.showScreen("mcScreenMedal", [optional transition code to use]);

... attach the new screen, perform transition, remove the old screen

All screens are "self contained" so before removing them I call the "dispose" method (did I mention that all screens use the SimpleScreen interface?), which cleans the mess the screen has caused in memory and might set a few things in the controler class.

As Calisto is also the testbed for another project we have been tinkering with for a while, it's not just developing the game but also a lot of backend server stuff, which is a pitty, because I really would like to share a good deal more of the development process for CE (although, after having the screen handling nailed I might just show that for the sake of it).


2008 in words and pictures

It's time for our annual review of what we've managed to achieve over the previous 12 months, so bring that hangover and stale mince pie with you as we go back in time and space...


This saw our first birthday, and Olli experimenting with web servers and the Wii. Quiet month, I'm putting it down to hangovers.


The most loved up month of the year saw what has got to be one of the most camp games ever,


Loved Up, a rainbow islands inspired platformer. Turned around in a really short time scale ( It's development can be followed here ).
"Critically" ( Read: By boys who write teh shizzle lolz ) panned, it went on to do pretty huge traffic as soon as it made it to to the girl orientated sites.
Not a great game, but much better than it's feedback would indicate.


Olli kept us up to date with what could well be his longest development ever ( Still going ! ), and in terms of work, we had the following:


Golden Balls. Completed the year before in under 2 weeks, someone else had finished off the server side intergration ( I'd finished the Flash before the external company that does the clever secure stuff had even looked at the spec I think ) and added some more eye candy and a couple of graphical hic-cups.
A simple bread and butter project that pays the bills.


Professor Sauernoggin and the Landfill of Doom! My baby. So much love went into this game. Marmotte over delivered on the art by a huge amount, and for that I'll always love him.
A game to be proud of, just a real pity the client seemed not to understand the value of it ( As of right now, it's had a mere 41,979 hits. It's totally buried on the clients site, you can't even get to it from the front-page. I sent them two html pages to sit it on, and they used the holder page from the client area we'd set up, not even deleting the text, just setting it to black. Honestly, take two seconds to look at the source of that page. Quite a kick in the bollocks after putting so much love into this game ).
An enjoyable development, as much down to the people who worked on it as the game itself, just marred slightly by the lack of promotion and the drawn out sign off phase ( It was ready long before Loved-Up, which used the same engine, but came out a month later ).


Chimbo's Quest is an old one to finish this busy month off with. I'm not sure how much more needs writing about this here, I guess if you're interested and didn't catch them first time around, the player stats post is quite a good place to find out more info.


The 1st saw me go a little bit too far down the sick boy path, something I'll learn from for this year. Some general development posts about Orbs ( Still in development ! ) and Law of the West.
After March's mental release schedule we were due a break, so only two games this month,


MJ-1912 is a really old reskin of my first ever complete Flash game ( MJ-12 ). I recently sold the source of this to a mate, and made more than I have with the gameJacket ad revenue from it.
I like it as it's a slightly hammy feel to what is at heart a pretty solid Space Invaders clone, it's just that Space Invaders isn't that great a game in itself anymore.


Brain Voyage / Brain Benders. A port of the Edios DS game which I did whilst under contract at gimme5.
The good ? First as3 project, nice to do lots of mini-games again ( That really seems to be my thing ), the presentation is really good ( I love being able to do really really accurate ports, another one of my on buttons ) and the face book version was a nice touch ( And seeing Jon Hare had played it ).
The bad ? The games themselves were pretty piss poor. Also my biggest issue with it was the ad at the start. If you're doing an adver-game, don't be cheap enough to drop a fucking mochi-ad in there. I know Edios were having cash flow problems at the time, but honestly, that $5 isn't going to make much difference aside from making you look cheap. Very cheap.

And that was April.


Just the one release this month, but it was a big personal project,


The Law of the West, Olli's homage to the old classic "West Bank". In development for ages, Olli finally got it released only for us to suffer one set back after another with it ( It being hacked to high heaven was one low point ).
In terms of a game, it's pretty good, the presentation is great and it's done ok-ish traffic without ever really taking off and becoming a huge hit.


Aside from making it to 36 without anything too bad happening to me, June also saw a couple more releases.


Phantom Mansion. Looking back over the blog it seems that the last one ( "Black" ) was finished this month. I think I must have done 4 last year then, and reached the point of not even blogging about their releases.
If truth be known, a really fucking horrible project, one I was only too glad to see the back of. Huge fan base though, which is weird. PMII is out now, some cheeky sod copied the format and posted on FGL. Matt at gimme5 saw it, knew I'd rather wake up next to my mum than ever do another PM game, so got this guy on board to do the next 6/8 games. There's a moral there somewhere, not sure what though.


Big Bod Says
. Tiny little game, which somehow stretched to taking 9 days in total. There was no GDD for this, and I had a 15 min chat with Ricky the designer of it before getting to work. Couple of days in and it turns out I'd got the wrong end of the stick, so I basically re-wrote it one morning, only to discover that was wrong, and finally nailed it in the afternoon. So in effect 3 different games in 3 days, and then 6 days to finish off the love.
Kinda fun, and the speech is just a different class.


Law of the West pinball. This was done much earlier in the year as I wanted to learn how Box2D worked and pinball seemed the obvious choice. Unfortunatly at the time Box2D didn't support bullets in as3, so the ball would quite happily fly through objects at high speed.
When v2 came out I was finally able to finish this bad boy off, and to whore it around for sponsorship. It was offered the vast sum of $300, which would include the source code, although wouldn't be exclusive ( Too kind ), so we just dropped it into gameJacket.
In terms of the game itself, I really really like this one. It's one of the few games I've done I can actually just switch off and enjoy playing. For a lot of other people it really missed the mark, and has failed to do the traffic we would have liked.
The maim positive to come from this is that it's been included in 8Bit rockets new Retro Hall of Fame, which is really cool, although I have had to send Jeff and Steve lots of photos of me in the bath for it to be included.

In June I also posted how I do a preloader in as3 / Flex, which seems to be our most hit page here.


We did things, and we wrote about them, but we didn't release anything new to play, so let's skip this month and move on to...


...much the same as July.


Just more words. Come on, we were productive for the first couple of months of the year.


And back on form. Where did this month take us ? No, not roughly from behind, but on a mixed voyage...


Son Of Sico. An Air front-end for our simple little action script mangler.
We've had fuck all feedback about this, nothing. Also 1 reply when I sent the GYW Encryption package out to friends, so as far as we're concerned either people don't give a shit about their stuff being hacked, or they just don't want us to help them from preventing it.
Either way both projects are internal only now, life's too short to try and give things to the community when they don't want them ( Check me out being all bitter on New Years day ).


Operation Cortex: My entry into this years 48 hour FlashKit comp. It didn't win. I've linked to the post rather than the game, as the source code is also available there.
I liked this game, and it was pleasing to be able to do a 100% complete game in something like 12 hours, it makes me feel like the sponsorship kids who always say things like "Well I earned $16 an hour from my game which is more than I earn working after school, and it only took me 5 hours to make".
I think this game may re-surface somewhere else, with a lot more love and a bit more depth.


651 Announce. Released on 20th October, which numbers fans, is exactly 651 days from when GYW came into being, way back on the 9th Jan 2007.
I'm so proud and pleased with this. It is just pointless eye-candy, but all the best eye-candy is pointless. If you've not seen it, it's a collection of demo effects all done in real time.
The blog posts in Oct. cover how a lot of these effects were created if you're at all interested.


This saw more words ( Including my "Help me" words when it came to giving up smoking, plus a death of sorts in the family ( The 360 went to console heaven ) ) but no more toys, so let's move along to what is apparently the most wonderful time of the year,


To finish off the year, a release each.


Gameball Maize Maze. Our first project with Brandissimo, a creepy iso game with a really rich art style.
It's development was covered in an almost diary like form back in September with the last update being this one.
Again I'm happy with this one, it's development took longer than I'd hoped, but the extra time spent on it was an investment as to cut it too short would have been to really rip the guts out of the game. On the downside, you have to register to play it, hence the link there going to the blog post rather than directly to the game.


Handigo ( You'll find it sitting in the games column ). This was like the previous years Fuel Factory-Y / Model City, except this time it was Olli jumping in to fix other peoples half done code for the simple lure of cheap dirty money.
The main menu is 100% low fat gyw code, along with various bug fixes ( Esp. game 1, proof that in actual fact you can polish the odd turd now and again ).
Pays the bills, and the credits were nice, plus working for Ubi-Soft has a certain kudos to it, and by all accounts they were quite lovely.

Other blog highlight this month was the ( Still going ) development of X++ in the form of new build being uploaded straight to the server, and the fantastic Zombieland post mortem by Pany ( If you missed it before Christmas, take a read of it now, it's one of the most honest accounts of a Flash game development and aftermath you'll read anywhere ).

And that was the year that was. I'm going to avoid making any predicitions here, as to be honest, I really can't see the point. When people do them they're a mixture of the stupid ( "Nintendo to release a Wii Remote Contact lense so you can just look at objects to interact with them" ) and the obvious ( "More games players to buy more games", "Women to buy casual games more than men" ), and who checks them ? Who actually goes back to the year before and reports that the stupid ones didn't happen, but hey, you were right about the obvious ones, spot on man, wow. That's like a gift you've got.

Also another reason not to do any predicitions, is 'cause I actually checked back at what I said this time last year,
"Coming up we've got the platform game ( Which I'm really proud of. It's on par with GOL in terms of love and quality ), the continuing Phantom Mansion games, Orbs and Olli's got a great old school game that we've been commisioned to do."

The first two were done, the second ? Still in development limbo. I don't want to jinx anything by making some big stupid sweeping statement about it here.

What I would like to do to finish off though is to thank all of you for taking the time to come here and read our crappy outpourings when we make them, and to wish you all a Happy New Year and we hope you'll stick around during '09, 'cause if it all goes to plan we'll still be releasing games and still talking about them.