Gaming Your Way

May contain nuts.

Knight's Quest, the story so far...

Sorry we've been a bit quiet here recently, both Olli and I have been beavering away like a couple of mentals on projects which hasn't given us any free time to devote to the blog ( Also we didn't have that much of interest to say ).

Knight's Quest, our first Facebook and our first RPG, has been my main focus for weeks. It's finally starting to come together after weeks of just working on the techy side, so I thought it may be of some interest to go over some bits and bobs from it.

The game is iso, which is a pain at the best of times. Z-sorting is murder. How I've gone about it is to split the map into sectors. Each sector is 16x16 tiles, and we only z-sort on those visible areas ( Also we turn off any plotting in sectors which aren't visible ).
This really reduces the sorting to just what is needed, also the floor tiles are burned into their own bitmap ( See this old post ) so we're only having to sort tiles and sprites, which helps.
Also as we're using the blitter we don't have to worry about sequential indexes, it's like as2 all over again, where you could give a sprite any old depth and not care about it.

Next up, the dungeons. I've used Olli's generator ( He's written tons about it previously ) and it works a treat. Basically it creates "cells" which are in this case 4x4 tiles. The cells tell us which walls or doors are present. Rather than just randomly plot tiles I've set up a lot of mc blocks, eg.

KQ_tiles.png
This may be tricky to explain well so stick with me. As we read each cell we know what's there, let's say for example a north and east wall. From there we look up the array which contains all the blocks with a north and east wall and pick one at random.
The floor is burnt into the background bitmap and the wall tiles ( Or cauldron placeholders ) are converted into blitter sprites ( Bobs ) which can then be plotted / sorted etc.
The reason for this is that we can then hand design a lot of different wall blocks and use them randomly ( Rather than just picking one random tile at a time ). It should make the dungeons look more hand designed, which is what we want.
It's important that we create the impression that someone has slaved over each dungeon to make it look as non-random as possible.


I think that's about it for now, there will be more to share real soon.

Squize.

I can't see you ...

colours.jpg

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.

 

nGFX

Much ado about nothing

I think it's time for a little recap, if for no other reason than to show we're still alive.

Work has started on our first RPG / Facebook game, "Knight's Quest". It's a whopper of a project.

So far most of my time has been spent on the boring techy part.

Firstly I figured out a way to do terrain splatting which should work nicely. Basically that's how most 3D engines, including Unity create their terrains ( Speaking of which, have a google for the previews they've been releasing for v3. I know 3D proper is meant to be coming to Flash in the next couple of months, or at least the announcement of it, but Unity is looking more and more stunning every day. If only there was a good web based business model for it I'd ditch Flash in a heartbeat ).
Basically you have up to 3 textures ( Any more and Flash was giving me artifacts for some reason ), in our case movie clips made up of 1 iso tile repeated over and over. By using gradient "Brushes" and the erase blendmode you can remove as little or as much from each texture as you like.

terrainSplat.png

So in the mock-up above the base texture is the grass, on top of that the soil which we erase so only that part you see there is showing, then the road is the 3rd texture, where we do the same again. Basically we're erasing pixels at different alpha transparencies.
The game takes these different movie clips and bakes them all into one big bitmap, which is a bit costly in terms of memory as it's a big ol' bitmap, but in terms of filesize it's nothing, as we've only used 3 tiles and a handful of brush movie clips, it shouldn't be anything more than 20k at most and in-game moving 1 bitmap around is nice and quick, so it's all good.



That's just a test, the final ground will use bigger tiles for the textures, and then we'll overlay a normal mc on top containing flowers / grass / rocks and pebbles etc. and bake that into the same bitmap. We should end up with a really nice art based look at min. cost, much much cheaper in every way than just tiling the whole floor.

As usual I've written more than I planned, so I'll save stories of path finding and z-sorting for another time.

Squize.

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

fotoarchiv_00.jpg

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

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

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

toygame_01.jpg
Playing level 1, just crashed 2 toys ...

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

nGFX





Blitter engine: Benchmarks

Ok, before anyone says "You said you weren't going to do any benchmarks, you said. Wanker" I had a rush of inspiration the other night to improve the blitter engine, so I figured I need to have my own benchmark test to make sure I'm not just wasting my time.

And because I'm a giver rather than a taker, I figured it wouldn't kill me to do a pointless sprite based one just to show how slow they [ Sprites ] are.
Before we go any further, I'm busy working with our new favourite client ( We may even have a game to show next week. Yeah, actually producing something rather than talking about it ), which means I'm knackered, which in turn means the examples are as ugly as you like.
Also it's not a case of getting them all running as fast as possible, it's to show the relative speed between them. We're not trying to break records here, it doesn't matter how high we piss, more how the three approaches compare to each other.

The first test just uses sprites with a bitmap for the scrolling background ( ie, the background isn't wrapped in a sprite, it's just a bitmap added directly to the stage ). For this test we only run a 1000 sprites ( Ha, only. In Flash5 that really would have been a record ).

Test1

Yeah, ugly and not even embedded, but it's only for us to see. All the tests can take a little while, once all the sprites are active you'll see "Finished" and then it's worth checking out the fps.

Next up it's a test using bitmaps, like the scroller they are added straight to the screen. 3000 of the bad boys this time.

Test2

You should roughly be getting the same fps as the sprite test, but with 2000 more objects running ( I get around 31-35, but let's not get too hung up on the actual frame rate, as I'm running snow leopard on a macbook pro and using Firefox as my browser. You more than likely won't be, it's all about the relative speeds ).

Final test, 3000 bobs a blitting, and the scroller background is also being blitted.

Test3

Now for me it runs slightly quicker than test2 in the browser ( I'm not running the debug version in the browser ), but locally the bitmap version ran faster by around 5fps or so.

I'm not overly advocating the blitter approach compared to bitmaps, I'm not trying to sell the blitter engine to you. Bitmaps give you a lot more of everything, you get all the lovely blendmodes, rotation, alpha etc. All the good stuff you don't get in a straight forward copyPixels() engine.
The advantage of the blitter engine is that it's better suited to mobile devices, it will run better on an iPhone than a bitmap approach. Moot point I know, but don't forget we're all going to be writing Android games real soon.
Also the framework for dealing with layers is there and working, if you're using bitmaps then you've got to write your own framework for such things ( And if you do, please post it on your blog so I can get a copy ).

Let's recap as it's late, bitmaps are great, the blitter engine is pretty sweet and sprites are like poking a stick in your eye.

Squize.

Blitter engine

I thought I may as well open source this as it may be useful for some of you.

Let's start with the all important caveats.
I'm not going to be showing you a load [ Or any in fact ] of benchmarks or examples, I can think of nothing more boring to do. Either take it on faith that it's fast, or just use it to look through and nick the bits that may be helpful to you. I'm not trying to prove a point with this that my code is so l33t. I've found it useful, if you do to then cool, we're both winners. If not, well you've not lost anything have you ?

Again another life's too short thing, I really can't be bothered with sorting out a license for this, is it MIT or is it GPL ? I don't really care, it's not something I hold close to my heart, it's a bit of code to do a job. If you do tinker with it and make it better it would be nice to share what you've done, if you make a game using it and you make a ton of money, great. A credit or even a shout about it would be cool, but if not, then I'm not going to hunt you down with an angry mob.
The only thing which would piss me off is people passing it off as they're own, but we've got a wanker free readership here so it's not going to be any of you guys, and there's not a lot you can do about the sort of idiots who would do that anyway.

There may be bugs, there was some experimental iPhone and pixel bender stuff in there which I've just ripped out. If you spot any thing dumb please flag it up, it would be nice to have a fixed version available here for people coming to this further down the line.

Ok, let's go over the usage.

The static Canvas class is the main part of it, it's what makes it tick. To set things up just do a simple,

            Canvas.init(stage,new Rectangle(0,0,600,500),true);
            stage.addChild(Canvas.viewport);
 
stage is your stage ref ( Surprisingly enough ), next up is the size of the canvas ( The canvas is the bitmap which everything will be blitted into, the viewport property ), and are we going to be transparent or using a background ? You decide with a boolean. You can also pass a fill colour as the final parameter if you don't want to use a bitmap as the background.

Next in our hierarchy is the PlayField. Think of this as your container sprite. I don't know about you, but I miss working with layers in as1 via the timeline, so I've always simulated them with container sprites. PlayFields are pretty much that, eg

            var defRect:Rectangle=new Rectangle(0,0,600,500);
            gridPlayField=new PlayField(defRect);
            baddiePlayField=new PlayField(defRect);
            playerPlayField=new PlayField(defRect);

            Canvas.addChild(gridPlayField);
            Canvas.addChild(baddiePlayField);
            Canvas.addChild(playerPlayField);

From memory I don't think the engine actually does anything with the rectangle we pass to it, I think I was planning to do some simple clipping, but never got round to it, but pass it in anyway it doesn't do any harm.

When it comes to rendering the display, the Canvas class loops through all the PlayFields in the order they are added, so the gridPlayField in that example will be plotted first, then the baddiePlayField and so on. It's a simple way of simulating layers / depth.

Finally we're onto the Bob class. These are your Blitter OBjects, your software sprites. To create one,

            var temp:Bitmap=new playerBM();
            bob=new Bob(temp.bitmapData);
            playerPlayField.addChild(bob);

You just pass it the bitmapData you want, and then add it to your PlayField. The Bob class has all the properties you'd expect, and supports animation too ( So bob.gotoAndStop(bob.currentFrame+1) works, check through the class on how to pass it an animated sprite sheet ).
Where possible I've tried to make things as close to the display list as possible, there's no need to be forcing a new syntax onto yourself.

Like the PlayFields these are plotted in order ( The PlayField is basically just a list of its children ), so add them in the depth order you want, exactly like adding children to a sprite.

As with all blitter engines there are restrictions due to using copyPixels, so forget all about rotation and alpha and blendModes. A pity, and I did start with a ComplexBob class that used Draw() for those things, but to be honest it was a real arse ache, and it's quicker to attach the bitmap directly than to use draw ( The downside to that being the bitmaps have to be above the canvas, there's no way to slide them in there between PlayFields ).

There are quite a lot of properties and methods available to you in these classes, auto-complete is going to be your friend with this.

One last thing, the Canvas uses the RENDER event to refresh the screen, so there's no need to call anything in your mainloop, just by altering a bob's x position it'll refresh for you ( If you're not going to use the actual package, I'd recommend having a look at the Render event stuff, you should find it quite useful if you're doing something similar ).

Guess I should just link to it now, download me here.

As always abuse the comments. Just to sound a grumpy shit for one last time this post, this isn't some big open source project that I plan to expand and maintain, if you find bugs or even better come up with fixes, then yeah they'll be added with a great big bag of thanks from me, but this isn't my life's work. Feature requests are going to be ignored to be honest, it is what it is.

Squize.

INEEDUMORETHANUNEEDME

Hey kids, it's time for another fun round of "Name that game ( 'Cause I can't be bothered )". This time the stolen gameplay is based on the C64 game, "Bounder".

Here's the title screen,

bouncingGame_title.jpg

As you can see I've made no effort at all to name it, internally in the code it's just known as "G2". Play3D as an option you say ? Yep if you've got some red / blue glasses you can give yourself a bastard headache playing it in 3D for no real benefit.

Need to see an in-game shot for more inspiration ? Go on then,

bouncingGame_inGame.jpg

For those of you not old enough to remember Bounder, the game mechanic is that the bomb there bounces up and down, in and out of the screen ( Hence my idea to give it a bit of 3D, great idea and works kinda well, it's just that it's created so much more work for me, but it'll be worth it for the 6 people who'll play it with glasses on ) and you control it's movement to ensure it lands on a platform.
Hmmm this is harder to explain than I thought. Imagine looking down on a tennis ball bouncing, and you've got to move it from one room in your house to another only bouncing it on rugs rather than the carpet.

So we've got bombs, we've got bouncing, we've got platforms. The bombs not got a name so feel free to go down the lines of naming him for the title, eg "Billy Bouncing Bombs Big BlowOut" ( Which I instantly quite like, why didn't I think of that before writing this post ? ).
I was really blown away by the response to the last help me with a name post, if we only get a fraction of that creativity this time then I'll be more than happy.

Over to you my beauties, and thanks in advance.

Squize.

PS. It goes without saying you'll get an in-game credit, so I won't bother.

Embedding a text file

I've started work on game 2 for game'88, and it's going to be a tile based scroller. Unbelievably after doing literally dozens of tile based games in as2, I've still not done one in as3.

First up I fired up Mappy, did some an ultra simple test map and then exported it using the lua based exporter I wrote way back. It's a nice simple format, eg

smf!|10|200|0,0|0,0|0,0|0,0|

We've got a bit of a header there, "Stimunation Map Format", now that's going back some years, the width and height of the map ( 10 tiles wide, 200 high ), and then a combination of the tile image|tile attribute.

In the good old days we'd just #include that and hit it up that way, but as3 doesn't give us include, so it's a swanky new byteArray approach for us.

As always reading code on a blog is just boring, so open up another tab and get some filth in there to flick over to when your eyes start to glaze, or maybe a youTube video of a cute cat.

package Classes.Game2.Scroller {
    import flash.utils.ByteArray;
    
    public class G2_LevelData {

//---------------------------------------------------------------------------------------
// Assets
//---------------------------------------------------------------------------------------
        [Embed("/_assets/G2_level1.txt",mimeType="application/octet-stream")]
        private var level1Data:Class;
        
//---------------------------------------------------------------------------------------
// Properties
//---------------------------------------------------------------------------------------
        public var map1:Array;

        private var mapData:ByteArray;
                
//---------------------------------------------------------------------------------------
// Constructor
//---------------------------------------------------------------------------------------
        public function G2_LevelData() {
            mapData=new level1Data();
            var mapDataArray:Array=convertToArray(mapData);
        }

//---------------------------------------------------------------------------------------
// Private
//---------------------------------------------------------------------------------------
        private function convertToArray(source:ByteArray):Array{
            var tempString:String=source.toString();
            var tempArray:Array=tempString.split("|");
            return tempArray;        
        }
        
//---------------------------------------------------------------------------------------
    }
}

And that's it, almost too simple to share, but if it saves you a bit of hunting further down the line then it's not a bad thing.

Squize.

Inspiration has left the building

I'm currently working on Game'88, a collection of mini-games in various retro styles, and also by coincidence my 88th game.

The first game is all but done, it's a keepy upy game using a zombie head in the style of an old green screen game system, naturally.

zombieHeaders.png

It's called "Zombie Headers", the only name I could come up with. It's a really lame name, hence this post. We're offering a once in a lifetime prize* to anyone who can come up with a better name, so hit that comment button and save me having to think for myself.

Squize.

PS. Please at least one person post, even if it's shit, as there's nothing worse than a blog doing something like this and no one replying. It's like being alone at your own birthday party.

*Your name in the credits or something, I haven't really put any thought into that either. Let's be honest it's not a real prize as such, that's just a bribe.

Twisted metal

Just a couple of grabs from Destroy More Cars today, the crashes look good enough to share.

dmc_crash1.jpg

dmc_crash2.jpg

I'm really hoping this is going to be code complete by the end of this week, it's starting to outstay it's welcome now.

Squize.