In another thread someone mentions that the game runs at 30fps? Is that correct? In some of the graphics intensive games, frame rate achieved is dependent on the hardware, so I'm wondering how CW does this?
30fps sounds like a bit much for such a simple game. No offense intended, but I'm sure you understand what I mean.
Im basing 30fps on what i read in the flash to exe post virgil put on the blog, he said one of them only got him 21-22fps while he aimed for 30fps.
30 fps also seems a typical for most games,
See here (http://knucklecracker.com/forums/index.php?topic=15.msg3995#msg3995).
ChopRaider is set to run at 24 fps, CW1 at 36 fps, and CW2 at 30 fps.
Why these numbers?
Well, back in the flash 9 days "multiples of 12" were the sweet spots for getting the most consistent frame rate across different browsers. So 24 is a good frame rate for a game set to run in browsers that only have flash 9. This is also the default frame rate for flex based applications.
But, 24 is a little on the "choppy" side so 36 was what I used in CW1. I planned on releasing a flash version of the game and I still wanted to support flash 9.
Now everybody has flash 10.x... and the multiple of 12 rule no longer applies. If you set a trivial flash app to 30 fps, you will actually get 30 fps in both AIR and the browsers. So CW2 is set to 30 fps. This offers a fluid frame rate while reducing the computational load a bit (which I immediately put back to use for the games algorithms).
Ah :P i had that multiples of 12 rule in my backhead, but assumed you would use 30fps as its the universal minimum framerate.
i stand corrected Karsten :P
Quote from: virgilw on September 12, 2010, 12:21:44 PM
CW2 is set to 30 fps. This offers a fluid frame rate while reducing the computational load a bit (which I immediately put back to use for the games algorithms).
Quote from: virgilw on January 25, 2010, 05:53:14 PM
CW is a frame-locked game. This is on purpose... This means that the game loop does things like calculate creeper expansion, packet routing, and rendering. Now not everything happens on every loop of the game. But as the game slows down, _everything_ slows down. This is a wise choice for a game like CW where performance can vary but you want fair treatment across different runs of the game. Other game engine choices might be to measure the time delta between each game loop and adjust game physics based on that delta T. This makes things run at the same wall time across fast and slow computers. So for CW every game loop updates a counter. Packets get produced after so many loops have passed (that's a simplification, but basically what goes on).
Quote from: virgilw on February 15, 2010, 03:10:01 PM
CW is a frame-locked game. THis means that everything slows down if the computer it is running on can't keep up. So everything just gets slower (the creeper moves slower, guns move slower, packets move slower, even the clock ticks slower). It is done this way to keep scoring 'fair' across different platforms.
I've always wondered how this frame locking exactly works. A few questions:
1. Does the game measure whether the intended amount of FPS can be displayed with the current hardware?
2. Do you assign a duration of 27.8 ms (1/36 sec) to each frame to eliminate the use of the real time?
3. You say not everything gets calculated each loop of the game (= frame?), so during one frame more calculations may be done than during another frame. How do you compensate for that?
In flash, you set a FPS that you want rendering to occur at. You can also implement an "enterFrame" listener like this:
addEventListener(Event.ENTER_FRAME, onEnterFrame);
This means that the function "onEnterFrame" will get called for each 'frame' of the flash player. Ideally, if you set the FPS to 30 this function will get called 30 times per second. But of course it isn't that simple.
Inside that 'onEnterFrame' function you can do anything you want (the entire game logic for instance). If you do a whole bunch then you will take more than 1/30th of a second. The result is that the next call to onEnterFrame will come as quickly as possible, it just won't come 1/30th of a second later.... so your effective frame rate will drop.
Now this general way of doing things isn't really that tied to flash. If you were doing an XNA game, you'd be working off a 60fps system (probably). In any of these cases there at two general types of games you can write; frame locked and time locked.
In a frame locked game, you do your logic per frame and assume a given frame rate. So if you want a ball to take 10 seconds to move across the screen you assume 30fps and move the ball accordingly per frame. In this kind of game, the ball will take longer than 10 seconds if the machine running the game can't maintain 30fps. A time locked game, won't do this. It instead will move the ball differing amounts depending on how much actual time has elapsed. So if the game runs on a slow machine the ball will still move across the screen in 10 real seconds... it may just take a few bigger jumps to do it.
Which way you write a game depends on the goal of the game (and a little about the platform). For CW, the game is frame locked. This means that when the game runs on a really slow machine, everything slows down. This is desirable for a game like CW. It might not be desirable for a first person shooter.... and would certainly not be desirable for some multi player games.
Anyway, I digress...
Since CW is frame locked, I do most of the game logic per frame.... just not every frame. For instance, full creeper updates come only every 8 frames. Some units check things only every 36 frames. I literally have a frame counter and may do something like:
if (frameCount % 8 == 0) {
updateCreeper();
}
Now in reality things are a even a bit more complex than this (in some cases). Instead of one big creeper update once every 8 frames, I actually do 1/8th of the creeper update each frame. In CW2, I split the load in half so that half of the creeper array gets updated every other frame.
Even with all of this, there will sometimes be frames that take too long to do their work. When this happens there is a "jerk" in the game. If it's just a little bit and happens every so often then no big deal. A little hiccup that happens at a regular interval is more noticeable than one that happens at irregular intervals. So, I sometimes mod the frameCount by a prime number (and use different prime numbers for different tasks) to help mix things up.
Lastly, flash takes a monster load of time to render the screen as well. This can account for 75% of the total cpu load. It all high depends on the number of transparent bitmaps, blah, blah, blah. It also depends on if the user has scaled the game...
And it depends on how many cores a person has in their machine. With more than one core the flash player has an opportunity to move the rendering to a different core(s) and free up event frame processing. I believe this is why I see such a huge difference between single and dual core machines for flash performance. (And why I'm curious what people have: http://knucklecracker.com/forums/index.php?topic=4696.0 (http://knucklecracker.com/forums/index.php?topic=4696.0) )
This may explain little "freezes" I have noticed on the game on my laptop.
Thanks a lot! This really shows how much more interesting game development is compared to the development of many other systems, as you have to deal with so many more aspects.
So basically you increase the number of seconds by one to obtain the elapsed time when 36 frames have been processed? Is this also the reason you calculate the score from an integer time value and can't take the (non-existing) fractional part into account?
When a jerk/hiccup occurs, does the rendering of this frame gets skipped while the logic behind it is still executed?
To calculate a framerate I see how long it takes for 36 frames to come. Ideally, this would be 1 sec. So when I'm dev'ing a game I'll have that little number on the screen all of the time. In fact right this second I'm looking over on a second monitor where I have an AIR version of CW2 running. It shows a little "30" right now (30 fps). I'm running a test on a machine where I've turned off the second core and am toggling the intel speedstep in the bios (yes, it makes a difference to performance). Basically, I take a moment every so often the check the performance on a slow machine. Then I'll spend a few days optimizing algorithms (or removing /altering features).
Score wise, there is no frame reason for the way it is on CW1. I basically just focused on "score" not time. I had web site score integration in mind. Time in CW2 (for scoring purposes) is calculated by the number of elapsed frames since mission start. So it's a pretty accurate thing. Scores reduce this accuracy by mashing a very accurate frame count into an exponentially decaying range of 10000 to 0.
As for hiccups and frame rendering. The answer is sometimes a yes. Flash won't always redraw the screen and can skip some renders. I don't really have total control over this in flash (unlike some other environments).
Let me ask you a different question - suppose you have a really simple game, but you set the frame rate very low. So all processing happens in only a fraction of the time allocated to that frame. Does the game show some signs of "jerkiness" as it moves objects around?
The reason I asked this question about the completion time was because the scores always jump by 3 points (short game) or 2 points (medium game). Fractions of the completion time seem not to be taken into account (while this is possible with a framecounter
not modulo 36). I notice this often lately when I play a quick Chronom map (< 2 minutes) and the time counter increases by one second just at the moment the rift opens (costing me 3 valuable points).
Regarding the skipped frames: so the logic is always executed and the OnEnterFrame is always called, even when the frame rendering is skipped? I think I don't understand this part completely:
Quote from: virgilw on September 12, 2010, 02:23:24 PM
A little hiccup that happens at a regular interval is more noticeable than one that happens at irregular intervals. So, I sometimes mod the frameCount by a prime number (and use different prime numbers for different tasks) to help mix things up.
Quote from: Karsten75 on September 12, 2010, 03:37:43 PM
Let me ask you a different question - suppose you have a really simple game, but you set the frame rate very low. So all processing happens in only a fraction of the time allocated to that frame. Does the game show some signs of "jerkiness" as it moves objects around?
If you set the frame rate to 1 fps, your enterFrame method will get called pretty much once per second. You game logic will move you ball say 2 pixels. The system will twiddle it's thumbs, then call your enterFrame method again after the next second is up. Then you will move your ball again.
In this case the ball isn't jerky, it's just moving really slow. To compensate for such a slow moving ball, you might decide to move the ball 20 pixels per update. Now the ball makes it across the screen quicker, but it jumps 20 pixels at a time doing it. In this scenario you might characterize the movement as "jerky", but it will always be pretty uniform at it.
Quote from: UpperKEES on September 12, 2010, 03:38:31 PM
The reason I asked this question about the completion time was because the scores always jump by 3 points (short game) or 2 points (medium game). Fractions of the completion time seem not to be taken into account (while this is possible with a framecounter not modulo 36). I notice this often lately when I play a quick Chronom map (< 2 minutes) and the time counter increases by one second just at the moment the rift opens (costing me 3 valuable points).
Regarding the skipped frames: so the logic is always executed and the OnEnterFrame is always called, even when the frame rendering is skipped? I think I don't understand this part completely:
Yes, the score is calculated off of "seconds" not frames. So precision is lost there. To get those extra points you have to shave off enough to keep the time from advancing once second more.
Rendering the display can be skipped from time to time and this is independent of when your enterFrame method is called. For the most part, the rendering happens... but it can get skipped. Think of it like another processor/thread. The rendering isn't synchronously tied to the execution of you enterFrame calls. So rendering could take a 100ms vacation while your enterFrame methods continued to get called.
Next question: Can I find the frame rate delivered on my system somewhere?
I've seen that when the game is paused and spores are in flight, they seem to jump a few pixels every second, is this a result of low framerates, or just your algorithim
Quote from: virgilw on September 12, 2010, 03:20:12 PM
Score wise, there is no frame reason for the way it is on CW1. I basically just focused on "score" not time. I had web site score integration in mind. Time in CW2 (for scoring purposes) is calculated by the number of elapsed frames since mission start. So it's a pretty accurate thing. Scores reduce this accuracy by mashing a very accurate frame count into an exponentially decaying range of 10000 to 0.
Quote from: virgilw on September 12, 2010, 04:04:46 PM
Yes, the score is calculated off of "seconds" not frames. So precision is lost there. To get those extra points you have to shave off enough to keep the time from advancing once second more.
I'm not sure if I understand the exact relationship between above two quotes. Is time in CW1 also calculated by the number of elapsed frames since mission start? If so, i.e. 378 frames would be equal to 10.5 seconds, which could be converted into a precise score, right? (And yeah, I know it's too late for that now. I noticed it before, but I never said anything. ;)) Thanks again for all your answers!
Quote from: Karsten75 on September 12, 2010, 04:47:19 PM
Next question: Can I find the frame rate delivered on my system somewhere?
I wondered the same thing. I always had it on display when tweaking my Half Life setup years ago.
Quote from: thepenguin on September 12, 2010, 05:05:39 PM
I've seen that when the game is paused and spores are in flight, they seem to jump a few pixels every second, is this a result of low framerates, or just your algorithim
This is just animation. They spin a little and because this animation isn't fluent (the end doesn't come back to the starting point exactly) the spore seems to 'jump' a little, but it doesn't actually move. Let the game run (in paused mode) for a while and you'll see they're still at the same spot.
Yes, the score could be based on frame precision timing, it just isn't. It's based off of the number of seconds that have elapsed. So I take the frames counted, turn this into seconds and then use that to show the elapsed time and to calculate score.
Tap the "=" key during a mission then look in the lower hand corner and you will see the frame rate. Keep in mind you may see fluctuations up and down... this is normal. You may also see a number less than 36, and that is perfectly fine too. The average person will probably see around 32-33 fps. I've played the game down below 30 before. Also note that the frame rate will appear to double when you activate double speed.
Quote from: virgilw on September 12, 2010, 08:08:56 PM
Yes, the score could be based on frame precision timing, it just isn't. It's based off of the number of seconds that have elapsed. So I take the frames counted, turn this into seconds and then use that to show the elapsed time and to calculate score.
Tap the "=" key during a mission then look in the lower hand corner and you will see the frame rate. Keep in mind you may see fluctuations up and down... this is normal. You may also see a number less than 36, and that is perfectly fine too. The average person will probably see around 32-33 fps. I've played the game down below 30 before. Also note that the frame rate will appear to double when you activate double speed.
Easter Egg! Nice one, Oh Sneaky One! :P
Quote from: virgilw on September 12, 2010, 08:08:56 PM
Tap the "=" key during a mission then look in the lower hand corner and you will see the frame rate.
Nice indeed! And very useful now I'm testing something:
Quote from: virgilw on September 12, 2010, 02:23:24 PM
Some units check things only every 36 frames.
When I just
filled my screen with collectors, reactors and relays only (http://knucklecracker.com/forums/index.php?topic=4666.msg24228#msg24228), CW slowed down a lot: 7.5 FPS on my rather fast computer (full screen or windowed very tiny actually didn't matter!). You would expect these rather static units not to affect the FPS too much (I guess CW only needs to check if they are still there and connected to the network, so probably a counter is updated per unit type. Same for speed and storage, so I always wondered why a map with 40 pre-built speed nodes suffers from so much lag. Aren't these the units that you check every 36 frames? Just asking because you might be able to improve this for CW2....
Units check for connectivity back to OC about once a second. But, as you add more of them you create a larger graph of nodes. This makes the "search" for connectivity take longer while at the same time you are increasing the number of units.
I've made great progress increasing performance for cw2 in the A* algorithm and supporting data structures. I pretty much has to if I wanted to pull of the game I've created in CW2. Every terrain cell is a node in a graph, and the game space is 32 x 90 (currently). Packets are also more plentiful in CW2 so they are path finding their way through this array all of the time.
That said, CW1 isn't bad... it gets away with a lot considering only about 25% of the total processing time is devoted to game computation... of that, more than half is devoted the the Creeper CA simulation. What's left does path finding and everything else.
75% of the cpu load is from the flash player drawing everything.... and that's another reason why when you add more units things get a little slower.
Don't get too caught up with the fps, though. You'll start experimenting with all kinds of variables (screen size, resolution, color depth, cpu settings, flash versions, air versions, game settings, mission content.....) It's a black hole... :)
Quote from: virgilw on September 12, 2010, 11:23:24 PM
75% of the cpu load is from the flash player drawing everything.... and that's another reason why when you add more units things get a little slower.
I'm surprised by that because none of these units have animated graphics, so there's no need to redraw parts of the screen.
Quote from: virgilw on September 12, 2010, 11:23:24 PM
Don't get too caught up with the fps, though. You'll start experimenting with all kinds of variables (screen size, resolution, color depth, cpu settings, flash versions, air versions, game settings, mission content.....) It's a black hole... :)
No worries, I won't. I'm done with it now, so back to playing! :)
Next question then:
When you animate a blaster in CW, its turret moves in the direction it fires. Do you simply have a library ful lof blasters pointing in the various directions and you replace the graphic, or how is that done?
Karsten: im pretty sure its a single frame he rotates on a central pivor in the direction its shooting in
Blasters are made of thee sprites, one for the body, one for the gun, and one for the beam. The body pretty much forms the base, the gun in on top of the body and gets redrawn based on the direction of fire. The beam sprite sits between the two. It is transparent most of the time. When the blaster fires, I draw the line. I also add a glow filter to the beam sprite to make the line appear to have soft edges.
The game as a whole is made up of several different 'layers'. There is a terrain sprite that holds the background bitmap. There is a sprite above that which holds the creeper bitmap. There are several sprite layers for the units (when they are on the ground, when they are moving). There's a sprite for the mist... then a couple more sprites for things like dialogs and popups.
Reading all of this I think you're developing damn fast! :o
I've seen people on A.G take years to develop a game not even half as long as CW1 and nowhere as good.
I say, Virgil is the best developer ever. What was it? About a month or two ago and there were no screen shots, and now, it looks close to being done.
Quote from: virgilw on September 12, 2010, 02:23:24 PM
Since CW is frame locked, I do most of the game logic per frame.... just not every frame. For instance, full creeper updates come only every 8 frames. Some units check things only every 36 frames. I literally have a frame counter and may do something like:
if (frameCount % 8 == 0) {
updateCreeper();
}
[...]
I sometimes mod the frameCount by a prime number (and use different prime numbers for different tasks) to help mix things up.
After trying to determine a few of these prime numbers I found:
- blasters fire every 7 frames (pretty sure about this one)
- mortars fire every 103 frames (could also be 101 or 107)
Is that correct?
How do you solve the +15% firing rate upgrade? Can they still be prime numbers?
Humans can only see 23.7 fps. The more FPS, the higher the quality.
Lies kamron, there isent a certain FPS people can see...
The human's eyes only processes a max of like 23.7fps-ish. That's why movies are 23FPS. However, Ultra-High Def is like 2000FPS, which is massively high quality :P
As said again, i can experience pure 30fps laaging, and i can see the flicker of a flourescent tube.. which is around 40-50.
Ultra high def is not 2000fps, as that would be a waste, its just higher bitrate :P
Quote from: UpperKEES on October 20, 2010, 04:27:22 PM
After trying to determine a few of these prime numbers I found:
- blasters fire every 7 frames (pretty sure about this one)
- mortars fire every 103 frames (could also be 101 or 107)
Is that correct?
How do you solve the +15% firing rate upgrade? Can they still be prime numbers?
Lets see....
Unless I'm reading my code incorrectly (wouldn't be the first time) Blasters look like they might indeed fire every 7 frames. The 15% upgrade isn't really exactly 15%.... It actually just makes a blaster fire every 6 frames rather than 7. Mortars look like they might be 105 (not prime).
Great, thanks. :)
Now we can use this for the exact firing rate data, see here (http://knucklecracker.com/forums/index.php?topic=246.msg27242#msg27242).