Time? Otherwise you do it.

It's in mind. Waaaay in the back, is all.

I have started putting together the Game class. The hub of activity in my design.

Now there is one question I would like an answer to. How do we handle input?
I'm imagining this as an old style console game with only button input, no mouse. I thought we could make an input hierarchy of menu>dialog>player. So if a menu is open it gets all input, then if a dialog is open but no menu it gets all input and if neither dialog or menu is open you can run around with the avatar and blow shit up.

As an improvement over KQ, you should always be able to open an in game menu by pressing esc (or select/start on whatever) and choose to skip dialog or exit to main menu. Pressing esc in any menu should close it.

Anyone have objections?

How do we want the .map file designed? We could do XML, standard UNIX config file, our own proprietary thing, or one of those other things that Cortex Command uses.

whaddayathink?

Trezker: I need to finalize this as I design the dungeons, but we're currently going with the idea of keyboard movement, mouse aiming/shooting.

This seems extremely unintuitive to me. I think a skip button makes a lot more sense, and not just to me, but your average joe. I can't even remember a time where I accidentally skipped a scene.

If you're worried about people skipping them on accident, I think the best idea would be to keep a "journal" of all the scenes, and the player is able to replay scenes that they've encountered.

SquareEnix did it in FFXII and I think it's brilliant. I'm sure they'll do it again for FFXIII. There's nothing unintuitive about it. That's like saying a file deletion confirmation is unintuitive.

This is a good idea, however, it doesn't solve the problem of accidentally skipping the cutscene. Either way, the flow of the game is broken, which is very annoying for users (at least for me).

Agreed. The optional prompt makes it even more user-friendly. Everybody gets what they want and if a user does unintentionally skip a cutscene it's probably his own damn fault for disabling the prompt.

The menu also has the advantage of offering to exit the game faster (rather than waiting for the after-cutscene elements to load and render, he can immediately exit if he so desires).

I don't think it matters much. I mentioned mouse because for some reason I figured it might cause some kind of problem... But now I've realized I was wrong.

I've written a very simple Menu class that has pointers parent menu and child menu. So you can go further into submenus and escape to parent menus, no mish mash. For now I just send in ALLEGRO_EVENT events to the top menu which sends it on to child if available, to its own handler if no child.

However we implement specific menus, I have no idea.

I'm attaching what I have done so far. I'm too lazy to start using svn for this yet. Also, an attachment is easy for everyone reading the thread to just download and take a look at. See it as a nightly snapshot...

There is not much comments in the code, so you'll have to just look around at your own risk. The Player, Animation, Animator classes is just something I ripped from my allegro 5 test project, I thought it'd be fun for everyone to fly around with Mr. Smiths famous Gryphon sprite.

Oh, maybe I should also mention I build the project with scons.
But it's using the speedhack organisation so you can use a makefile from there.

Yeah, the player class probably shouldn't know where the input comes from. It should just get events called up, down, left, right, shoot...

Okay, as long as we're using the Allegro hacker's guide, and it doesn't contain ALL the coding formats that we may encounter, where will this "new and updated" version be? Maybe as part of Mark Oates's page?

I'd like to do our own proprietary thing. Then you'd be forced to use a map editor to make changes. This means that the map editor itself could do a lot of the error checking and corrections, at the expense of easy readability and flexibility...

For the map format, binary formats are a pain in the @$$. It should be plain-text, editable with any text editor. We can provide a map editor and say "don't edit these unless you're sure you know what you're doing", but taking out the ability of knowledgeable users to fiddle the maps by hand is not a good idea.

EDIT: Also, we should start getting the code we have imported to SVN and giving developers access to it.

I third the text-based map format. Assuming we're going for open source, the whole project should be as open as possible.