Project MOAM - Moon over Arba Minch (Development MSX Forum)MSX Resource Center MSX Info Update - Finnish MSX madness at its best              
              
English Nederlands Español Português Russian         
 News
   Frontpage
  News archive
  News topics

 Resources
   MSX Forum
  Articles
  Reviews
  Fair reports
  Photo shoots
  Fairs and meetings
  Polls
  Links
  Search

 Software
   Downloads
  Webshop

 MRC
   Who we are
  Join our team
  Donate
  Policies
  Contact us
  Link to Us
  Statistics

 Search
 
  

  

 Login
 

Username

Password




Don't you have an account yet? Become an MSX-friend and register an account now!.


 Statistics
 

There are 51 guests and 2 MSX friends online

You are an anonymous user.
 

MSX Forum


MSX Forum

Development - Project MOAM - Moon over Arba Minch

Goto page ( Previous Page 1 | 2 | 3 | 4 | 5 | 6 )
Author

Project MOAM - Moon over Arba Minch

ARTRAG
msx master
Posts: 1686
Posted: July 28 2008, 13:55   
RyJuZo
msx lover
Posts: 106
Posted: July 28 2008, 16:53   
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 ?
ARTRAG
msx master
Posts: 1686
Posted: July 28 2008, 18:20   
maybe in 2010...



Huey
online
msx professional
Posts: 586
Posted: July 29 2008, 09:42   
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.
ARTRAG
msx master
Posts: 1686
Posted: July 29 2008, 10:25   
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.


RyJuZo
msx lover
Posts: 106
Posted: July 29 2008, 14:40   
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.




RyJuZo
msx lover
Posts: 106
Posted: July 29 2008, 14:53   
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...






Huey
online
msx professional
Posts: 586
Posted: July 29 2008, 15:40   
Quote:


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



I do plan. But my work and kids are unplannable
ARTRAG
msx master
Posts: 1686
Posted: July 29 2008, 21:33   
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.

ARTRAG
msx master
Posts: 1686
Posted: September 22 2008, 15:33   
A small update about MOAM
It will have in game PCM audio (yes, in game, while the action flows!)

It will be real PCM with 8bit per sample, sampled at about 8KHz.

Now we have a replayer able to do mix PSG and SCC for music and sfx
In particular we have:

1) music only : psg+scc
2) music + aysfx : psg for music and sfx, scc for music
3) music + pcm : psg for music and sfx, scc for pcm

Here to have a taste of the PCM player

https://sites.google.com/site/testmsx/Home

(due to an HW flaw the PCM audio will not be perfect on real HW, never the less far better than nothing)



 
Goto page ( Previous Page 1 | 2 | 3 | 4 | 5 | 6 )
 







(c) 1994 - 2008 MSX Resource Center Foundation. MSX is a trademark of MSX Licensing Corporation.