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.
So?
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.
So?
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 () {
transform.position.x++;
}
(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 ...
nGFX
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)
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 asp.net 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).
FUCK!
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)
Code:
/**
* ...
* @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")
this.initMenu();
}
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 ....
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. !?
WTH?
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.
nGFX
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).
nGFX
Hi,
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).
nGFX