goodAdventureGame ProgramStructure?

[Jigganis]

I'm trying out making a point and click adventure game in the vein of Myst. Not knowing much about good programming practice, I figured I'd ask here if anyone experienced with making this type of game had any ideas or tips for me on how I should be structuring this Flash

[GustTheASGuy]

Um you have a bunch of stuff and you can click them and they do stuff. Where does good programming practice come in? You don't even have to use AS because there are built-in behaviors (Window -> Behaviors).

[Rustygames]

MVC all the way

[GustTheASGuy]

No way. How horribly complicated can a clicky game get? There's hardly any model.

[reefermadness]

At 10/8/08 07:20 AM, GustTheASGuy wrote: No way. How horribly complicated can a clicky game get? There's hardly any model.

Well depends... If its a SCUMM style game (with inventory, depth of objects, quests or tasks)

it might be a good idea to use some arrays or whatever to store the info

[Rustygames]

At 10/8/08 07:20 AM, GustTheASGuy wrote: No way. How horribly complicated can a clicky game get? There's hardly any model.

lols

[GustTheASGuy]

At 10/8/08 01:14 PM, Rustygames wrote: lols

You have a bad habit of never seeing how ignorant you are.

[LeechmasterB]

At 10/8/08 07:20 AM, GustTheASGuy wrote: No way. How horribly complicated can a clicky game get? There's hardly any model.

Yet its a long text to explain what components you need even if its easy to program it. The really tough part about these games is content. Backgrounds, character animations (lots of those) as voice overs and the text ect. A lot of content running on little code.

Basic requirements or things you ll need in short:
Collision Detection
Event Queue
Pathfinding
Inventory
Level Loader
Object Actions
Dialogue Manager
Animation Managerl
Sound/Music Manager
File Persistency (for savegames ect.)

That pretty mutch sums it up. I worked on one and like said the tough part is content and not the code.

cheers

[Rustygames]

At 10/8/08 01:24 PM, GustTheASGuy wrote:

At 10/8/08 01:14 PM, Rustygames wrote: lols

You have a bad habit of never seeing how ignorant you are.

You're black too

[GustTheASGuy]

Event detection, pathfinding? I don't see what you did there. Most of the components you listed don't have to communicate in any way. I don't consider that (ie., listing fancy names) a good argument for using MVC here.

[zedd56]

At 10/8/08 03:13 PM, Rustygames wrote:

At 10/8/08 01:24 PM, GustTheASGuy wrote:

At 10/8/08 01:14 PM, Rustygames wrote: lols

You have a bad habit of never seeing how ignorant you are.

You're black too

Rusty, stop making useless posts.

And dude, he's right, an all-click game can't be too complicated. Don't worry about program structure, that varies with the project. Just make sure your AS is neat, organized, and won't be a major pain in the ass when you want to go back and make a change.

[Ben-Fox]

The model for any clicky game comes down to a container with a list of "triggers" (clickable objects) in it. Activate the triggers in the right order to solve the puzzle and advance to the next one (or unlock a door, or whatever). For a more "freeform," MYST-like adventure you'd want your containers connected in a graph structure to allow you to make a versatile map for the player to explore.

Everything else is more or less gravy. Maybe some of the triggers are timed. Maybe they're in another room. Maybe you can only activate a trigger with a certain item in your inventory. Maybe certain triggers can only be activated after you've reached a goal condition in a previous room.

If you sit down and make a proper model for it, the sky's the limit for what you can do with a clicky. Modeling not only the puzzle pieces (the triggers) but ways they can interact with each other lets you easily open up puzzle staples, like pull lever A in room 1 to open door B in room 2

If what you're going for is a series of self-contained, linear puzzles that'll occupy your average person for 10, 20 minutes or so; behaviors and similar simple things are definitely the way to go. If you're shooting for a more complex, MYST-like puzzle game, the time spent building a model will be well invested.

[Rustygames]

At 10/8/08 04:26 PM, zedd56 wrote:

At 10/8/08 03:13 PM, Rustygames wrote:

At 10/8/08 01:24 PM, GustTheASGuy wrote:

At 10/8/08 01:14 PM, Rustygames wrote: lols

You have a bad habit of never seeing how ignorant you are.

You're black too

Rusty, stop making useless posts.

And dude, he's right, an all-click game can't be too complicated. Don't worry about program structure, that varies with the project. Just make sure your AS is neat, organized, and won't be a major pain in the ass when you want to go back and make a change.

Sorry, I don't mean to get in the way of your very useful post. You answered his question with "don't do anything". Great post, an absolute asset to this forum.

At 10/8/08 03:57 PM, GustTheASGuy wrote: Event detection, pathfinding? I don't see what you did there. Most of the components you listed don't have to communicate in any way. I don't consider that (ie., listing fancy names) a good argument for using MVC here.

Every program has a structure. You are describing singleton, which is fine, but it is still a programming structure none the less.