So then, if the game engine is responsible for all of the stuff you don't see, the game content makes up all the stuff you do see. A well-written engine will separate itself as much as possible from the content, so that if someone with no interest in programming comes along later desiring to make a game, he can create totally different content, plug it into the engine, and BAM! New game. Just like Emeril. In Computer Science lingo this separation of function (engine) from form (content) is known as abstraction. The engine is not associated with any particular set of content, and performs equally well with any (and all) valid content.
Eventually, in the course of writing an engine, programmers must make some assumptions that result in the engine being capable of certain things and incapable of certain other things. As a general rule, the more assumptions the programmer makes, the less variety of content the engine can support, and the easier it is to write. I'm going to make mine as flexible as possible, but I've never done this before, so we'll see what happens.
So, where to start? Good question! I don't know! I started by brainstorming as many different things my engine needs to do as I could:
- keyboard input
- mouse input
- gamepad input?
- audio output (music, sound effects, etc)
- visual output (graphics, text, etc)
- load scenario
- load game
- save game
- settings
- video - what specifically?
- audio - what specifically?
- keybindings
That's a verbatim transcription of my notes, so I apologize if it's not very meaningful. To be honest, I didn't feel like this approach was very useful to me, either. So I chose a different method of brainstorming, one that's helpful when thinking about object-oriented class design. The gist of it is that you sit down and think of verbs your component needs to do, and nouns it needs to operate on. (For the CS inclined, in case it's not clear, the nouns will eventually correspond to objects, and the verbs will eventually correspond to methods.) I probably learned a fancy name for this technique in school, but I don't remember what it is.
- Verbs
- move
- clipping
- roll for random encounters
- trigger events
- speak
- PC conversation choices
- NPC responses
- trigger events
- trade
- buy/sell items
- manipulate gold/inventory
- trigger events
- fight
- use items
- retreat
- cast spells
- special conditions/effects
- perform basic attacks
- rewards
- trigger events
- interact
- push buttons
- move objects
- take objects
- trigger events
- Nouns
- world map
- dungeon/town map
- battle
- monster
- inventory
- PC
- NPC
- party
- item
- shop
- weapon
- armor
- trinket
- spell
- effect
Now we're starting to get somewhere! This definitely gives me a clearer idea of the functions my game engine needs to perform. For example, map objects will need to do various things when something tries to move-- they'll need to check to make sure that movement takes place within established boundaries, they'll need to check for random encounters after successful moves, and they'll need to allow special things to happen based on positions or timings. Keep in mind that this is far from an exhaustive list. Once I actually start coding, I'll probably revise this more or less constantly as I stumble across new cases I didn't consider this very afternoon.
Astute readers will have noticed that every verb I list has the ability to "trigger events". Events are all of the "special" things that happen as a result of the player's actions in the game. Honestly, much of the fun of the game will be determined by the quality and flexibility of the special event and special effect systems. These are the parts of the engine that allow designers (mostly just me, later) to create exciting and dynamic encounters, items, and scripts. I haven't decided how I'm going implement these just yet, but rest assured that they'll get a post of their own later.
Astute readers will have noticed that every verb I list has the ability to "trigger events". Events are all of the "special" things that happen as a result of the player's actions in the game. Honestly, much of the fun of the game will be determined by the quality and flexibility of the special event and special effect systems. These are the parts of the engine that allow designers (mostly just me, later) to create exciting and dynamic encounters, items, and scripts. I haven't decided how I'm going implement these just yet, but rest assured that they'll get a post of their own later.
No comments:
Post a Comment