Gaming Your Way

May contain nuts.

The first of many stats

Just a quick X++ stat to keep things ticking over on that front.

Since it's been on FGL the total distance flown has been 643 kilometres, which is the equivalent of going from Paris to Milan.

Boring, but true.

Squize.

PS. And 29274 shots have been fired in anger. That's a lot of anger.

And now we wait

Just a minor update about X++

The final version has been posted to FGL, so if you're a registered developer there with a 1+ rating in each of those different categories that I can't remember ( Market place and the like ) feel free to check it out ( It should be verified in a couple of days ).

We were looking to Kong for a sponsorship but we've not heard anything back, so off to FGL she goes.

It's funny how the last 0.5% of it has dragged on quite so long, but we were both tied up with proper work. I think it's worth the delay though, I'm really proud of it.

Anyway the next post about it should be a link to it's final home, and then we can move onto the next one.

Squize.

Error #1152, you sly fox you

Just a quick one in case you ever get a,

 

error 1152: a conflict exists with inherited definition


I'd used the instance name "name" on a dynamic text field on the stage, and the Flex compiler just didn't like any of it, to the point of giving me 14 errors for my trouble.

Simple lamer mistake I know, but if you're here after pulling your hair out with that error it may save you some pain.

Hmmm bit of a geeky post, sorry, we'll get back to our usual brand of swearing and talking crap next post.

Squize.


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

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_00.jpg
(CC game, using 40x40 tiles)

 

cc_editor_00.jpg
(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


Quicker than planned

I have that written on the front of my pants.

The penultimate preview of X is online now and panting for you to play it.

New in this are the options screens, which between you and me I'm really not happy about. I backed myself into a corner with using tweens and bitmaps for the majority of the text / buttons, which take ages to actually get into the game.
Once they were in I realised I'd messed up by not giving appropriate feedback on each selection. I should have re-done them, but it would have taken ages and been really boring, so instead I just dropped in a really cheap way to show the feedback.

If there's going to be a part of the game that really bugs me, it's going to be the options. But the rational part of my brain ( As opposed to the part that makes me want to delete the whole game and start again 'cause those options aren't as good as they should be ) is saying that people will only ever got to the options once or twice ever, that the pay off for the look & feel of the game text is greater than losing out on a bit of feedback, and, well, fuck it.

The main thing in terms of feedback about the options is the alternative control method ( Well two actually, but in a lame lazy way ), which to be honest I really struggle to get to grips with. I coded it a couple of days ago and obviously tested it, and after a while it wasn't too bad ( I'm kinda used to EveryDay Shooter on the psp so it's not a million miles away from that ), but since than I've not used it, and having a quick go today showed that I'd fallen out of the habit of playing X that way, and that I really didn't want to get back into it.
Not really giving it the hard sell am I ? Well it's a case of it's there if you want it, although to me the default method is always going to be better.

Squize.

3rd from last

Only two more updates to go after this one, we're nearly there.

It's actually getting tricky now, as it's so close to being a final game, what I can and can't post. I don't want to give the whole thing away, but then I don't want to shut the door too early on you guys who have followed from the start.

In saying that the roadmap is as follows,
* build 19, the latest one, features the sound and music along with a couple of graphical tweaks and fixes.
* build 20, options so the new control modes can be tested.
* build 21, the global stats ( We've got something really sweet in mind that we're both really excited about. Not excited about the code, but the results should be way sexy ).

And then that should be it in terms of public releases. In my head I want the game to be finished next Friday, and then it'll just be a case of seeing what we're going to do with it.

For this build I've put a watermark in there. I was in two minds what to do, but I opted for the less sweary version ( I was going to put a harsh word onto the background, but figured that could just backfire ).
I'm not overly happy about having to do it, or rather feeling like I have to do it, but if it stops the game being spread in a beta version then all well and good.

Nearly there. It's really mad to think that it's just build 19. I've had some half days on it, and big breaks where real work has got in the way, but I've really not cheated ( ie worked on it for extra days but not said. I've had to "join" half days together rather than post builds after only working a couple of hours on it ) and to do a game like this in 19/20 full working days is pretty cool.
It shows what can be achieved if you have a real joy for the project, as opposed to an extended slog, and having pretty much complete creative control over it makes such a difference in terms of dev time.
We're going to have a really in-depth post mortem about this and see how we can transfer these things to client work to improve turn around.

Squize.

Time to leave the nest

Bit of a minor update for X++ in anticipation of the options settings.

So what does build 18 bring to the party ? Well lots of things behind the scenes ( Such as FlashJoystick support, which is so sweet. I swear a little bit of pee shot out the first time an asteroid hit a ship and the joypad rumbled ).

On the surface though it's not a world apart for build 17, not every new build is a huge step forward. The main ( Only ? ) user facing update is the option screen right at the start allowing the user to set the "quality" of their machine.

We've touched on the play back issues on previous posts in this little mini-series and it's now become the time to address them. Basically if you've got a good enough machine you get to play it looking all super sexy. If on the other hand you're stuck with a less than able machine, picking the reduced visual quality option will turn off some of the love and hopefully enable you to actually play it.

What would be really nice would be if any of you guys have had input problems in the past ( Due to the nature of the time based mainloop, if things over-run too badly then Flash can't keep up with I/O requests, such as reading the keyboard ) could give it a go with the reduced quality settings and give us a shout back in the comments about it ( Including your spec ).

I'm also going to post this over at FK.games for the first time in it's own thread, 'cause it really needs testing on a wide range of machines. I can almost picture the next hour being one of writing caveats in that thread...

[ Update, thread is here ]

Squize.

Art / Life / Art

< I wrote this yesterday, but then my net connection poo'd out on me, so it's a little bit past tense >

It's good to be back. My first free day for as long as I can remember ( This year at least ). It feels pretty damn great to be honest.

The main reason I'm free right now is that the Maths based educational project I was working on got cancelled the other day. There's a neat little story about life imitating art, indulge me a minute,

Story

Basically ( If you don't want to leave us ) an asteroid passed pretty damn close to the earth the other day.
The weird thing was that the concept of the game I was working on was to use maths to target a missile at an earth bound asteroid. So when I was in a meeting hearing how it was canned, we were all just a couple of hours away from starting over again and living in caves.

If you wrote it in a story it just wouldn't fly.

There's another game I'm close to based on the whole asteroids as the bad guys theme, and today I had a good crack at it again.

Where the development has been paused for such a long time, I'm not a 100% sure what's new and what's kinda new. So forgive any repetition.

The final flv is on the title screen now, and it looks great. It's really large in terms of filesize and ideally we'll be able to cut that down somehow and retain the quality, but it is a thing of beauty, nGFX has done some great work there ( It's worth watching all the way through, trust me ).
The player movement is less, well, shit, which is always a plus.
Options are in there now. Well, a button saying Options, I really wouldn't press it as you'll probably have to reload the swf ( Although you'll be able to look at our logo rather than a blank screen again, which is another new thing ).
( Adding that options button was a ton of work due to the curved text and the set in stone way I'd set things up. That'll teach me ).
The "play" options are in. They're all unlocked now so you guys can check them out easily, but in real life you won't see those options if none of those features are unlocked ( ie, pressing Play will just make the game play as you'd expect without an extra click ).
Notes are gone. They weren't that great so sod it, they're dead and buried.
There's a lens flair in the game now, although it's pretty subtle and is based on a "Chroma fan" rather than a usual flare.

I'm sure there must be some other bits and bobs, but those are the main things that spring to mind. As always, the latest build is here, thanks for taking the time to give it a bash.

Squize.

Now, where was I ?

Busy busy busy. I'm like a broken record. A busy broken record.

X is on hold for the time being, but it doesn't mean I'm not thinking about it. I think being denied the chance to work on it is making me think about it more, it's like smoking.

Quite a few people are feeding back that the controls stop being responsive on lower end machines. This is due to the main loop it uses. Rather than me go into depth about it, have a check of the great tutorial at the other end of that link.
The only downside to it is that so much of Flash's time is spent actually updating the display that input listeners can be missed, making it feel that the game is being unresponsive ( I'm guessing a listener buffer within the vm is checked every frame, and if the mainloop over-runs due to the sheer amount of data which is being plotted then the listener handler misses it's chance to check the buffer for any triggered events for that frame. That happens 60 times or so and that's two seconds where the game is ignoring you ).

One of the ways I'm looking to fix this is to add an options menu to the game, so people can turn off the eye-candy to suit their set up. The downside to this is, do I default to the game not having everything turned on by so anyone can just come to the game without messing with the options ( As it should be really, a game shouldn't expect or force a user to jump through config hoops before you can play it ), or do I max it out and put some comment in the game telling people that if it's slow to go and mess with the options ?

My current thinking is to run a cpu speed test at the start of a game. So some text explaining what's happening, that the user can go to the options page etc. and a counter runs down whilst it does it's thing ( So we can get an average of say 5 seconds ). This generates it's own problems though ( Doesn't everything ? It'd be so much easier to just be making banner ads for twice as much money ).
The first being, what test do I run exactly ? Should it be a maths formula in a loop and it running some bitmap plotting at the same time ? Is that the best way to judge a machine ? Then, should it be running under a normal enterFrame, or using the timer loop ? Next up, how much can you trust this test ? I don't know where this game will end up, so in theory whilst the test is running something could be happening in the background ( From the user opening a new tab to a nasty chat window to the right of the game doing something ).
Finally where do I get a good spread of test figures from ? I can tell you how quick a quad core pc running FP10 in FireFox 3 with 2 gig of memory will run the test at, but from there we only have so many other test machines. Are there going to be enough of you good readers of this blog willing to give good feedback on such a test ?

Even so, using the figures themselves isn't totally clear cut. To try and explain that, let's say a test on my machine comes back with a value of 10. I know X plays perfectly on my box, nothing I've thrown in there has affected anything at all, so 10 <= is a perfect machine in terms of playback. Great. Say you test it, and you get a rating of 20. What does that mean in real life ? I really doubt it means your machine is twice as slow as mine, 'cause it's just too much of a generalisation. But let's say it means that, what options do I turn off ? Do I kill the particle effects and leave the others running, or can I get away with removing something else.

I'm thinking the way to do it is run the test, output your machines rating, and then turn all the options off. Then when you're playing it, ask you to turn each bit of eye-candy on 1 by 1 until your machines screws up.
Quite a big ask.

I'm really throwing this open to all of you guys, what do you think ( About any of it ? )

Oh the new asteroid images are in the game btw, usual place.

Squize.

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.

nGFX