Gaming Your Way

May contain nuts.

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.


Comments (5) -

  • Chris Cutler

    1/31/2009 11:14:19 PM |

    Hey Squize,
    Try removing the event.updateAfterEvent()  from the main loop and see if that helps on lower end machines (it should). I find that I have to remove it more often than not in my more demanding games. (I didnt include it in my initial port of the code, but Jeff discovered that it can definitely help in certain situations)


  • 8bitjeff

    1/31/2009 11:20:51 PM |

    I really like the idea of a CPU render test. I think you MAYBE could start plotting (blitting) objects (or add Sprites) and check the frame rate until it goes below your minimum. Then you adjust the game play accordingly. Maybe with fewer enemies it runs faster or the enemy shoot more or take more hits, or...

    I don't know, but I'm sure you will come up with an elegant solution, and you will let us know what it is.

    At least the draw doesn't hurt the Rover this week...

  • 8bitjeff

    1/31/2009 11:21:40 PM |

    I meant Rover(s), not Rover, but what the hell...back to Oblivion on the 360...

  • Squize

    2/3/2009 12:15:19 AM |

    Cheers for the quick feedback Chris ( And sorry for my slow one ).

    I'm on a million different things right now, but I had a quick play after removing the updateAfterEvent call and obviously it wasn't as smooth.
    I'm going to have to post a version without that and get some of the people who have been having issues to have another play, if it fixes it then I guess I'll have to live without it being as smooth ( It's not as if working with Flash having to compromise is a shock to the system ;) )

    Thanks for the ideas Jeff, I'm still mulling over the best way to go about it. Oblivion ? Too rpgy for me, I need the arcadeness of Fable 2 ( Arcadeness and a dog that is ), and yeah the boys may not be winning but it's better than it was under Ince.

  • jason

    2/6/2009 4:41:16 AM |

    Some kind of realtime LOD might work.

    You'd could monitor the FPS each second, and if it's below (or above) a threshold, turn on/off features accordingly. I think it could work well, and it removes the need for the user to try to make that decision (which, probably, they would just quit instead of looking for a solution buried in the options menu).

    A static test at the start is limited because it can't account for the update speed across the life of the session, so if performance varies it wouldn't handle that gracefully.

    Good luck, and congrats on the Prodigy game release.

Comments are closed