Another Unreleased Game - Blaze

[Shatterhand]

You're grossly under-appreciating the effort behind game design. The engine, many times, is NOT the most taxing and time consuming aspect of making a game.
If he was alone making this, I would especially find it difficult to find the motivation without payment and on a platform already winding down at the time of development.

Quoted for truth.

Game design and assets creation will take a lot more of time than coding a competent engine.

[Amiga1992]

KEitH! Really appreciate you showing up and sharing the source code to the game!
If we manage to salvage your tools on disk, there's a really good chance the game can be expanded to completion and I believe this would be pretty awesome. But then we'll need proper game designers and am not sure how many are really active in this community.

Hopefully this gets picked up and worked on!
Love your game, really impressive.

[Korodny]

Originally Posted by keithbugeja

By all means, please do! As for the licence, I would say BSD.

Thanks, it's online! I specified the "modified / 3-clause" BSD license, as it's recommended to specify the actual variant you're using (there are three), let me know if that needs changing. I don't think the it matters in practice though, the different variants are explained on Wikipedia.

[Mrs Beanbag]

might have to up my game to compete with this

[PortuguesePilot]

Originally Posted by Mrs Beanbag

might have to up my game to compete with this

Actually, in my honest opinion, judging by your own games (in terms of game design), you're a good candidate to "pick Blaze up" and finish the game.

Ideally a team of talented people should do it. We're humans after all and each person usually occupies a niche in which he/she is really great. But very few of us are real polymaths in the sense that few of us are "one-man-bands". So a team (graphic artist, coder, musician, play-tester, etc) would be the best-case scenario for this situation (like it was in the recent excellent and happy-ending case of Putty Squad). I know this ideal scenario is somewhat over-idealistic (if you pardon the pleonasm) but a man is allowed to dream, is he not?

[adrdesign]

Amazing work! didn´t see anything like this before on amiga. I´ll love to see this game finished. If you need the music here´s my hand.

[s2325]

Another video, glitchy graphics but with better aspect ratio [ Show youtube player ] Because of these big flowers all I can see is Kid Chaos, not Sonic the Hedgehog.

[edd_jedi]

Originally Posted by s2325

Another video, glitchy graphics but with better aspect ratio [ Show youtube player ] Because of these big flowers all I can see is Kid Chaos, not Sonic the Hedgehog.

Very fast and glitchy, is that on an A1200? Somebody really needs to make a WHDLoad install for this which would hopefully solve the compatibility issues

[s2325]

I don't know, sorry, it's not my YouTube account but he is using mostly A1200 settings.

[gimbal]

Originally Posted by mc68060

But it's only 2 levels! I really can't understand why the author didn't finish it. I mean, the most important thing, the engine, seems to be pretty finished.

Because programmers are good at tech and perhaps far less good at level design Just because you're good at doing the tech does not mean you'll be able to produce the content, sadly.

[Reido]

Originally Posted by keithbugeja

The game was basically written during the school summer holidays (I was still in 4th or 5th form, I believe)

That's pretty impressive! You mentioned in your blog that you had lost lots of work, including a Street Fighter 2 clone, due to a damaged HD in your A1200. That's a real shame. Not knowing the ins and outs of recovering information from a damaged HD, is there any potential for salvage? Obviously you're busy with real life, but just considering how relatively poor the various Street Fighter 2 ports are on the Amiga (for various reasons), and how good your Sonic clone is, it looks like the Amiga lost out on a good SF2 clone. Thanks for sharing your work anyway!

[candyman]

Awesome work, really.

Unfortunately the Assembly code is almost unreadable for my knowledges
It would be a great thing for the community if some of the skilled people (like Asman, CodeTapper, Photon and many others) of this community while optimizing the code could find the time to comment the code step-by-step.

I mean a sort of Assembly game making tutorial for newbies like the one that Amiga Format published years ago about the creation of Menace.

The progress could be posted in a dedicated thread and the project could involve many people (there are also graphic designers and musicians on this board).

[Sir_Lucas]

This game looks really good for OCS/ECS.

[Dastardly]

Very impressive stuff. I'd be interested in seeing a version with Sonic's gfx applied to this, just to see how the Amiga version compares to the Megadrive.

[keithbugeja]

Hey, I've recovered all the remaining files necessary for building Blaze from source and made a short video about it - basically, how to build the game using Devpac 3.18 on the Amiga:

https://keithbugeja.wordpress.com/20...ce-code-redux/

The blog post also contains links to the missing files and a playthrough of the level using the binaries just built. The aspect ratio is correct this time round :P

Enjoy!

[saimon69]

If anyone want music for it lmk

[Havie]

Trired on my A1200 and managed to get it running but lots of very glitchy graphics - might be something to do with 030?

[Havie]

Originally Posted by keithbugeja

The screen is re-drawn every frame, from 32x32 pixel blocks; there is no actual scrolling. This allows fully animated blocks without additional penalty and also means that blitter objects (Bobs?) need not save and restore the background. Per-cell flags determine whether a block is drawn behind the player character (without the use of a mask), or in front of it, in which case a mask is applied to scissor the tile. The collectibles are actual map tiles, not 'sprites'.

I'm interested in this statement. When you say there is no actual scrolling - what do you mean? If you are not using hardware scrolling - how are you creating the movement? Excuse me if I'm missing something obvious.

[clenched]

Assembles fine with VASM Devpac compatible mode. Takes the better part of a second on my PC. Also noticed pressing J repeatedly gives great jumping capability.

WinUAE tests:
- Failed to load at all with Kickstart 1.3
- Loaded OK with Kickstart 2 but mildly glitchy graphics
- A1200 looks fine.
- saw this message on 68000 "FATAL CPU CRASH!" a couple of times.

Maybe I'll try Devpac later and see what happens.
Fine looking game.

EDIT: Using Devpac 3.02, Kickstart 1.3, game looks perfect. Kickstart 2.0 still some slight gfx trouble. Neither showed the fatal message this time. Didn't bother with A1200.

[keithbugeja]

Originally Posted by Havie

I'm interested in this statement. When you say there is no actual scrolling - what do you mean? If you are not using hardware scrolling - how are you creating the movement? Excuse me if I'm missing something obvious.

No, it's more like I wasn't clear enough. Let's say you have a typical side-scrolling shoot 'em up (like R-Type), with right-to-left scrolling; for every block (or tile) worth of horizontal hardware scrolling (say 16 pixels), the whole playfield is copied (blitted) and moved 16 pixels to the left, and a new column of tiles is drawn at the rightmost edge of the screen to fill the empty space.

In Blaze, scrolling doesn't happen this way - instead, the screen is composited from tiles each and every frame. Hardware is still used to control the scrolling at the granularity of pixels, but no 'software' scrolling is used, so to speak. The advantage of this method is that the whole playfield could be animated without any penalty in performance. Moreover, since the screen is basically redrawn at each change, one doesn't need to save the portions of background behind software sprites (bobs). The flip side is that the technique is limited in terms of fill-rate, which is why Blaze runs at around 25 Hz.

In a later project, I had experimented with decoupling the pixel scrolling from the rest of the rendering, and running it at 50 Hz. This resulted in silky-smooth scrolling, but sprite movement became very jittery (Think Superfrog). For the player sprite, solving the jitter was just a question of using hardware sprites, which are independent of the background, but for the other sprites, I had no suitable solution.

Hope this makes it a bit more clear.