Superfrog kind-of-fan-clone public tech demo
Moderator: Dream17 Staff
Superfrog kind-of-fan-clone public tech demo
Hi all,
A public test version of the game is all ready, check it out and let me know what you think. It's still in early-alpha stages, btw.
Download here: (edit: link removed - check my other posts for a newer release, or later check my website for a fully public release)
There is no installer, so simply unzip it somewhere on your computer, and run platformer.exe. It starts in windowed mode by default - simply press ALT+Enter to switch to fullscreen.
You can find out more about the project on my website http://www.lithiumdream.com
You need DirectX9.0c Post-October 2005 installed (simply because the post-oct releases have the managed runtimes), and the .Net 2.0 runtimes. If you ran this app successfully in the past, you should have no problems running this new version. If you're unsure whether or not you have the prerequisites - just try running the game, and seeing if it works.
You can get DX9 from: http://www.microsoft.com/downloads/deta ... laylang=en
and .Net 2.0 from: http://www.microsoft.com/downloads/deta ... layLang=en
In this early tech-demo test version, at least, are a bunch of cases where behavior doesn't match Superfrog. These aren't bugs, they're simply unimplemented parts of the game:
* Bees don't jitter around like in the actual Superfrog
* I scattered monsters about randomly - just for testing, for now.
* There is no score or forced exit-criteria yet; the player can pick up coins, fruit, etc with no benefit.
* Monster collision exists, but there is no notification or penalty yet. (although there is for spikes)
* You can exit Forest1-1, but trying to exit the second level (Forest 1-4) does nothing (just hit esc to quit)
* In the second level, spikes don't do anything
That's all I can think of right now.
Since I last posted, I have found a couple of artists who are keen on working on an original game, I'm intending on writing an engine which is an extension of the Superfrog-style engine - with maybe 3-5 maps total, so while we sort out our original IP, I'll continue coding up a semi-fan-remake of Superfrog.
A public test version of the game is all ready, check it out and let me know what you think. It's still in early-alpha stages, btw.
Download here: (edit: link removed - check my other posts for a newer release, or later check my website for a fully public release)
There is no installer, so simply unzip it somewhere on your computer, and run platformer.exe. It starts in windowed mode by default - simply press ALT+Enter to switch to fullscreen.
You can find out more about the project on my website http://www.lithiumdream.com
You need DirectX9.0c Post-October 2005 installed (simply because the post-oct releases have the managed runtimes), and the .Net 2.0 runtimes. If you ran this app successfully in the past, you should have no problems running this new version. If you're unsure whether or not you have the prerequisites - just try running the game, and seeing if it works.
You can get DX9 from: http://www.microsoft.com/downloads/deta ... laylang=en
and .Net 2.0 from: http://www.microsoft.com/downloads/deta ... layLang=en
In this early tech-demo test version, at least, are a bunch of cases where behavior doesn't match Superfrog. These aren't bugs, they're simply unimplemented parts of the game:
* Bees don't jitter around like in the actual Superfrog
* I scattered monsters about randomly - just for testing, for now.
* There is no score or forced exit-criteria yet; the player can pick up coins, fruit, etc with no benefit.
* Monster collision exists, but there is no notification or penalty yet. (although there is for spikes)
* You can exit Forest1-1, but trying to exit the second level (Forest 1-4) does nothing (just hit esc to quit)
* In the second level, spikes don't do anything
That's all I can think of right now.
Since I last posted, I have found a couple of artists who are keen on working on an original game, I'm intending on writing an engine which is an extension of the Superfrog-style engine - with maybe 3-5 maps total, so while we sort out our original IP, I'll continue coding up a semi-fan-remake of Superfrog.
Last edited by Moxy on Mon Jan 22, 2007 2:46 pm, edited 3 times in total.
Requiring .NET and DirectX for a 2D platformer is ludicrous.
Edit: If you want, I can take a look at the source and try to fix that problem.
Edit2: After 45 minutes of my life have been forever snatched by .NET and DirectX updates, I got the game to run. It feels pretty close to the original. SF seems to move a little faster than in the DOS version, but that's about it. I was a bit disappointed when all the secret places weren't there, but it probably just isn't implemented yet. Also, bees don't seem to move when you don't. Did they really behave like that in the original?
Edit: If you want, I can take a look at the source and try to fix that problem.
Edit2: After 45 minutes of my life have been forever snatched by .NET and DirectX updates, I got the game to run. It feels pretty close to the original. SF seems to move a little faster than in the DOS version, but that's about it. I was a bit disappointed when all the secret places weren't there, but it probably just isn't implemented yet. Also, bees don't seem to move when you don't. Did they really behave like that in the original?
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.
Which problem are you referring to? The fact that you don't like .NET?K^2 wrote:Requiring .NET and DirectX for a 2D platformer is ludicrous.
Edit: If you want, I can take a look at the source and try to fix that problem.
I'm glad you got it to work.K^2 wrote: Edit2: After 45 minutes of my life have been forever snatched by .NET and DirectX updates, I got the game to run. It feels pretty close to the original. SF seems to move a little faster than in the DOS version, but that's about it. I was a bit disappointed when all the secret places weren't there, but it probably just isn't implemented yet. Also, bees don't seem to move when you don't. Did they really behave like that in the original?
![Smile :)](./images/smilies/d17_smile.png)
The renderer code is fully abstracted, and so focused, that I could write up a new renderer to avoid DX. However, I'm planning on an original game which will be an extension of this engine, which will definitely require DX.
As for .NET, when I started the project I wanted to learn C# - after a couple of weeks I really, really liked the C# language, and made the project deeper.
This is still an early tech-demo, so some aspects of the game aren't "right" yet. Regarding the secrets areas: they should be all there for Forest 1-1 - that's the only level that's pretty-much-complete.
The bees should move, even when you're not. Perhaps they're hitting their max radius before you realised?
The problem is that it uses .NET, which it doesn't need. Not that anything actually needs .NET, but this game less than anything else I've seen.Moxy wrote:Which problem are you referring to? The fact that you don't like .NET?
If you want to run 3D code, use OpenGL. That will make your code more efficient, stable, portable, and less dependent on versions of software installed on the machine.Moxy wrote:The renderer code is fully abstracted, and so focused, that I could write up a new renderer to avoid DX. However, I'm planning on an original game which will be an extension of this engine, which will definitely require DX.
C# exists for writing business applications by hiring the cheapest coders you can find, and still ending up with a secure product. If you actually want to learn to program, avoid C# like a plague.Moxy wrote:As for .NET, when I started the project I wanted to learn C# - after a couple of weeks I really, really liked the C# language, and made the project deeper.
I'll check again.Moxy wrote:The bees should move, even when you're not. Perhaps they're hitting their max radius before you realised?
Edit: Oh, I see. The max radius shouldn't be for to limit motion. The max radius should be for deciding whether the bee reacts to the SF. The bee should follow SF anywhere, but only when SF is close enough.
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.
- bucky o'hare
- Newbie
- Posts: 28
- Joined: Wed Aug 09, 2006 1:09 am
- Location: Connecticut
- Contact:
The bees don't follow SF, though. They pull towards his direction when you get near, but within fairly small parameters actually. They just kind of linger towards you once you get near 'em, but they'll follow you within an area probably less than that of a full screen.
Unless if it was different in different versions, but I know that the bees don't follow you on the Amiga.
That being said, they probably would make for more interesting enemies if they were capable of following you anywhere.
Unless if it was different in different versions, but I know that the bees don't follow you on the Amiga.
That being said, they probably would make for more interesting enemies if they were capable of following you anywhere.
Last edited by bucky o'hare on Thu Jan 11, 2007 12:59 am, edited 1 time in total.
Wow, K^2. As for your anti-.NET, anti-DX, anti-C# stance; you really need a reality check. You obviously have massive blind spots, are absolutely wrong about every single one of your assertations. Thanks for the contribution, but cool it with the negativity.
As for the max radius, you still haven't got it right. In the real Superfrog, the bees only follow you to a certain max radius, and only begin following you when you are close enough - however, as I keep saying; this isn't really Superfrog - so the gameplay isn't going to be exactly like superfrog.
As for the max radius, you still haven't got it right. In the real Superfrog, the bees only follow you to a certain max radius, and only begin following you when you are close enough - however, as I keep saying; this isn't really Superfrog - so the gameplay isn't going to be exactly like superfrog.
That sounds like a good idea. Perhaps I'll set it up so that they follow you some fraction of your speed, and don't stop following you until they are offscreen or something.bucky o'hare wrote: Unless if it was different in different versions, but I know that the bees don't follow you on the Amiga.
That being said, they probably would make for more interesting enemies if they were capable of following you anywhere.
K^2 is an extremely "down-to-earth" programmer, but you get used to it.
As for your game, it's nice, as far as I could tell. I mean, it looks exactly like Superfrog, but it's unplayable for me, since the game runs at super-hyper-warp-drive-speed. A single key tap is enough to make him zoom across the landscape to the point it screws up scrolling and ignores collision detecting. Any movement, even jumping, has the same effect (the latter making him get stuck at the top of the game).
I'm sorry, but this is just...![Surprised or Shocked :shock:](./images/smilies/d17_eek.png)
As for your game, it's nice, as far as I could tell. I mean, it looks exactly like Superfrog, but it's unplayable for me, since the game runs at super-hyper-warp-drive-speed. A single key tap is enough to make him zoom across the landscape to the point it screws up scrolling and ignores collision detecting. Any movement, even jumping, has the same effect (the latter making him get stuck at the top of the game).
I'm sorry, but this is just...
![Surprised or Shocked :shock:](./images/smilies/d17_eek.png)
Team17 Forum Refugee | OpenXcom Developer
Woah that is the first time I heard of that happening. I'm glad I posted on here. It's definitely not normal behavior of the game.SupSuper wrote:K^2 is an extremely "down-to-earth" programmer, but you get used to it.
As for your game, it's nice, as far as I could tell. I mean, it looks exactly like Superfrog, but it's unplayable for me, since the game runs at super-hyper-warp-drive-speed. A single key tap is enough to make him zoom across the landscape to the point it screws up scrolling and ignores collision detecting. Any movement, even jumping, has the same effect (the latter making him get stuck at the top of the game).
I'm sorry, but this is just...
I'll have a think about the problem, then send you an email in a couple of minutes. This is definitely something I want to get solved ASAP.
Team17 Forum Refugee | OpenXcom Developer
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.Moxy wrote:Wow, K^2. As for your anti-.NET, anti-DX, anti-C# stance; you really need a reality check. You obviously have massive blind spots, are absolutely wrong about every single one of your assertations.
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.
- AndrewTaylor
- Regular
- Posts: 157
- Joined: Tue Mar 01, 2005 11:01 am
- Location: Leeds UK
- Contact:
I suppose it depends what you're doing.
Personally I use C# pretty much all the time now purely because I code on my own and it's so very, very much faster to develop an application when the language has built in UI, debugging, and so forth, and when you can check a box to do something instead of writing (or even pasting) ten lines of code to do the same thing. Sure, the apps run slower as a result but we've no shortage of CPU cycles here, and the computers' time costs less than mine.
The last 3D development I did was with OpenGL, in MSVC++4. C# is far, far from ideal for games, obviously, but that doesn't always mean it shouldn't be used for them, because considering the sheer number of such games that get abandoned partway through being made, reducing development time can be massively important -- it can mean the difference between a project getting finished and not, and I don't think a 2D platformer from the Amiga is going to push modern PCs to their absolute limits anyway, but I know I'd rather have a game that ran slowly than no game at all.
Personally I use C# pretty much all the time now purely because I code on my own and it's so very, very much faster to develop an application when the language has built in UI, debugging, and so forth, and when you can check a box to do something instead of writing (or even pasting) ten lines of code to do the same thing. Sure, the apps run slower as a result but we've no shortage of CPU cycles here, and the computers' time costs less than mine.
The last 3D development I did was with OpenGL, in MSVC++4. C# is far, far from ideal for games, obviously, but that doesn't always mean it shouldn't be used for them, because considering the sheer number of such games that get abandoned partway through being made, reducing development time can be massively important -- it can mean the difference between a project getting finished and not, and I don't think a 2D platformer from the Amiga is going to push modern PCs to their absolute limits anyway, but I know I'd rather have a game that ran slowly than no game at all.
Look, we could be arguing about this forever since every programmer has their own point of view on coding. Some have a thing for Java, some go back to the roots, heck, I know a programmer which would love nothing better than to write an entire essay on how C#/DX/XNA is the next best thing since creamed corn.
But that's not the point. We got a really accurate working SuperFrog fangame which is even made in actual coding and not some cheap GameMaker crap, so let's not scare the guy away, eh? Please?
But that's not the point. We got a really accurate working SuperFrog fangame which is even made in actual coding and not some cheap GameMaker crap, so let's not scare the guy away, eh? Please?
Team17 Forum Refugee | OpenXcom Developer
Uh, GameMaker is more than capable of making high quality games thanks. I use it myself as do a lot of my friends online who've even won games contests against people using 'real' languages...SupSuper wrote:But that's not the point. We got a really accurate working SuperFrog fangame which is even made in actual coding and not some cheap GameMaker crap, so let's not scare the guy away, eh? Please?
Don't matter what you use to make a game as far as I'm concerned as long as it's done well. I don't enjoy commercial PC games but I do enjoy quite a lot of indie games some of which have been created with GameMaker and Multimedia Fusion and the like.
Like I mentioned elsewhere I was thinking of doing a sorta Superfrog test level myself with all new graphics. Just thinking up the best way to work out the slopes before I start.
I'm not dissing the program, I was an avid Multimedia Fusion user myself. But usually, the easier people have it, the less effort they put into it, the sloppier it gets, the crappier it gets, and the more easily the project dies.Wolverine wrote:Uh, GameMaker is more than capable of making high quality games thanks. I use it myself as do a lot of my friends online who've even won games contests against people using 'real' languages...
Don't matter what you use to make a game as far as I'm concerned as long as it's done well. I don't enjoy commercial PC games but I do enjoy quite a lot of indie games some of which have been created with GameMaker and Multimedia Fusion and the like.
You're bound to find more crap made with basic free programs than masterpieces. Heck, I dare you to find more MMF platformers that actually use a good custom-made movement instead of the poor built-in platform movement.
Team17 Forum Refugee | OpenXcom Developer
Superfrog: the best things in life are green.
That's pretty cool, except for the nasty map jitter when the player moves around.
I switched my game to a proper fixed physics timestep a couple days ago, and had the same kind of jitter until I got the interpolation math right.
Is this a normal macromedia fusion thing, or didn't he construct the game correctly?
I don't know. I should ask him, really.
http://wired.st-and.ac.uk/%7Ewong/ for more games by the same. All hard as hell though.
http://wired.st-and.ac.uk/%7Ewong/ for more games by the same. All hard as hell though.
Superfrog: the best things in life are green.
Well the movement is basic move 'n' jump, which might be the built-in one, but the game is actually properly done and polished, which is something I don't see a lot these days.
![Smile :)](./images/smilies/d17_smile.png)
multimedia fusionMoxy wrote:That's pretty cool, except for the nasty map jitter when the player moves around.
I switched my game to a proper fixed physics timestep a couple days ago, and had the same kind of jitter until I got the interpolation math right.
Is this a normal macromedia fusion thing, or didn't he construct the game correctly?
![Razz :P](./images/smilies/d17_tongue.png)
Well how the game scrolls is up to him. Multimedia Function has built-in scrolling, but it's up to the author to decide when to scroll the screen and how much.
Team17 Forum Refugee | OpenXcom Developer
That's not the point, though. The problems occur when the frame rate doesn't match physics steps. If you have 2.5 steps fitting into a frame, you'll end up with alternating frames of scrolling a step distance x2 and x3, which will look a bit jerky. There can be two solutions. You can either make very small steps, or interpolate behavior for a fraction of a step. Moxy went with the later approach. 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.SupSuper wrote:Well how the game scrolls is up to him. Multimedia Function has built-in scrolling, but it's up to the author to decide when to scroll the screen and how much.
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.