Re: compiling it

On Linux, it doesn't take anything too special; I couldn't for a while because my libstdc++ was all screwy. A working install of gcc/g++ and A5 should work. On Windows, I don't know.

EDIT:
I just re-read the game specification on Mark Oates' web site, and we don't seem to be being that true to it. It specified wasd to move and mouse to aim/fire; is that still the plan?

As I suggested in IRC, it would probably be best if we all post our free hours in UTC so it's more easy to see overlap.

Monday - Friday: 23:00 - 04:00 UTC.
Saturday - Sunday: 18:00 - 07:00 UTC.

_{(These are typical and subject to change... :P)}

Not tomorrow, until the fifth. After then, I don't know yet.

I'm sort of new to IRC, but I think in some circles logging the conversations is considered unethical or something. I think a volunteer that documented the conversation as we go would be better (albeit, a log would help him do that after the fact). I'm not really very good at that sort of thing though.

If you can find anything that we can use there on freenode, even if it's an after-the-fact log that we find at some web address, it would be great.

FYI: On Monday, about 3-4 of us met and discussed what we could. Most of what I remember was trying to figure out how to handle movement, that we [still] need to implement the mouse "attack" feature, and that the HUD needs to be able to show us a few things: player health (most votes were for a graphical bar over a "33/40 HP" or "72% health" text output), weapon info like its icon (so we know what's equipped) and the weapon's stats (like remaining ammo or charge). Most votes were for a graphical representation (or text/graphical mix):
Ammo: ||||||||---or Remaining charge: |||||--------

Some things I feel we need to discuss:

• More HUD (though not a high priority)

• AI interactions (conversations?)

• Storyline (the website is good, but we need more detail)

I'll post more topics as I think of them (and as I have time). Some may be really quick "Let's not discuss this right now" back-burner kinds of things, others may be more pressing (like "Who wants to draw up a bunch of maps").

I think we should have a HUD. We can have it either tied to the Game to ensure that it gets drawn very last (over the top of everything else already rendered to the off-screen buffer), or tied to the Player, since it technically is only associated with the current Player, and can be called within the Player's own Render() function.

We will need to know the Player's HP. Will HP be part of the Entity class ("triggers" are Entities, too, remember... this won't give side-effects will it?) or individual Player/Enemy/NPC classes?

Or should there be a separate "Killable" kind of class that Player/Enemy (possibly NPC, but not necessarily) derive from?

Does the HUD show the enemies' HP (either as a number or a "health bar") over their heads in the HUD, or somewhere else?

What should CombatEntity handle?

• HP (hit points)

• MHP (max hit points)

• AP (attack power)

• DP (defence power)

• ...

Should it also contain all the functions needed for battle engagements, like CombatEntity1 attacking CombatEntity2, using healing items, etc.?

Not much need for attack and defense power. This game doesn't have fluctuating armor. All we should really need is how much damage each weapon does as a static number, and health. Nothing fancy. And the guns use energy, not ammunition.

The HUD will be very minimal. Basically a health meter, and two meters for whatever two pieces of equipment are currently bound to the mouse keys (jet pack fuel, charge on gun, etc). Maybe a few icons for the three dungeon keys to light up as you collect them. What else is really necessary? Not "would be nice". Actually worth our time?

I agree. I don't want to add things that are "yea, we might get around to that." I want to get the bare minimum done so we can move onto more things.

That's actually why I'm asking I don't want to make it all oh-so-expandable. Just enough to get by.

Okay, for the HUD:

• 1 meter for player's health

• 2 meters for remaining equipment energy

• 3 dungeon key icon slots

• http://www.allegro.cc/files/attachment/597423

For the weapons:

• All weapons will have a charge (instead of ammo)

• Weapons have a fixed damage amount (or range, like between 50..60?)

Will weapons be able to hit the entity that deploys them? Like, if the player is shooting a horde of monsters around him, can he accidentally shoot himself if he's not careful, or can he just start mad-clicking anywhere and know that he's not going to be hit by his own stuff?

This was a 30-second slapped-together mockup. What do you have in mind? I have NO artistic abilities, so I just threw together something that had all the components you were talking about just as long as I had the key components and features to start programming in. Making it look good is some else's job.

What about leveling up and experience? Can the player gain levels or is his powers constant throughout the game? If so, I like how Dungeon Seige (and others?) do it. They have say, three areas of experience (melee,ranged,and magic). The various areas go up depending on what the character does. The more melee attacks you do, the better your character gets in that area. A think that is a lot better than the old D&D style.::) Again...just my 2¢

Edit:
The status bars are really simple. Just uses simple math:

(CurrentValue / MaxValue) * LengthOfBar

This game isn't long enough for leveling up of that nature. The only leveling comes from the acquisition of better weapons.