Superfrog kind-of-fan-clone public tech demo

Whatever you're working on - be it Art, Music, a Fan-Game or a program for use with existing Team17 games - we want to hear about it.

Moderator: Dream17 Staff

Moxy
Newbie
Posts: 36
Joined: Wed Nov 29, 2006 6:15 am
Contact:

Post by Moxy » Thu Jan 18, 2007 2:20 am

haha. sorry for the slipup. MULTIMEDIA FUSION sorry. I'd have thought with a package like that, fixed-physics-tick, and interpolation would happen internally (and as standard), and the developer wouldn't have to worry about that kind of stuff.
K^2 wrote:The only problem with it is that you might end up with collision bugs that are very difficult to intentionally replicate, making debugging a bit trickier.
Is that with interpolation? I haven't encountered any so far. I THINK I may have avoided any collision issues. Collision is still calculated exactly the same as it was before (with a couple of minor fixes since the last release), just now, the player render position is set to "where it should be" between physics steps to avoid jitter effect.

I followed the method described in "the final touch" from this article:
http://www.gaffer.org/game-physics/fix-your-timestep/

K^2
Regular
Posts: 216
Joined: Thu May 26, 2005 4:02 am

Post by K^2 » Thu Jan 18, 2007 7:37 am

Do you actually split simulation steps, (e.g. perform simulation step with a different delta-t) or just adjust <x,y> coordinates of sprites during rendering? In the later case, you don't actually change collision detection. If that's what you have done, disregard what I have said.

It is only with splitting the actual simulation steps that you might end up having issues with debugging. And even then, if your collision detection works right, it wouldn't matter.
None of my projects (Minus One converter, W3D/W4 Map Viewer, and WMapEditor) are endorsed, supported or otherwise affiliated with Dream17. I just find Dream17 forums to be a nice place to share and discuss my work with others.

Moxy
Newbie
Posts: 36
Joined: Wed Nov 29, 2006 6:15 am
Contact:

Post by Moxy » Thu Jan 18, 2007 9:41 am

K^2 wrote: just adjust <x,y> coordinates of sprites during rendering? In the later case, you don't actually change collision detection. If that's what you have done, disregard what I have said.
Yup. That's pretty much exactly what I do, I render the sprite at "the location it should be at" between the previous and the next physics step.

Physics is calculated at 30Hz right now, btw. 30Hz seems to work fine for this type of game. Previously, physics was calculated at whatever your screen refresh was.

K^2
Regular
Posts: 216
Joined: Thu May 26, 2005 4:02 am

Post by K^2 » Fri Jan 19, 2007 5:44 am

It's easy with a platformer. I've been working on a pool game on and off for a while, and I run collision detection physics at over 1kHz, and there are still energy conservation issues. I'm going to have to set up potential energy storage structures to resolve these.
None of my projects (Minus One converter, W3D/W4 Map Viewer, and WMapEditor) are endorsed, supported or otherwise affiliated with Dream17. I just find Dream17 forums to be a nice place to share and discuss my work with others.

User avatar
AndrewTaylor
Regular
Posts: 157
Joined: Tue Mar 01, 2005 11:01 am
Location: Leeds UK
Contact:

Post by AndrewTaylor » Sat Jan 20, 2007 1:06 pm

K^2 wrote:It's easy with a platformer. I've been working on a pool game on and off for a while, and I run collision detection physics at over 1kHz, and there are still energy conservation issues. I'm going to have to set up potential energy storage structures to resolve these.
I'm surprised. I'd have expected you to use one of them non-iterative billiard ball simulations for a pool game. You know, the ones that work out when the next collision would be with equations rather than by incrementing the positions until it happens. Thing. We did them at uni. Can't remember the name.

They didn't have friction, obviously, because they were for atoms, though.

K^2
Regular
Posts: 216
Joined: Thu May 26, 2005 4:02 am

Post by K^2 » Sat Jan 20, 2007 6:59 pm

My simulation accounts for spin of each ball, there are wall collisions, etc. Off the top of my head, I'm not sure how possible it would be to write exact solution for motion of a sphere that slides forwards, spins backwards, until it stops, reverses direction and rolls backwards, or reverses spin direction and rolls forward.* Add to that collisions with multiple bounding surfaces, and it's just not worth it. The main reason, however, is that I was doing it just to get the feel for collision engines, and with a general collision engine for multiple polygon objects, it is best to rely on time steps. I've seen other engines have the same problem as my pool engine, and I think my solution will work for them to.

* Actually, I think you'd have to check time at which rotation would stop, time at which motion would stop, time at which next collision will happen, find the minimum, take simulation to that point, treat the condition that caused the interruption, and then continue to the next such event.
None of my projects (Minus One converter, W3D/W4 Map Viewer, and WMapEditor) are endorsed, supported or otherwise affiliated with Dream17. I just find Dream17 forums to be a nice place to share and discuss my work with others.

Moxy
Newbie
Posts: 36
Joined: Wed Nov 29, 2006 6:15 am
Contact:

New Release of kind-of-fan-clone

Post by Moxy » Mon Jan 22, 2007 2:44 pm

Thanks to everybody who tested the previous version of the game. I have a new version, please let me know what you think, and whether there are any improvements you see which need to be made (except for the switch to C & OpenGL suggestion, thanks K^2 :P)

Here's a new version: http://www.lithiumdream.com/superfrog/S ... 070122.zip

One of the major changes to the packaging is that I included the managed runtimes, so, the game should work with any old version of DX9 (or perhaps DX8?) without having to worry about any Post-October DX9.0c sillyness.

I added a fixed timestep to physics, so those of you who couldn't get high enough on the springs, and SupSuper who had insane run speeds will have their problems fixed.

I've also slowed the player down significantly - it should be pretty-much like the original superfrog by now. Run acceleration is a bit higher, but that can be changed via the Media/Player.xml - if any of you guys want to edit the file, and end up finding some values (max run speed, acceleration, etc) which suit the game even better, let me know what they are, and I'll set the values as that for the next release.

There is now a basic death screen for when you land on spikes, with the dizzy animation when you reset to the beginning of the map, or touch monsters. The player flashes, and becomes invulnerable for 8 or so seconds after touching a monster.

There is still no real gameplay yet - you can't kill monsters, get points, or exit the level (you just get to the end, but stay in the map)

Mainly, I just want to make sure that the problems from the last release have been eliminated, and new problems haven't come up.

Thanks! :)

User avatar
AndrewTaylor
Regular
Posts: 157
Joined: Tue Mar 01, 2005 11:01 am
Location: Leeds UK
Contact:

Post by AndrewTaylor » Tue Jan 23, 2007 12:18 am

K^2 wrote:it's just not worth it.
Words I never thought I'd read from you!

User avatar
SupSuper
leek hackspinn0r
Posts: 378
Joined: Mon Feb 28, 2005 5:04 am
Location: Portugal
Contact:

Post by SupSuper » Tue Jan 23, 2007 1:14 am

It's hyper-fast again! :cry:
Team17 Forum Refugee | OpenXcom Developer

Moxy
Newbie
Posts: 36
Joined: Wed Nov 29, 2006 6:15 am
Contact:

Post by Moxy » Tue Jan 23, 2007 2:18 am

SupSuper wrote:It's hyper-fast again! :cry:
*sigh* I wonder if it's something to do with the parsing of the velocity values when they're loaded in from the config file. Seems to be happening only for you so far. I sent you a PM with some changes.


Edit: ha ha ha. ha I think hardcoding the values is going to work fine for you.

Looking at the number formats in Portugal, commas are to signify decimal place, like: 123.456.789,00 - where decimals are used to represent thousands, whereas in the Player.XML, a decimal is used to signify a decimal place - and I don't specify country code, so that's probably where the problem is coming up.

So, for example, with the Portuguese country code set, 400.0 is being recognised as 4000, whereas "400,0" would be recognised as 400.

K^2
Regular
Posts: 216
Joined: Thu May 26, 2005 4:02 am

Post by K^2 » Tue Jan 23, 2007 5:32 am

That's what you get for using a pre-built parser, rather than writing your own.
None of my projects (Minus One converter, W3D/W4 Map Viewer, and WMapEditor) are endorsed, supported or otherwise affiliated with Dream17. I just find Dream17 forums to be a nice place to share and discuss my work with others.

Moxy
Newbie
Posts: 36
Joined: Wed Nov 29, 2006 6:15 am
Contact:

Post by Moxy » Tue Jan 23, 2007 9:13 am

K^2 wrote:That's what you get for using a pre-built parser, rather than writing your own.
LOL. True.

User avatar
SupSuper
leek hackspinn0r
Posts: 378
Joined: Mon Feb 28, 2005 5:04 am
Location: Portugal
Contact:

Post by SupSuper » Tue Jan 23, 2007 10:52 am

Moxy wrote:
SupSuper wrote:It's hyper-fast again! :cry:
*sigh* I wonder if it's something to do with the parsing of the velocity values when they're loaded in from the config file. Seems to be happening only for you so far. I sent you a PM with some changes.


Edit: ha ha ha. ha I think hardcoding the values is going to work fine for you.

Looking at the number formats in Portugal, commas are to signify decimal place, like: 123.456.789,00 - where decimals are used to represent thousands, whereas in the Player.XML, a decimal is used to signify a decimal place - and I don't specify country code, so that's probably where the problem is coming up.

So, for example, with the Portuguese country code set, 400.0 is being recognised as 4000, whereas "400,0" would be recognised as 400.
Hmm you're right, if I remove the ".0" from the XML values, it works fine. Maybe you could just do without them? I thought you could just use "f" to define float values.
Team17 Forum Refugee | OpenXcom Developer

User avatar
AndrewTaylor
Regular
Posts: 157
Joined: Tue Mar 01, 2005 11:01 am
Location: Leeds UK
Contact:

Post by AndrewTaylor » Tue Jan 23, 2007 1:35 pm

Is this still being made in .NET? Because I'm pretty sure the text parsing routines can all be asked to override local settings with an overload.

None-.NET things can do that too, of course, but I know .NET languages do it very easily.

Moxy
Newbie
Posts: 36
Joined: Wed Nov 29, 2006 6:15 am
Contact:

Post by Moxy » Tue Jan 23, 2007 3:44 pm

AndrewTaylor wrote:Is this still being made in .NET? Because I'm pretty sure the text parsing routines can all be asked to override local settings with an overload.
Yeah, I'll do that for the next release.

It seems that some people are getting the "you get death" intro looping tons of times - yet not me. I'll also fix that for next release. Not sure why it's only a problem for some people yet, though.

User avatar
SupSuper
leek hackspinn0r
Posts: 378
Joined: Mon Feb 28, 2005 5:04 am
Location: Portugal
Contact:

Post by SupSuper » Tue Jan 23, 2007 11:27 pm

Another note, you might wanna add acceleration to SuperFrog's X movement, like the original had. Plus every proper platformer has acceleration. ;)
Team17 Forum Refugee | OpenXcom Developer

Moxy
Newbie
Posts: 36
Joined: Wed Nov 29, 2006 6:15 am
Contact:

Post by Moxy » Wed Jan 24, 2007 4:26 am

SupSuper wrote:Another note, you might wanna add acceleration to SuperFrog's X movement, like the original had. Plus every proper platformer has acceleration. ;)
There is proper acceleration. The max velocity or acceleration is probably too slow or subtle for it to be obvious, if you open up Media/Player.XML and change values there, you can set velocities to whatever you like. (but not in the custom versions I've been sending you - cos they're hardcoded).

Units are in pixels, each tile is 16x16 pixels, btw.

Also, something which I noticed in the original superfrog is that if you're running around, accelerating, etc, then jump, the player slows down to some fraction of the run speed - so I've tried to emulate this by setting the X velocity to the run start velocity in my game. Back in earlier versions, you could buld some speed, then jump over a big chunk of the map.

In the original, the start velocity is a bit slower, and the acceleration is much faster.

User avatar
Bloopy
Regular
Posts: 238
Joined: Mon Jun 20, 2005 1:07 pm
Location: New Zealand
Contact:

Post by Bloopy » Wed Jan 24, 2007 12:32 pm

Moxy, your clone is rather well done! The acceleration of Superfrog is noticeably different, particularly when running and then changing directions.
K^2 wrote:I have written code for very different hardware on just about every level imaginable, starting with straight up machine code and to high level languages that are not even imperative. Primarily, I have written various simulations and renderers, some for very powerful machines, some not so much. Some ran in real time, and others needed days to give you a few seconds of animation. One thing I learned better than anything is how to write efficient code for any particular machine, using every bit of advantage that hardware can provide me, and making sure that no cycles are wasted on something unnecessary. DirectX and C# do not give you that. They both cause a lot of extra unnecessary code to be executed. You can program in what you want to program, but if you ever want to write code that will push hardware to its absolute limit, you need to drop these two and learn to rely on your own code rather than flooding your program with runtime libraries.
Well, some people are interested in low level programming and some are not. :) I get the most enjoyment when programming in C# because I achieve more.
x_+

Moxy
Newbie
Posts: 36
Joined: Wed Nov 29, 2006 6:15 am
Contact:

Post by Moxy » Wed Jan 24, 2007 1:33 pm

Bloopy wrote:Moxy, your clone is rather well done! The acceleration of Superfrog is noticeably different, particularly when running and then changing directions.
Thanks heaps :)

I'll set it up so that changing directions is subject to conservation of momentum for the next release.

S2K also told me that there is some jitter on his machine, I think I found where the problem is, so that'll also be fixed for next release.

Also after you hit the spikes, the "you get death" animation keeps looping on some machines, this'll be fixed also.

I see you are from NZ, also. Which city are you in?

User avatar
Pooka
Staff Writer
Posts: 363
Joined: Mon Feb 28, 2005 8:57 pm
Location: London
Contact:

Post by Pooka » Wed Jan 24, 2007 6:32 pm

It's taken me ages to get round to playtesting this.

There aren't any problems that I can see. There's sone jitter on my copy, like S2K's, but nothing overly noticeable - it might also be something to do with the movement.

8 seconds is a bit too long for flashing/invulnerability; I started to get worried that SF would never stop flashing!

Other than that, the speed seems a lot better (a bit of resistance never hurt anyone) and I'm not getting any of the height problems I had last time. Overall, it's rather polished! Huzzah!
Superfrog: the best things in life are green.

Post Reply