So last night the worst non-hurricane storm in Virginia history rolled through my neighborhood, and I am without power. No power means no router means no internet, so I won't be updating for a few days while the power company figures itself out. Rest assured though, when the lights come back on, I'll have lots to update y'all about, since puny thunderstorms aren't enough to keep me from planning in notebooks and on graph paper!
(If anyone's wondering how I managed to post this, I'm at Panera, eating dinner.)
Saturday, June 30, 2012
Friday, June 29, 2012
EPI #6: Classes
The brainstorming I did on Wednesday got me started on the right track as far as thinking about designing a game engine. I didn't post yesterday because I spent the whole day hiking. This blog is going to get a little bit more technical as my ideas crystallize further and I start writing code, so I apologize to those of you who are not hip to the Computer Science lingo. However, don't get too disappointed, because there will still be a lot of work to do designing the actual game once the engine is ready.
I hinted on Wednesday that I will use an object-oriented approach to implementing my game engine. I'm choosing this programming paradigm because it makes the most sense. Games are broken up into multiple discrete functional units, and taking an object-oriented approach allows me to conceptualize and implement each of these different functional units separately. This makes it easier both to translate my thoughts into code and to keep my project organized. Honestly, keeping this whole thing organized is very likely going to be the hardest part of what I'm doing.
Some of you are probably curious about which programming language I'm going to use. I have decided to use Python for the sole reason that I need to learn Python before I start my real job in July. If I had other concerns, I might have made a different choice, e.g.: C++ (if I were actually going to write a real game, as in one I could sell to people maybe); Java (if I were a masochist and/or concerned about portability); or PHP (if I wanted to use something I'm comfortable with). For graphics, I'm probably going to use PyGTK, although I haven't really explored my options there.
I've blogged before about how nearly all of the action in a JRPG takes place on the world map, on a town or dungeon map, or in a battle. It happens that, from a coding standpoint, there's no reason to separate world maps from town or dungeon maps. In practice, the world, town, and dungeon maps will probably all be designed very differently from each other, but the engine needs to support the same set of features from all three. So in practice I've reduced the number of locations in which action happens from three to effectively two. Therefore, the first class I'm going to design will be the Map class:
I hinted on Wednesday that I will use an object-oriented approach to implementing my game engine. I'm choosing this programming paradigm because it makes the most sense. Games are broken up into multiple discrete functional units, and taking an object-oriented approach allows me to conceptualize and implement each of these different functional units separately. This makes it easier both to translate my thoughts into code and to keep my project organized. Honestly, keeping this whole thing organized is very likely going to be the hardest part of what I'm doing.
Some of you are probably curious about which programming language I'm going to use. I have decided to use Python for the sole reason that I need to learn Python before I start my real job in July. If I had other concerns, I might have made a different choice, e.g.: C++ (if I were actually going to write a real game, as in one I could sell to people maybe); Java (if I were a masochist and/or concerned about portability); or PHP (if I wanted to use something I'm comfortable with). For graphics, I'm probably going to use PyGTK, although I haven't really explored my options there.
I've blogged before about how nearly all of the action in a JRPG takes place on the world map, on a town or dungeon map, or in a battle. It happens that, from a coding standpoint, there's no reason to separate world maps from town or dungeon maps. In practice, the world, town, and dungeon maps will probably all be designed very differently from each other, but the engine needs to support the same set of features from all three. So in practice I've reduced the number of locations in which action happens from three to effectively two. Therefore, the first class I'm going to design will be the Map class:
- Map
- name: string
- actors: MapEntity[]
- tiles: MapTile[][]
- move(Character, integer)
- OrderedPair
- x: integer
- y: integer
- MapTile
- description: string
- passability: integer
- art_path: string
- art_resolution: OrderedPair
- specials: string[]
So then, the really important parts. A Map will consist of a matrix of MapTiles and an array of MapEntitys. Maps will also be responsible for moving their different actors around. A MapTile, in turn, consists of the file system path to the corresponding art and an array of special event definitions. MapTile "passability" will make sense when I talk about MapEntitys:
- MapEntity
- current_location: OrderedPair
- last_location: OrderedPair
- control: Intelligence
- Party extends MapEntity
- members: Character[]
- travel_power: integer
- Character
- (statistics)
- (equipment)
- (abilities)
- current_HP: integer
- maximum_HP: integer
Above are classes that describe things that act on the map. MapEntitys keep track of their present and immediate past locations, Partys are collections of Characters, and Characters are the bread-and-butter of RPGs. Party travel_power is compared against MapTile passability to determine whether or not a Party can move to a particular tile. If travel_power >= passability, the move is successful. Intelligence will be an interface that prescribes methods by which MapEntitys will make decisions. There will be several different implementations of this interface, representing AIs, humans, and maybe one day even networked players. Class properties in parentheses are things I haven't yet completely thought out that need to exist.
When you're planning a software development project, there is always more planning you can do. But what I've done and blogged about so far is probably enough for me to start writing code. I haven't really been talking about it, but when I think about class design, I also think about how the classes will interact with each other and the main game engine execution thread. So now I have a pretty clear idea of how these pieces will fit together to generate a map with a figure on it that moves around in response to input.
"But Zach!" you say, "You haven't talked about how designers will create content, or how that content will be interpreted by the game engine! Surely you'll need some content to test your code as you write it?" Yes. I will. You've made an astute observation, dear reader. And you've raised a question that will be answered in a later post. In another later post, I'll get into the details of how these lovely classes interact with the main game engine execution thread. Maybe I'll even abbreviate that MGEET in the future, since I can't think of anything better to call it.
When you're planning a software development project, there is always more planning you can do. But what I've done and blogged about so far is probably enough for me to start writing code. I haven't really been talking about it, but when I think about class design, I also think about how the classes will interact with each other and the main game engine execution thread. So now I have a pretty clear idea of how these pieces will fit together to generate a map with a figure on it that moves around in response to input.
"But Zach!" you say, "You haven't talked about how designers will create content, or how that content will be interpreted by the game engine! Surely you'll need some content to test your code as you write it?" Yes. I will. You've made an astute observation, dear reader. And you've raised a question that will be answered in a later post. In another later post, I'll get into the details of how these lovely classes interact with the main game engine execution thread. Maybe I'll even abbreviate that MGEET in the future, since I can't think of anything better to call it.
Wednesday, June 27, 2012
EPI #5: Flow
After brainstorming all those different capabilities last post, I got to thinking about how they'll interact. It seemed pretty straightforward to me to make a flowchart to describe the player's experience. It's easiest to think of each box as a distinct "screen" that will be governed by a distinct object (think of the nouns from the previous post).
However, that description isn't perfect. For example, the world, dungeon, and town maps will probably all be handled by a Map object. Also, I'm not sure that I want conversations to take place on a different screen from the map in which they originate. I made four other notes, which I'll transcribe in case they're illegible:
- no equipment management (handle in inventory?)
- no victory condition (ha ha)
- no special events (cutscenes, etc.)
- distinction between dungeon and town is probably unnecessary
What these notes mean is probably not very obvious. Let me explain them:
- Equipment management (i.e. dealing with which items are equipped to which characters) is probably something that I'll handle from the inventory screen.
- The victory condition is a super special case, and only occurs when the player successfully takes whatever action is necessary to win the game-- I'll worry about it later.
- I don't know how I want to deal with the special events which temporarily wrest control from the player.
- The "unnecessary distinction between dungeons and towns" note merely acknowledges that the same verbs can happen in each one, so there isn't a good reason to separate them logically.
So, the flowchart isn't perfect, but neither am I. And it's a damn good start!
EPI #4: Engines
If I'm going to talk about game engines in this post, I ought to start by explaining what exactly a game engine does. Basically, when you're happily chugging along through a video game, the game engine is doing everything you don't see. If there are physics involved, the game engine is doing the math behind the scenes so that the physics behave appropriately. If procs (processed random occurrences) are, erm, occurring, the engine is the man behind the curtain rolling the dice. The engine is what listens to the player's raw input (mouse movements, keystrokes, etc), checks to make sure that they make sense in context, and then performs whatever action the player (hopefully) expects.
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:
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.
Tuesday, June 26, 2012
EPI #3: Genre and Plot
It occurs to me that I haven't discussed what sort of game EPI will be. I'll do that now. My vision is for EPI to be a JRPG (a Japanese-style role-playing game). Think of pretty much any Final Fantasy game ever, or, to a lesser extent, Pokemon, and you'll understand what I'm talking about. You roam around a world map travelling to dungeons and cities, randomly encountering marauding bands of monsters who must be dispatched by your party's cold steel and fierce majick. (Or, encountering adorable critters who must be bludgeoned into unconsciousness and enslaved by your own adorable, enslaved critters.)
A brief tangent on RPG sub-genres: JRPGs tend to differentiate themselves from WRPGs (Western role-playing games, although I don't think anyone really uses that acronym) by focusing on characterization, relationships, and plot as opposed to the WRPG focus on game mechanics and rules. When someone mentions JRPGs, think of Final Fantasy, while when someone says WRPG, think of Dungeons and Dragons. There are lots of other RPG sub-genres, most notably the MMORPG (massively multiplayer online role-playing game; think World of Warcraft) and the ARPG (action role-playing game; think Diablo II), but I'm not going to get into those right now.
My Facebook friends really picked this genre for me when they chose the title. Although The Tempest: Escape from Prospero's Island could lend itself suitably to other genres, such as platformer (think Mario) or action-adventure (think Zelda), in my head these seem like they're more complicated to implement. I want to keep this project simple, so that I increase my chances of finishing it. Contrapositively, it wouldn't make a whole lot of sense to make SnakeRacer+ anything but a racing game, or Ultimate Frisbee 2013: Callahan Edition anything but a sports game. This isn't to say it's impossible-- some of the most fun and interesting games I've played are the ones that bend and mix genres for a unique effect. (See the postscript for examples.) However, I'm trying to understand the basics of game development through this project. I'll worry about heavy-duty innovation later.
My choice of genre also provides information about what sort of capabilities my game engine needs to have. Nearly all of the action in a JRPG happens in one of three places: the world map, a town/dungeon map, or the battle scene. This means that my engine needs to support all three of these generic areas. Characters in JRPGs also tend to have statistics and equipment. Thus, the engine needs to support statistics, equipment, and modifications, both temporary and permanent, thereof. I'll elaborate on my engine's capabilities further in a later post.
So then: a word or two about the plot. Choosing JRPG as a genre also informs the general arc of the plot. JRPG plots traditionally involve a band of relatively obscure characters exploring the world, visiting different locations, finding equipment, and growing in power until they are able to defeat the Big Bad Guy in a climactic battle to save the world.
In JRPG style, my vision for EPI's plot is for the player's character (PC) to awake on a deserted beach after a (space-)shipwreck. The player will then gradually explore the island, encountering settlements (yes, I know the island is supposed to deserted), caves, dungeons, monsters, loot, and potential companions, until he realizes his only hope for escape lies in the mysterious wizard's tower at the center of the island. The game will probably end with a climactic battle at the top of the tower against the wizard (Prospero) in the middle of a raging thunderst- tempest.
Postscript: Genrebending games I like (in no particular order)
A brief tangent on RPG sub-genres: JRPGs tend to differentiate themselves from WRPGs (Western role-playing games, although I don't think anyone really uses that acronym) by focusing on characterization, relationships, and plot as opposed to the WRPG focus on game mechanics and rules. When someone mentions JRPGs, think of Final Fantasy, while when someone says WRPG, think of Dungeons and Dragons. There are lots of other RPG sub-genres, most notably the MMORPG (massively multiplayer online role-playing game; think World of Warcraft) and the ARPG (action role-playing game; think Diablo II), but I'm not going to get into those right now.
My Facebook friends really picked this genre for me when they chose the title. Although The Tempest: Escape from Prospero's Island could lend itself suitably to other genres, such as platformer (think Mario) or action-adventure (think Zelda), in my head these seem like they're more complicated to implement. I want to keep this project simple, so that I increase my chances of finishing it. Contrapositively, it wouldn't make a whole lot of sense to make SnakeRacer+ anything but a racing game, or Ultimate Frisbee 2013: Callahan Edition anything but a sports game. This isn't to say it's impossible-- some of the most fun and interesting games I've played are the ones that bend and mix genres for a unique effect. (See the postscript for examples.) However, I'm trying to understand the basics of game development through this project. I'll worry about heavy-duty innovation later.
My choice of genre also provides information about what sort of capabilities my game engine needs to have. Nearly all of the action in a JRPG happens in one of three places: the world map, a town/dungeon map, or the battle scene. This means that my engine needs to support all three of these generic areas. Characters in JRPGs also tend to have statistics and equipment. Thus, the engine needs to support statistics, equipment, and modifications, both temporary and permanent, thereof. I'll elaborate on my engine's capabilities further in a later post.
So then: a word or two about the plot. Choosing JRPG as a genre also informs the general arc of the plot. JRPG plots traditionally involve a band of relatively obscure characters exploring the world, visiting different locations, finding equipment, and growing in power until they are able to defeat the Big Bad Guy in a climactic battle to save the world.
In JRPG style, my vision for EPI's plot is for the player's character (PC) to awake on a deserted beach after a (space-)shipwreck. The player will then gradually explore the island, encountering settlements (yes, I know the island is supposed to deserted), caves, dungeons, monsters, loot, and potential companions, until he realizes his only hope for escape lies in the mysterious wizard's tower at the center of the island. The game will probably end with a climactic battle at the top of the tower against the wizard (Prospero) in the middle of a raging thunderst- tempest.
Postscript: Genrebending games I like (in no particular order)
- To the Moon - an RPG with no combat.
- Terraria - a sandbox game (think Minecraft) with RPG elements
- Deus Ex - a nonlinear first-person shooter with RPG elements
- Borderlands - a first-person shooter with RPG elements
- Portal / Portal 2 - a first-person shooter with puzzles instead of shooting.
- WarCraft III / The Frozen Throne - A real-time strategy game with RPG elements.
- Feel free to suggest your own in the comments! Be sure to justify your suggestion!
EPI #2: Setting
This post is probably going to disappoint you Shakespeare nerds out there. I apologize for that. EPI is not going to be a video game adaptation of The Tempest. Shakespeare already did an excellent job of telling that story, and there's no reason for me violate it by translating it into a medium that, quite honestly, it's poorly suited to. Instead, I plan on using The Tempest as a setting.
What do I mean by this? This means that I'm much more interesting in individual characters, locations, and themes than plot details. For example, I care a lot more that Prospero is a masterminding wizard than that he's the rightful duke of Milan who shipwrecked his scheming brother on his island. Similarly, I find the fact that Prospero repeatedly dispatches Ariel to implement his plans more interesting than any of the details in those plans.
That said, I read The Tempest this morning to familiarize myself with the subject matter. Here's what I wrote down while I was reading:
What do I mean by this? This means that I'm much more interesting in individual characters, locations, and themes than plot details. For example, I care a lot more that Prospero is a masterminding wizard than that he's the rightful duke of Milan who shipwrecked his scheming brother on his island. Similarly, I find the fact that Prospero repeatedly dispatches Ariel to implement his plans more interesting than any of the details in those plans.
That said, I read The Tempest this morning to familiarize myself with the subject matter. Here's what I wrote down while I was reading:
- 1.1 - inciting incident: shipwreck; Antonio, Gonzalo, Alonso, and Sebastian irritate the crew.
- 1.2 - Prospero caused the storm. He has a "magic garment".
- 1.2 - Prospero tells Miranda his story.
- 1.2 - "Sometime I'd divide..." - Ariel
- 1.2 - Members of the ship are all scattered about the island.
- 1.2 - Caliban's mother, Sycorax (who is dead), worshipped Setebos.
- 1.2 - Ferdinand and Miranda fall in love.
- 2.1 - Characterization of Antonio, Sebastian, Gonzolo, and Adrian.
- 2.1 - A plot is hatched against Gonzolo.
- 2.2 - Trinculo and Stephano get Caliban drunk.
- 3.1 - Ferdinand and Miranda are in love.
- 3.2 - Stephano, Trinculo, and Caliban drink. Ariel messes with 'em.
- 3.3 - A banquet served by fairies. Ariel scares Alonso, Sebastian, et al.
- 4.1 - Prospero gives Miranda to Ferdinand.
- 5.1 - "Mine would, sir, were I human." - Ariel
- 5.1 - "Whether this be or not be" - those who were shipwrecked seem to be unsure what/if anything is really happening.
- I could use a shipwreck as an introduction and inciting incident.
- There could be some (powerful) items with Prospero's name attached to them. Players might have to complete out-of-the-way challenges to earn these.
- Ariel's comment about dividing might make for an interesting encounter at some point in the game.
- The fact that familiar faces are scattered around the island may provide a mechanism for pacing the game. As players explore the island, they might periodically encounter groups of characters they'd been separated from by the storm.
- Caliban, Sycorax, and Setebos may also make for interesting encounters. (Actually, I already have plans for MegaCaliban to make an appearance at some point.)
- The love story of Ferdinand and Miranda provides many possibilities. It could be a complicated sub-plot that the player participates in, or it could be a pair of NPCs named Ferdinand and Miranda who whisper sweet nothings to each other.
- The fairies and reapers offer material for a bestiary.
- Iris, Ceres, and Juno offer ideas for encounters.
- Ariel's not human. She could be a really cool robot. (Yes, I know that Ariel is male, and that Prospero addresses him as a creature "which art but air" in the next line.)
- The writing might play with themes of illusion and uncertain reality.
The general idea about working with the The Tempest as setting is to make the game experience accessible to people who aren't familiar with Shakespeare's play, and extra fun (via allusions) to everyone who is.
One final word about setting: EPI will also carry a distinctly futuristic cyberpunk flavor. There is no adequate explanation for this, and it may be a recurring joke that the characters themselves express confusion about all the advanced technology around them.
One final word about setting: EPI will also carry a distinctly futuristic cyberpunk flavor. There is no adequate explanation for this, and it may be a recurring joke that the characters themselves express confusion about all the advanced technology around them.
Monday, June 25, 2012
EPI #1: Introductions
Before I start blogging cluelessly about making games, let me make a brief introduction for myself and for my project.
About me: I'm a 22 year old web developer, straight outta college. Strictly speaking, I studied Latin in college, but I spent a lot of time writing code, too. I even wrote a whole music website once. Regardless of my academic and professional interests, I play a lot of games. And I tend to think critically about what I'm playing. This means that as I play, I think about what I enjoy, what I don't enjoy, what I find annoying, etc.; in general, how the game could be improved in a patch, expansion, or sequel. The next logical step (to me, anyways) from there is to put all my ideas in one place and actually create something.
About the project: The Tempest: Escape from Prospero's Island (henceforth abbreviated as EPI) started life today as a challenge to Facebook. I have 21 days before I start a real job at a real company, and I want to do something cool with it. I've never written any part of a game before, so hopefully I'll learn a lot and maybe even have something to show for my effort. EPI will also be challenging because I'm not particularly skilled at art, music, or fiction. In the games I like to play, these components are all as important (if not more important) than the gameplay mechanics themselves. A good game should tell a compelling story in a fun way. Players should always be excited to see, hear, read, and experience what comes next. It is my goal to make EPI a good game.
I also ought to be clear about what I mean by "write a game in 21 days". Writing a whole, complete game from scratch in 21 days is unreasonably ambitious. So, as far as EPI is concerned, "write a game in 21 days" means that I hope to have a playable release by July 16th.
Subscribe to:
Posts (Atom)