phoboz

Cool game, also reminds me about Qix. Although shouldn't it be possible to eliminate the bad guy by encircling him?

It looks like a found the issue related to the final bug, e.g. the sporadically corrupt end sequence. This was a though one to track down, but it turned out to be a synchronisation issue, e.g. the final level did not unload properly before the end sequence was loaded. This lead to corruption that would degrade the system further and further. After finishing the game 4 times in a row, it would crash when attempting to start a new game. Now I am just waiting for some independent verification of this fix. It looks like you will get a very robust game this time...

Yes, Asteroite is the most complex game I worked on so far maybe not because of the looks, but because of the size of the game, and the variety of different enemies, items, skills, bosses etc. More complex software will of course have a higher chance of containing bugs.

This was indeed a real bug in the game code. However, on a very specific platform there might be a series of fortunate circumstances that prevent the bug from becoming a problem. For example, in every case I have been involved in porting a piece of (non trivial) software from one platform to another, previously undetected bugs in the code have manifested as themselves as problems on the new platform. Apparently the differences between most of the Jaguars vs. a small portion of the K-series Jaguars are large enough to enable previously unknown software bugs to manifested themselves as problems. So the issue in this case was not that certain consoles had out-of-spec behavior, rather it was indeed a software problem. That is normally not an issue as you are supposed to detect these during validation, but both the platform on which the game was developed, and the platform it was tested on, did not reveal the bug, as it didn't lead to a problem. The actual bug was in this case that I attempted to continue iterating over the elements in a linked list, after the current node was invalid (or re-used for something else). A NULL element would terminate that operation, which I belive was the reason why it was working on most consoles.

Yes, but only on a few Jaguar K-series consoles, that's the reason it slipped trough validation (because it did not manifest on my development console, nor on @Songbird's test console). Lesson learned: Test the game on a few different Jaguar consoles that are know to behave differently. I had the same experience from the Vectrex scene, but thankfully there was a person who collected these out-of-spec consoles and were glad to test games on these different consoles. Due to the more analogue nature of the Vectrex this was a well known problem (e.g. mainly due to scattering in the actual capacitance of the integrator capacitors), but I was surprised to see this on the Jaguar as well?

@Songbird tried a debug ROM twice yesterday on a console where the game used to crash, but it appears that we have found a way to correct the problem. So I will ship out cartridges with the new version, once we have test played the new ROM a little bit more... So there may be a minor delay, because I have to scrap the cartridges I already built before the bug was brought to our attention. Fortunately, I didn't put any labels on the cartridges I built, and the cartridge shell can be re-used. I may also take care of some of the other minor glitches mentioned here... Belive me it was not easy to track this down, even if the change was only one row of code. We also found a bug in the Removers' library (or rather jlibc which is a prerequisite for the Removers' library). This bug was not the source of the problem with this game, but it is nice to know that malloc() now actually returns NULL when the Jaguar runs out of RAM if using the latest version of jlibc.

Thanks.

It would be helpful if someone showed me a picture where I can see which room this is, e.g. before the glitch? Or Mark in on the map screen somehow?

Finnally, material for building Asteroite arrived! Folded a few boxes last night, I will start shipping to those who pre-ordered from me in the coming days. (mainly people in Europe)

Congratulations, well done! You are the first person that have shown in public that you reached a 100% completion score.

Congratulations!

We have to decide in which order the projects shall be prioritised, but there are certainly prototypes for games to be released for years to come.

On my side the material from @Songbird is on the way in. I propose that you check with @Gaztee, it should be a similar situation on the UK side.

Yes, we both agreed that the Moonstone combat is not suitable, currently the control is more similar to Golden Axe (even if the dash move is still in development). Eventually, we may expand it to be a little bit more advanced. Regarding the AI, I did a first attempt which gave similar results are the AI seen in the Beats of Rage for Atari Falcon video in another thread on this forum. That didn't appeal to me (especially when there were more than 2 enemies on the screen), because every enemy went for the shortest path towards the player, many times they were completely overlapping each other. I hope to make something a little bit better for this game. In relation to RPG elements. We are thinking about some kind of experience point collecting system, with gradual improvement of the characters abilities as result. We will see how much of all this can be implemented in the end?

My original inspiration was actually Moonstone for the Amiga, but the combat system of that game is not for beginners (definitely not a good match for the JagPad) I am still hoping that we can get some RPG elements into Hammer of the Gods.

It also has to do with the size of the sprites (from the Object Processor's perpective) I am not sure what sprite sizes Streets of Rage had, but the Knight character is a 128x128 sized sprite, and the current enemies are 112x128, or similar.

I don't say we really need 10, but we might have some other, non interactive characters on the background (like a blacksmith). The key to optimize AI is to not check and make decisions every frame. Rather each character has a counter, and when that counter expires things are checked and decisions are taken. Then these counters are given different start values so they don't expire all at the same time. This way, the only thing needed to be done every frame (for all characters) is just to increase a counter, and check if it has expired.

I tried to max the engine out, and 10 characters in total is the limit. Not because of the much debated 68000 "blast processing" CPU of the Jaguar, but because of the much praised Object Processor. You see on the first section with 3 parallax layers, small lines start to bleed though at the black borders on the sides of the screen (yes we do want to cover the over-scan area, because there are some nasty things going on there when the screen is scrolling)

You are probably referring to the project below? I tried to look at the Open BOR code, and very much of the code was dedicated to loading animated .gif files from a filesystem (but the Jaguar does not have a filesystem, usually part of an operating system for a computer). I wanted to take a different approach than spending several months to write runtime capable .gif decompression algorithm (on the GPU), and I am not sure that it would be fast enough in the end. Of course the code related to the actual game might be helpful to look at, but personally I am not smart enough to understand someone else's code faster than writing my own code. So my estimation is that it might take as just as long to port Open BOR, than to write a custom Jaguar engine from scratch. I did not work so much on the AI yet, because my first attempt lead to that all the enemies walked the shortest path towards the player, many times overlapping each other. This did not look very good when I had 8 enemies on the screen at the same time (mostly overlapping). Now I see in the video above that this version of BOR seems to have a similar behaviour, but this was different in games like Golden Axe, and Final Fight. Maybe the AI was improved for later versions of Open BOR?

Yes, Krauser has an idea about a combo system. This genere is new to me as a developer, and the last game like this I played was Golden Axe (I may have tried Legend once?) I guess that a lot has happened to the genere since then? It will take some time before we have a combat system we feel confortable with. What you see now is just a minimal base to build further on...

Belive me, the time is not completely wasted.

I will reply to you privately.

We are thinking to have at least 3-4 different selectable character races (e.g. Knight, Archer, Magician, etc). How many of that could play at the same depends on how much we can squeeze into the 2 MB of RAM that the Jaguar has. The number of different enemies at once also affects RAM usage. If we cannot fit more than 2 players at once in normal mode, we may add a mode where 3-4 players could face off against each other (without external enemies), using team tap.