Tonight we start the new game...

Published November 27, 2006
Advertisement
[EDIT] Forgot to say, String Theory got featured in PC Gamer, one of the UK's biggest game magazines, this month. Didn't someone round here write that? Much kudos, whoever you are [smile].

I'm going to make a start on the new game tonight. I'm working on a sprite editor at the moment since I want far more complicated sprites in this game than Orc and find it really hard to do animations with Paint Shop, but I'll be writing tools till next Christmas if I don't crack on.

I just want to get the basic physics for a Mario-ish platformer working with just any old blocks for now.

I'm slightly concerned by the implications for frame-rate independant movement and jumping. In Orc, everything was velocity based, so velocity increased over time up to a ceiling, as well as actual movement, plus it really didn't matter if an object moved very slightly slower or faster dependant on the frame rate as long as it wasn't noticable to the player.

However, with something like Mario jumping, all the upward velocity has to be applied to the character in one instant as far as I can see, regardless of the frame rate. It is very important though for a platformer that the sprite jumps exactly the same height and across the same horizontal distance regardless of frame rate, otherwise you could make certain jumps at one frame rate but not at another.

It may be that the simple velocity model is not sufficient here and this is my first job - to find out exactly how this is going to have to be handled. At least when I have that working I'll have the bare bones of the game and should be able to start making some progress.

I've been playing some Abe's Exodus on the Playstation recently and was quite excited to realise that I could now implement the hiding-in-shadows effect using the diffuse colours in D3D so expect a kind of stealth-Mario thing to happen. I'd love to combine the high-speed Mario/Sonic style 2D scroller with the flexiblity and puzzle-based elements of the Oddworld games.

Obviously complex animations are a problem for a one-man hobbyist developer which is why I'm so taken with the "free" effects like using the diffuse colour thing to do shadow effects. The D3D wrapper will probably need a rewrite so I'm going to create a new one based on the one I used for Orc so I can mess about with it without leaving Orc in an uncompilable state.

There is no escaping the fact that I'm going to have to do quite a lot of animations for the game I have in mind though so I'd expect progress on this one to be a lot slower than Orc. I'd also like to have a much longer game finished before it gets released this time.

At least I have a level editor ready this time though.
Next Entry platformer
0 likes 9 comments

Comments

takingsometime
For inspiration for the sprite editor, maybe ToonBoom Studio can give you some cool ideas. I've found its method of 'onion skinning' for animation to be a god-send when trying to animate my really crude characters.
November 27, 2006 11:54 AM
jjd
You should definitely be able to continue using your velocity-based approach to create a 2D scroller; to do otherwise would be debauch. There are a variety of ways to achieve what you're after. Two that stand out for your situation are (1) numerical integration and (2) using a closed-form solution (for simple forces, which you'll probably use in this case). Basically, you can get a long way down the track using a velocity-based approach. In a simple game, it is not hard to make your forces independent of frame-rate.

Give me a yell if you have any questions about this stuff.

[edit] Just noticed your post on the Game Programming forum. Looks like you managed to sort it out :-)
November 27, 2006 01:09 PM
Aardvajk
Thanks for the posts.

I reckon from discussions on the forum that locking the physics to a fixed time rate seems to be the way forward. I've got this in my main loop now:


void CEngine::Cycle()
{
	float Time=Timer.Get();

	if(Lock) Tim+=Time;

	Elapsed+=Time;
	if(Elapsed>=0.025)
		{
		UpdatePhysics(0.025);
		Elapsed=0;
		}

	if(Y<Max) Max=Y;

	Dev.Clear(D3DCOLOR_XRGB(0,0,255));

	Dev.BeginScene();

	Qu.Begin();
	Qu.Add(380,Y,40,40,D3DFLOATRECT(),D3DCOLOR_ARGB(255,255,0,0));
	Qu.End();
	
	Dev.Draw(Qu);
	
	Dev.EndScene();
	Dev.Present();

	Sleep(40);
}



It means that the game does run at very slightly different speeds on different frame rates, but not enough to be really noticable, especially since you can't directly compare (well, unless you are going to set up two computers side by side and plug one keyboard into both with a splitter, in which case you are more than welcome to notice differences [smile]).

It would appear though that the maximum height of my jump in the above test is absolutley identical to the fifth decimal place of a float regardless of the value I put in the Sleep() statement.

Glad that's sorted. I did try and get my head round RK4 interpolation (or whatever its called) but my brain fell out of my ears and I had to pick it up with a dustpan and brush.

Sod it. Solution above seems good enough to me.
November 27, 2006 02:18 PM
jjd
Looks fine to me :-) Here is an article on game loops if your interested (see the section "applying the throttle" for what you're interested in). And, yeah, RK4 is a tricky beast, and probably not so good for games.
November 27, 2006 02:26 PM
HopeDagger
Great! I'm really excited (by your excitement!) to see this game turn out. Your motivation looks high, and your aim is at a very reasonable goal (that is loaded with potential). I would absolutely be thrilled if you managed to fit in Abe's Odessy(/Exodus)-like stealth and puzzle elements into the game. :)
November 27, 2006 02:26 PM
Aardvajk
Cheers Hopedagger.

Hey - it was you that pointed me at String Theory via your journal, wasn't it? I'm sure you said one of the GameDev regulars wrote that. Am I remembering correctly?

I was just wondering if, whoever they are, they knew they'd got a feature in one of the UK's biggest magazines.

@jjd - thanks for the link and info. I'd seen that article before and it is a good one. I'm actually looking now at just throttling the physics and keep the rendering going as fast as possible, although I guess that is a bit silly really come to think of it, since the visual result will be the same [doh]. Perhaps I'll just throttle the whole thing like the article suggests.

Actually, it won't be the same, will it? Surely if I throttle the whole thing and the rate slips behind the vsync, the frame rate will halve, whereas if I use the approach I just posted, the rate will be less affected? Brain hurts. Someone explain this to me properly...
November 27, 2006 02:41 PM
Mushu
Toxic Hippo, AKA dcower wrote String Theory ;)
November 27, 2006 02:44 PM
Aardvajk
Quote:Original post by Mushu
Toxic Hippo, AKA dcower wrote String Theory ;)


Groovy. Does he/she know about the PC Gamer article? I dunno how well known that magazine is outside UK.

[EDIT] - Ah. The person in question appears to be banned. [smile]
November 27, 2006 02:46 PM
jjd
Quote:Original post by EasilyConfused
Actually, it won't be the same, will it? Surely if I throttle the whole thing and the rate slips behind the vsync, the frame rate will halve, whereas if I use the approach I just posted, the rate will be less affected? Brain hurts. Someone explain this to me properly...


I remember reading a game loop that had the game update and the rendering decoupled, so there is merit in the idea. But I wonder if you should worry about it at the moment. I'd probably start simple and throttle the whole kit-and-kaboodle.
November 27, 2006 03:08 PM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Profile
Author
Advertisement
Advertisement