GamingYourWay - Unity

Let's start all over again - or "how to handle all that weight"

nGFX — Mon, 06 Sep 2010 12:21:17 GMT

Ok, the last bit of the headline was a cleverly placed quote from someone who took Mass Effect 2 way to serious, but hey it still fits.

Our little toy based Unity game has made some nice progress over the last few weeks (with just a few scattered coding session inbetween all the other stuff that needed to be done). I'd go as far and say it is just a few 100 lines away from becoming gold (yep, in more than one way hopefully).

So the the release date is coming closer - at least that is what I thought till Friday...

And now the pretty headline kicks in. Why on earth do I want to start all over? The reason (and once I learned to handle all that weight) is quite simple:
It's a grown game, it started off easy, but then lingered it's way through some fails (talk Unity animation system and events) and a "second" floor and ended in the tab system that should showed informations as well as the ingame help.

There was quite a loud "damn fucking shit" from my side when it finally dawned on me that Unity's UI system (which, honestly is dog shit) does only handle click events and is missing the "over, out, down and up" states I've came to expect from flash. So my idea of using a rollover event on the tabs to focus the camera on an object failed badly. Before I even started to code it (the idea was to show each moving toy as a tab, then if you move the mouse over it's tab the camera would zoom in on the toy to show it in closeup - pointless but neat), plus from time to time help tabs should be added that can be ignored or read. Oh, and while I'm at it, hints to be shown on rollover for the built in level editor became quite impossible too.

Next point on the list of "things not easy to add" was "scaleability", read new decorational elements, backdrops and styles that could be bought by players so that we can earn a quid (to pay the servers for instance).

A few hours later, with a few sheets of paper used as external memory, I swallowed the bitter pill and decided to start all over again. Starting with a new map system, new "landscape" features, a more flexible decoration system, the level editor (and a way to save these levels on our severs), deciding an a service for micro transactions and, and, and ...
The tiny little game grew up, causing a lot more thought and work then I ... thought ...

Either I start again, or drop it, but I do believe that (oh did I mention I'm doing an overhaul of the visuals?) it might get some fans playing it on Facebook or through our website ...

And now: Day 1 of the development diary (oh come on, I doubt I'll ever be able to write about it every time I code on it. Just that much: next time I think I'll have a quick look at MT systems for Unity right now I'm looking into UnityTokens and Dimerocker (and if you know some else don't hesitate to post a comment).

nGFX

first post in ages - and a jolly short one too.

nGFX — Fri, 25 Jun 2010 10:10:10 GMT

I guess you won't remember me (nGFX) as for ages only Squize has done all the posting. Not that I have been lazy, but there hasn't been a single line of interesting code on my side, nor something mildly game related.

I've been coding some large scale foto archive software. To sell our really vast collection of black/white press fotos (180 000 of the 1.5 million negatives should be available in the end) and coding the backend and the frontend (with lots of ajax). Right now last bits and bobs of the user handling needs to be done and there are still a good number of negatives to be scanned (alas, thank fuck I'm not in charge there).

Ok, back to something game related at last ...

While Squize is churning out flash games like mad, I've jumped on the Unity train (of course) and been tinkering with it for a while now. I've started with porting the dungeon creation code over to C# and played with dynamic maps, which proved to be working just nicely. In order to get more out of this project I thought it might be helpfull to get deeper into Unity with smaller game.

A remake of one of my games seemed a good idea, I've got the AS2 code to look at and knew how the game should work (and added some minor additions). So here's something I've learned besides the usual "oh damnit" ...

Unity's animation editor is good enough to make things easier, but don't trust it on time critical problems.

The game involves things moving along tracks - so my first idea was to save some code and use animations for that. I wanted to use a container that I can just move from tile to tile and let the "car" move inside it from the start of the tile to the end of it, then an animation event should be fired, telling the engin to move the "car" to the next tile and start the correct animation.

I did a few tests (of course) and it seemed to work, so I did all the animations (straight tracks, junctions, ramps and so on) which roughly saved some 500 lines of code (compared to the flash version) - oh lovely - same game, less code, I was on fire.

Of course it didn't work.

I tested it locally, online in a browser and all went well until I noticed that the timing can get off the track and cause visual glitches. These showed themself as "jumping" car, where the car jumped ahead one tile for a single frame and then continued as intended. This happened every time I started a level - but not always at the same time (hence I didn't see it in my tests).
After a good night of debugging, tracing (or Debug.Log()) I found out what happend.

Unlike flash the "timeline" in Unity doesn't sync visuals and code - and in fact Unity has no "timeline" - point taken, lesson learned :| .
So this happened (and caused the glitch)
1. [engine] sendMessage -> [car] "goto next tile"
2. [car] move to next tile, rewind animation, play it
3. (glitch might occur)
4. [car] sendMessage -> [engine] "done, give me next tile"
...

Because the code isn't tied to the visuals, the code in 2 can be executed, but the visuals from the animation might start on the next frame, hence the container is moved to the next tile, but the animation is still on the last frame (at the and of the track) ...

... I ended up coding the movement in the end ...

Editor scripts can do a lot of damage (or just be utterly helpfull)

In order to get the levels into the game I needed an level editor, but was too lazy to write one - so I decided to dig into editor scripts in Unity, which allow you to do all kind of dangerous things.
I wanted to be able to drag my level into the Unity editor window, grab it and save it to a file (which works just wonderfull). the first big "shit" came when I added a function to clear the level from screen (so I could do a new level) and carelessly allowed "DestroyImmediate" to delete from the asset window (and not checking if the GameObject I want to destroy is a child of my Playground) - oh well.

Anyway, you can easily add you own menu entries, access files or manipulate your current scenes with editor scripts.

And now some screenies ...

Project Hellstrom

The ponytailed lady is just my scaler model, in the end I guess it'll be 1st person.
Right now you can walk around a dynamic generated map (with temp mapping) - A LOT of work left to do.

ToyGame - the game without a name yet

Inside Unity's editor, the first level in progress ...

Playing level 1, just crashed 2 toys ...

And with this I descent back into the hell that is js/css and html ...

nGFX

Idiot's guid to skining GUI in Unity.

nGFX — Thu, 30 Apr 2009 17:36:07 GMT

As I already mentioned, the Unity docs are not quite what I would call helpfull. I think they cover a lot and most of it will solve your problem, finding the right info in them is what really is the hard part.

Take the GUI scripting guide for instance "Reference Manual > GUI Scripting Guide", this covers everything you need to know to build a GUI. My mission currently is to create a simple form for the game I talked about earlier.
For the salutation I needed a drop down list, so I had to do it on my own, because that's the one usefull control I missed.

After a few hours I came up with this (scaled down a bit)

The form is dynamic (you can turn of the salutation for instance) and already has a working validation, but it's dead ugly. So the next task was to skin that up ("Reference Manual > GUI Scripting Guide > Customization").

Yet again the manual does a good job to tell you what you can do, but fucking lacks some basic examples on how to deal with the textures to skin up buttons for instance. That's where I got a bit pissy (although I must admit that I hate searching in boards or wikis when the solution should be in the manuals).

So the key to skinning the buttons (and the rest of the UI elements is the GUISkin file or for single use the GUIStyle. I knew that there has been a psd file with "templates" of the default textures used, but alas I still havent been able to find it again, though I know I saw it while playing with Unity for the first day (and I was like wtf?).

After skinning for a few minutes

I found the most valuable (and yet again MISSED info) in the scripting guide (after just testing it with a basic psd file) ...
So I looked at the default values of a new Skin and saw this:

And I wondered why (and how) it'll become this: .

What the manual is missing badly is the info that you can set a "fixed" border for a texture in a skin that isn't stretched:

var border : RectOffset
Description

The borders of all background images.

This corresponds to the border settings for GUITextures. It only affects the rendering of the background image and has no effect on positioning.

Why do I need to find that out by testing? (I guess no one reads through the scripting guide until he needs a specific info, I for sure do not)

By default the border values are set to:
left: 6, right: 6, top: 6, bottom: 4 ...

After knowing this it was oh so easy to just do this: to get to the buttons used above.

Oh well.

I hope that saves some ugly searching for you,
nGFX

Unity3D business model ? Seems Blurst have found it

Squize — Wed, 29 Apr 2009 10:58:05 GMT

We've made no secret of loving Unity. We cuddle up to it. We watch rom-coms with it and feign interest. Hell, we'd lick it if we could.

But as we've fallen more head over heels it's just highlighted the fact that there's no tried and trusted business model for it yet. There's no mochi, there's no big ass portal wanting to pay for that shiny shiny 3D gameplay, shit there's not even sponsors with their $500 plus source code offers.

The handful of Flash game studios like ourselves who are looking to Unity I assume are following a similar pattern, knock out some nice generic games with some added wow, and then offer it as an alternative [ To Flash ] to clients with the added carrot of an iphone version of the game. So in effect you take a hit on the costs of making the actual game ( Unless you're lucky and can get a decent budget ) but make that back via the iphone version ( One code base, one set of assets, two games to charge for ).

Flashbang have a different idea via their Blurst site, and to be honest it's a real epiphany moment reading about it.

The full article is on the Wall Street Journals site ( Which is quite a wow in itself ) and can be found here.

To cover the key points before you go shooting off over there, the idea is that you have "True fans", the fans who really dig your stuff ( A great article which is linked to in the above article can be found directly here )

"A creator, such as an artist, musician, photographer, craftsperson, performer, animator, designer, videomaker, or author - in other words, anyone producing works of art - needs to acquire only 1,000 True Fans to make a living."

They have calculated that by using a subscription based model they only need 5000 people signing up every six months. That pays for their 6 staff.

In theory that's so simple it's brilliant. Ok it's nothing new, but it's just seeing the maths laid out so simply just makes it feel viable.

We've touched on downloadable versions before, and the general feeling was that very few people will pay for Flash no matter how good it is, because there's just so much free stuff out there and Flash games demographic in terms of indie players seem to be the younger end of the market ( Although that could be skewed due to the younger end of the market being the most vocal ) who
a) Don't have as much disposable income.
b) Have the mindset of "If it's on the net it should be free".
But with Unity your downloadable game can be so much more. Enough to encourage people to subscribe to get it ? Maybe, maybe not. There are more alternatives to just giving a exe version of a game though. Subscribe to gywGames and in our racing game we'll let you design your own livery, and you can take a snapshot which all your friends can see when you're logged on to the site, hell, they can even vote for it.

It's that divergence of media that will sell a subscription. The level editor that's unlocked once you join. That comp to win a psp when you're subscribed. It's allowing players to be that little bit more than players, to let them have a direct effect on the game they're playing, that sense of community. It doesn't have to be heavy handed, it's not all about achievements and gamerscore, it's about putting a little bit of creative power into peoples hands and seeing what they can do.

That to me is the business model for Unity that we've all been searching for.

Squize.

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

nGFX — Tue, 21 Apr 2009 07:38:04 GMT

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)

Unity Plasma effect

Squize — Sat, 04 Apr 2009 18:26:32 GMT

Hey my beauties. Sorry I've been ignoring you all, I've just been pretty ill the past week or so ( I was going to say I've been sick, but I used that joke up last post ). It's me not you, honestly.

Just a short post to go with a small experiment. I've done the plasma effect to death in Flash but it's a nice little effect to play with when trying out a new language so I thought I'd see how straight forward it would be to port to Unity.

The answer is... fairly. If nothing else I've discovered that for...in is nasty slow in Unity ( All these new coding caveats to learn, joy ).

Anyway I still feel like crap, so I'm going to cut this short. The effect is hiding behind this link and it's really nothing special, I just wanted to show something after being away for a week or so. If anyone would like the source just ask in the comments.

Squize.

PS. I'm so sorry to everyone I owe an email too, I will catch up, and let's be honest you should know how crap I am by now.

I need teh codes lolz

Squize — Wed, 25 Mar 2009 08:25:00 GMT

Anyone who hangs around Flash boards for any length of time will see a pattern ( Usually around school holidays ) of script kiddies turning up, asking a million lazy questions, telling you that in spite of a lack of knowledge right now they're going to see their project through 'cause it's the best idea ever ( It's like Mario, but with guns. And tits. And rpg elements. And zombies ), that if you can just help them with the character select screen the rest of the game will be all but done, and how much can you earn via mochi again ?

I just like to push back on my rocking chair, spit out some of ma there chewing tobacky onto ma porch and grin like a hog that found the shit.

Tweening a zelda sprite isn't going to produce the best game ever ( From the best idea ever ).

So look at me now, I'm playing with Unity3D and I don't know what the hell I'm doing. I'm guessing it's not far away from the Unity equivalent of tweening a zelda sprite and yet I'm really confident about turning out a complete game fairly ( Relatively ) soon-ish.
Unity has it's quirks, and the javascript code is no as3 ( All those posts bitching about as3 being a pain in the ass, well it is, until you get a couple of games out of the way, then it becomes as natural as yawning in meetings ) but... already, 6 days into the trial, I have no desire to go back to making games in Flash again.
To me it's like going back to as1 and publishing for F7 only, it's such a step backward that it holds no appeal at all.

Now hopefully I'm not too much of an idiot to release I can just up and leave Flash. Unity may not be the pot at the end of the rainbow, for all the very lovely demos there still aren't a lot of complete games, which does ring some alarm bells, and perhaps it is a world of difference between having a nice mesh with some physics running on it all at 60 fps in your browser and making that full game ( The gulf between tweening zelda and making a game could be huge ) but... fuck me it's so good.

I've never been a Flash evangelist. I think a recent post I made on FK.games was the first time I've ever really bitched about what Adobe are doing ( And that was in the light of the windows release of Unity in comparison with the upgrade cost to CS4 ).
Basically I couldn't care less. I do like using Flash, but it's just a means to an end, it's a way for me to make games that can generate an income, a tool to do a job.
I'm not passionate about it.
I am passionate about making cool games though, albeit doing that within business constraints ( It is my job, so I can't just go off and do some GBA homebrew just for the hell of it ), and Unity seems to be far and away the best solution to that.
( I'm so glad I've not spent money upgrading to cs4, which is quite an indictment really seeing how I'm professional Flash game developer )

As a quick update to X++, nGFX was sick last week ( Well he was in bed with his nan, and that's pretty fucking sick ! Thank you ) so he's behind on things which means we're a little bit behind on where we want to be, although it'll be in selling limbo for a while even when it's done so I think the next update may just be a "Look it's live, tell us how much you love it" post.

Squize.