Gaming Your Way

May contain nuts.

It's all about chosing the right door.

Just another picture post...


Screengrab of the current test version of The Hellstrom Project showing a few of the corridor tiles I've set up.
The mappings aren't final, nor the lights (will render the lightmaps later) - and it's only one of the visual styles that will be used in the game (and dungeon) - but that's another post (I don't want to give away the story yet).

Right now you can only run around the generated dungeon, though new things are added daily when updating placeholders with new models and refine/add methods.


Say "Hi" everybody ...

Small picture post this time.

This is "Danielle" (or what she looks like atm) for the RPG'ish game I'm working on in Unity. The project isn't quite showable atm, but I promise to upload something when there is more to see (like having Danielle walking around).

She'll def get a visual overhaul for the game (and this model will be used as "Generic Femal Player") as the "real" Danielle will get a lot more "pirate" to her outfit. (The other two playable characters will be quite different, but more on that ... later)

She's modeled from a foto reference with a good set of idealizing the model and she'll need some optimizing as the whole model is using 3.6k triangles atm, though she can be reduced safely to about 2k polys.

So long and back to Unity, nGFX

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

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).


I can't see you ...


Let's get right to the point. If you can see a second square inside the square on the left of the image above, chances are that your monitor is at least not too dark. Though, we haven't talked about colour yet (next time maybe).

If you CAN'T see a second square your monitor might be a bit too dark.

And why should I care?

Let's take the game that belongs to the screen I posted last time, it's dark and that is of course part of the idea. But during playtests some of our friendly testers mentioned that the tiles are to dark to be seen confortably and I was about to tell them to crank up the damn brightness.

They won't do it of course. I wouldn't. But then I'm on a colour calibrated monitor (ok, two of them). So for me all my colours are correct.

I guess I'm going to up the brightness of the tiles a bit then.



Well I'll be damned

Just a quick picture post, showing the title screen of my first personal game this year. Should be finished in a couple of days.


It's not an overly creative gameplay, but for the sake of it I wrote a minimalistic particle thingy that really makes it a glittering experience to play. Once I've got the sound in it should at least score in the mood department.


All new and shiny ...

Two and a half busy days have passed since I finally got into gear and did a reskin of our blog (ok and an upgrade of the blog software). The idea has been there for quite a while now (I guess the first test rendering of the header image dates back to February).

I really wanted to do this post yesterday, but there has been some trouble with uploads that needed to be fixed before (and it seemed that 2 javascripts have been placed in the wrong directory).

Now say hello to our new appearance and while you're at it spread the word and if you're a true fan download the wallpaper :)

Just click on the image for the 1280x1024 version, oh and please remind me to do other resolutions, too (I need one at 1920x1200 and a 1680x1050 one, so if you like something else, just post a comment.


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

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 ...


The good things in life aren't for free ...

Let's start with a little rant.

So there are all these shiny things you can do with css, alas they might not work in all the browsers, knowing what works (or to know how to fake/correct it) is for me some sort of art form. I'm not even talking about the possibilites of JS and DOM based development.
But I do believe that there is something utterly wrong with css in parts if there are people out there (thanks guys) who devote a damn good deal of time to write bloody FRAMEWORKS so that you can do something as trivial as a 3 colum layout. It gets worse if you want a header and a footer - alas not a footer that is always BELOW each of the 3 columns and not just the main column).

I needed to get that out.

What else? Ah the redesign - yet again - what first seemed a good idea, wasn't that good when done. Back to start then. (Meanwhile we just continue here.)

Speaking of things that seemed to be a good idea ...

Last time I wrote about the map format used for the current game (or that I'm thinking about it) the last one I had seemed to be a good idea too. I guess I can say that I was wrong :) .

My first idea was to a tilebased map and to create it from the dungeon data I've got out of the dungeon creation code. Basically I wanted to convert each cell into an 6x6 piece of tiles, so there could have been a wall 1 tile wide and so on.
This worked quite well until I had the idea that I don't need a tile based map at all and just could plot the floor of a cell in one go (as for the new idea I don't needed walls in the tiles) - this worked also quite well.

I could reduce the code needed to convert the dungeon by some 75% - and was quite please with the outcome as it was also quite fast, the scroller needed to plot less tiles and everybody was happy, I used simple vector math for wall/door/trigger collision tests. Untill ...

While recoding the converter there was a nagging feeling that I forgot something, that I *needed* the tile information for something and right just as I finished the converter I dwaned on my why I wanted to use them in the first place - pathfinding.


I know I could use nodebased pathfinding or some other utterly clever method (I've got heaps of books about that) but honestly there is nothing as simple as a tilebased pathfinding ... so I'm adding a simple tile map info back in (using a bool map). Joy.

Well, good thzat I haven't just deleted the old code ...


Less irritating to the throat.

Commercial time ...

"Refreshing and Healthful"

"This is your brain. This is your brain on drugs.
  Any questions?"

"All my men wear English Leather, or they
 wear nothing at all."

... over now.

Ah tv slogans, so lets get to the point of this pointless post - we're having a little break and some blog re-design coming for us. If everything works fine there will be no break, but hey - who knows ...


I don't like Zombies

I just noticed that when getting back to the prototype of "Dial Z" to continue with it. The best thing I could do with it, was to file it away (yeah I know it's just a pretty way of moving it to the trash).

I'm pretty sure I've nailed the control scheme for the time being and I did a lot of planing on this one before I started coding (I usually do, just not to this scale).
Brainstorming into a mindmap was quite fun and it revield a lot of things that needed reduction in order to get a game out of it. Being able to use it as a kind of todo sheet also helps to keep the bigger picture in view.


Speaking about views ...

First thing I'm going to code today (ok, start coding) will be the viewport. To get the "features" I want for it I'll need to do some rewriting on my tilebased scroller.
My first idea was to just use 2 of them with 2 additional layers for walls and sprites inbetween. In theory this would work out but also waste a good deal time, because some of the loops will have to run a few times. First for the floor scroller, then for the walls and last not least for the top scroller.

Combining that all into a speacial viewport class (and maybe reuse it later) will take some more planing and a good deal of copy and paste...

But first have a break and return to the dungeon generating code and see how I can fit the maps into the new scroller.

Well, we'll continue with this interesting post right after the next comercial. Or tomorrow.