Scrolling Game Development Kit Forum

There's only one day left in the drawing.  I won't be hard with the cutoff, If they keep coming in past Friday (pacific time) I will go ahead and wait until the last minute.  So if you have any finished game at all, please submit the screen shot in the post comments.  Thank you.

Well I don't get in here that much.  I was going to do my game in SGDK, but a lot of things have happened since I was going to start doing that.  I may not use it at all in the future, but I would like to keep tabs on what's going on in here.  So hopefully you won't delete my account :-)

I'd say try to find the benefits.  Perfect collision detection, and a game that runs the same on almost every system.  (In other words you don't get the slow down from too many sprites on screen in some frames, and in others were it speeds back up.  Instead it gets jerky but every position is updated to the right position based on how much time it takes).

Most all the games you play nowadays use some form of time based movement.  (In some 3d cases there's an even different technology called rendertweening for 3d, essentially it uses the time and then generates the inbetween poses so you're assured of the smoothest movement possible on your system, but that is way more advanced)

In any case, i'm not going to change your mind.  In fact I found out that anything you suggest to anyone is just not going to take.  Because unless it's their idea, they don't really care much what you think.  Even in cases when someone asks you for your opinion they've already made up their mind.  They just want some validation even if you choose the opposite idea from theirs.

I personally go by the 2-3 rule, if 2 or 3 or more people suggest something, then I start listening, otherwise I don't worry about it.  And we're only 2 people... but I wasn't even trying to convince you to do it, i'm just saying that the problems you're naming are mostly an excuse for the fact you don't want to implement it.  And that's fine by me.  No one else has made a nice system like you have here, and until there's a better system i'm sticking to it.

Keith

I'll attempt to shed some light on this subject.  Essentially time based movement is supposed to keep movement consistant reguardless of actual frame rate.  It is essentially based on elapsed time between calls, so that if you have a slow computer the object will appear to move at aproximately the same rate as it does on a fast computer.  Let's say you need to move a spaceship from star A to star B, and let's say they're aproximately 50 pixels away from each other.  On a slower computer (hypothetical) the spaceship might move 5 pixels per second, on a faster computer it may move 10 pixels per second.  At 5 pixels per second 50 pixels would take 10 seconds, at 10 pixels per second 50 pixels would take 5 seconds.  But here's the problem, the speed isn't the same, the slow computer takes 10 seconds whereas the faster one takes only 5.  So how do you account for that?  Time based movement.  You call a timing function (usually with millisecond resolution), Save the start time and the end time, and subtract the start time from the end time, to get the actual amount of time elapsed.  You then use it to input into your movement.  Essentially you adjust the pixels the ship moves per step based on how long it's taken since the last call to get_time.  What it results in, is that now, the slow computer will move the ship 10 pixels per second, resulting in the 5 second move, which is exactly what the faster computer does.  (Ie the slower ship moves farther in the step than the faster one does).  The only major problem with this is that with a really slow computer the frame-rate gets a little jerky, because it apears to jump farther to stay in sync with what a faster computer would do.

Frame based movement of course relies on how fast the computer can update frames.  This is why you have some older games that move unplayably fast on more modern computers, and at a correct speed on slower computers.  Newer games that use this method essentially rely on the speed the video can update, which means a slow computer on a modern game appears to make the game move "in slow motion" because it can't update fast enough.

So really it's a tradeoff.  If you can guarantee at least x amount of frames per second on slower computers, then it shouldn't be a problem, because usually you frame-limit games so they don't go too fast on new computers.  (Say 30-60 fps depending on what you're doing).  Time based movement on the other hand requires that the computer be fast enough for the game to feel smooth.

I hope this clears up what you're trying to talk about.

Keith

Oh comon, they're not that far apart.  A M.U.D. is essentially a multiplayer text rpg.  Text adventures are sort of "dumbed down" MUD's that is, not only single player, but usually there are no skill levels or points.  An adventure is more pure as in it's an interactive narrative, where each puzzle should add to the main overall story.  I should say adventures are dumbed down rpg's.  You play a role in an adventure but usually it's of a single purpose, and it's to reveal more of the narrative.  Whereas rpg's may have many stories, and side quests who's only goal is to increase your skill set.  The current term for text adventures, however, is interactive fiction.

I'm developing a graphic adventure, in the vein of King's Quest or Monkey Island.

(btw graphic adventures rely on graphics but are still adventure because they're interactive stories).

Keith

Curious can you guys make a game with it yet, or it just a set of related and not-completely-functional tools?

Keith

One thing I noticed when going through the tutorial, where you create a script to use spacebar to drop bombs.  Doesn't seem quite so difficult now.  Although it would still take me a while to get the hang of.  By the way how does the script wizard make scripting easier?

Keith