Yeah, I called that problem early.

For the most part, from a programming standpoint, what we need is really, really, really simple. Tilemaps with no fancy collision detection? Mouse-based weapons? Some scripted dialogue? For the most part this is amateur hour stuff and not a whole lot of elaboration is even possible. Perhaps we should have picked Allegro 4.0 instead of 5.0. I wouldn't be having problems monitoring the project (and saying what's needed), and I suspect others wouldn't as well, making it easier to get into. For all I know, people have wanted to help, tried to install Allegro 5.0, and gave up.

Trezker said he had been busy lately too so that is no doubt a big contributor to the minor stall; maybe we could get a word or two from him on a to-do list? Or anyone else with their mitts in the code? I would like an answer to the following, preferably from Trezker: what is the minimum left that would have to be done to get a demo working that loads maps and lets the player interact with them (basic collision detection with walls), allows switching from map to map via doors, lets you shoot basic targets with the gun weapon only, and allows you to talk to stationary NPC's (no scripted scenes with movement or anything, just dialogue)? No particles, no inventory menu system, no fancy scripting, no complex item or level interaction. If I said that demo had to ship by Friday, what would need to be done?

The basic stuff

• loads maps - Done

• lets the player interact with them (basic collision detection with walls) - Done

• allows switching from map to map via doors - N/A yet

• lets you shoot basic targets - N/A yet

• talk to stationary NPC's - N/A yet, this has fallen under Matts area and he's playing around with gui's and learning C++. At least he's one of the few who got A5 working on linux and windows...

The awesome stuff

• scripted scenes with movement and everything

• particles

• inventory menu system

• complex item interaction - Define complex? Entity interaction script is done.

If I said that demo had to ship by Friday, what would need to be done?

Todo

• map switch - Should be easy to do, entity handling for this case might pose a little problem...

• lets you shoot basic targets - The basic collision system is in place, just needs a little implementation for lines, then the entities need a little shooting code in Update.

• talk to stationary NPC's - Could be done with a simple class that can be accessed from lua, which was my original plan until my discussion with Matt left it hanging under his menu system plans...

OOOH CHEAP SHOT! Seriously though, I didn't know map loading was done. I need to look at that code and make sure my editor can churn out the correct formats. Sprites can be done with "programmer art" for now.

I think I've got the directional tile collision detection working as well, at least for map tiles only. I'm still trying to make it so you can't walk on top of the other NPCs (I think I need to inherit from the Obstacle class, but I'm still not entirely sure about that yet).

I would really like to have a graphical "debug" obstacle layer that shows which direction movement is allowed (and blocked) on based on a binary system (see my branch's include/obstacle.h's enum for BLOCK_NONE .. BLOCK_ALL). That way, when we throw down a random number on the tilemap, we can see how things are being blocked based on the obstacle layer.

I've drawn a rudimentary "blocked tilemap" PCX spritesheet, but don't know where to implement it so we can actually see it, if someone wants to work on that (I'll be pushing that up shortly).

The map doesn't have any animation or script support, only layers and collision.
Also, as I said, entities aren't quite tied in with maps yet...

The tileset is stored in its own file.
The map only has a number of layers with indexes that are passed to the Tileset class in the engine. Animation has nothing to do with the map class, that's something the Tileset class should handle, it's just not implemented because I didn't know how the Tileset image file will look with animation frames.

The tileset file format is currently just pointing to an image file and the specifies tilesize. How to add animation support to this I don't know.

media/tileset_placeholder.png
32 32

Maybe specify an animated tiles with animate [index] [frames] lines
animate 12 3
animate 24 4

I wouldn't mind if someone other than me took care of implementing animated tilesets.

Multilevel maps have not been planned at all and I don't think our master designer has even planned on having that feature in the game. But I guess it wouldn't hurt to have it in there.

One thing you did not bring up is the issue with triggers. I think these should be part of the map but not strictly bound to the grid.

Trezker: From the wiki mockups, it appeared to have at least two "levels": it's like you have to climb up on a ladder or to the top of the castle wall to get to some of the items (like that key or other item). They were not all on the same plane.

I thought of Zelda for the SNES, where your character may be on an upper "level" and the guards, who are on a lower "level", don't see you.

I've actually got a lot of the code working for all of this already (more of a surprise to me than anything), except of how to actually handle the file input structure.

For now, until we move to a map editor, everything is in ASCII text files, and I'm trying to figure out how to just load everything.

media/
  WORLD_0/
    map0/level0.txt
    map0/level1.txt
    map1/level0.txt
    map1/level1.txt
    ...
  WORLD_1/
    map0/level0.txt
    map0/level1.txt
    map0/level2.txt
    map1/level0.txt
    ...

Some structure like this is how I was thinking about it. Though if others have better ideas, that'd be great. I don't even intend for this to be the permanent structure: just something that works, that we can throw out there, and that others can come along later and redo when a better system is developed.

When I think of "triggers", I'm thinking of things that you interact with (or that interact with you) when you either walk close to them, or stand next to them and press the action key.

If we all like this "multiple levels" approach for each map, I think that these triggers should be tied to each "level" so you can have something activate if you're on the top of a bridge, but that doesn't activate if you're underneath it instead. Is that what you're talking about?

Here's a nice naggy post about organization, having carefully COUGH studied COUGH what's going on with this project. (Disclaimer: I don't know what's been done and who's working on what. That might be problem no.1, although to you it might be clear. Also I can't find a clear to-do list.)
The best approach to organise this thing seems to be:
Splitting up the tasks in urgent, necessary and optional. Urgent tasks are performed by people assigned to it, and are evaluated periodically i.e. have deadlines. Things like the level-loader/editor/format (that really seems like one task). There is only one or at most two urgent things happening at once. And somebody working on an urgent task, should not even look at other things. Once a urgent thing is done, a necessary task is picked to be urgent. Anyone can pick-up a necessary or optional task however: and somebody who has, might be the one assigned to the urgent task. Also it might happen two people have been doing the same thing: it's of no concern to The Project. Optional tasks are completely open: you can even invent new stuff.
It is important especially for the non-urgent tasks that there is a concept:
a method to draw to the screen for menu's, handles for scripts, concept art for sprites, instruments for music. Urgent tasks might be providing such concepts.
It is nice to think in terms of a non-changing API with placeholders where necessary, but perhaps in the early stages it would better to just code separate things and build an API on that. But I think you are about at the end of "early stages". I don't know much about version control, but a benefit seems that additions in early development can be abandoned by one and picked up by someone else: i.e. everybody should update his/her branch as much as possible (also for the reason some people might mysteriously disappear).
You are trying to find a way to make Monday projects work, aren't you?

After reading some wikipedia with as only lead "critical path analysis" (yes, I'm sort of a layman/n00b), I actually have an answer to your question.
To do list would be a good idea. But the rest is too much work. In my proposed management the manager only has 1 or 2 tasks to really take care of. Remember, the manager is also just a hobbyist. (Are there hobbyist managers like hobbyist programmers?! That would be... scary Or handy...:o)

Some TODOs that I see in the trunk:
http://svn.miquelfire.com/svnview/wsvn/monday/trunk/Code_todo.txt
http://svn.miquelfire.com/svnview/wsvn/monday/trunk/Implement_todo.txt

Note, everyone has read-only access to the project anyway (or should). Only if you need write access do you need to contact me.

Could the original poster edit his post to contain links to important posts/links (Mark Oates webpage, decisive choices, todo lists, wiki's) so we can have a set location to locate what's needed for this project? It's over 30 pages of posts for me and I don't feel like reading through to find "direction" posts around the "derail" posts.

I think it should all be put up on the wiki. That way its all in one nice easy place.