http://www.selamta.net/Downloads/amharic_syl.pdf

Quote:

Quote: How long have you been working on this project ? Since Huey is going on vacation as we speak, I'll try to answer that question. I may be mistaken though. I think Huey started it in 2006, after which ARTRAG came along which his mad coding skills. I joined the team in 2007.

have you some idea already as to when it will be finished ?

maybe in 2010...

Quote:

have you some idea already as to when it will be finished ?

Well, I think of the project more as a therapy I have no idea how to waste my precious free time if we finish this project. So I try to slow down progress as much as possible

We try to finish it late 2009 early 2010. There are some things in the main engine that still need to be implemented:
- Enemy management (to track their status outside the rooms on re-entering)
- Object interaction with subweapons
(not sure if I'm forgetting something important)

The design tools need some work too. The level editor needs some dynamic flag allocation functionalitiy.
Flags can be global (whole game) or local (level). These flag can be used to track if items are already dropped. To track if some conversation/quest is already done. Or it can be used to let objects/enemies communicate with each other.

Once the main engine is done the hardest part (design) has yet to start. Luckily the script John made is very detailed and already helped a lot on the gfx design. But new things are added all the time.

At this moment progress is slow as vacation, work and kids are interfering a lot.

The do list IMHO
- status management for enemies (when leaving rooms)
- subweapon interactions with objects
- MC "vine mode" (to be able to act Tarzan like)
- MC tuning in swimming mode and other states (for HP and AIR)
- Tuning FSMs of existing NPCs
- New FSMs for other NPCs
- FSM specific code for Bosses
- Tons and tons of scripts and script code
- Level design

and naturally, on the tool side

- Tuning of Meteor to support some of the new datastructures
- Implementation in Enemator of the new FSMs

PS
Meteor and Enamators are our tools for level design and NPC design
The most impressive thing we did (as author I could be biased) is that the AI of NPCs is coded into the data and not in the code.
This means that the very same loop runs for all the NPC's, form bats to moles, passing trough bullets.

Looking at our code, none can infer a single thing of what a given NPC does
as all the FSM is coded in tables that encode state transitions, events and actions.

Quote:

The do list IMHO - status management for enemies (when leaving rooms) - subweapon interactions with objects - MC "vine mode" (to be able to act Tarzan like) - MC tuning in swimming mode and other states (for HP and AIR) - Tuning FSMs of existing NPCs - New FSMs for other NPCs - FSM specific code for Bosses - Tons and tons of scripts and script code - Level design and naturally, on the tool side - Tuning of Meteor to support some of the new datastructures - Implementation in Enemator of the new FSMs PS Meteor and Enamators are our tools for level design and NPC design The most impressive thing we did (as author I could be biased) is that the AI of NPCs is coded into the data and not in the code. This means that the very same loop runs for all the NPC's, form bats to moles, passing trough bullets. Looking at our code, none can infer a single thing of what a given NPC does as all the FSM is coded in tables that encode state transitions, events and actions.

I'm very impressed on your implementation of your AI in data method...especially on a MSX.
It has been done before but on powerfull machines !!
Also interaction with main player is something which is usually sacrificed with this kind of AI. So beware of this.

I'm eagerly looking forward to the release of your game.

Quote:

At this moment progress is slow as vacation, work and kids are interfering a lot.

Maybe using a schedule like I do could help you too?

I've a very demanding job and also many many hobbies(music...coding...electronics...and more)

So in order to do it all I've planned when I do what and how long...

that's why I know I will finish KM3 on time...it's planned out entirely ! And right now I'm even a bit ahead of schedule.....

so got some time to waste...so that's why I'm wasting it here...

Quote:

Maybe using a schedule like I do could help you too?

I do plan. But my work and kids are unplannable

Another nice feature we are proud of is the fact that all the sprite NPC's (we have also tile based NPC's) have two colour layers, one for the main colour and one for the detail colour with lower priority (normally used for black outline).

MC has normally 3 colour layers (one for detail colour with lower priority - used for black outline).

When the 5th sprite condition occurs, the sprite engine allows flickering only on the details.
If things go worse, the engine keeps only the main layers of MC and NPCs, avoiding flickering.
At worst, the engine keeps only the main layers of MC and NPCs, with flickering.

Moreover the flickering is "almost optimal".
I mean that we use the info on which layer(s) is(are) disappeared in a given frame and we make reappear it(them) just in the following frame.
At each fame, the engine resurrect always one or more hidden sprites.

I know this seems a detail, but in fixed sprite multiplexing or in random sprite multiplexing you can spend many frames before the hidden sprite is shown again.
Add the management of the two two colour layers with different priorities for NPCs and you'll get a not trivial piece of asm.