EPI #7: Maps, part 1

Three days, zero showers later, and I'm back in business!  And just in time, too, because I was about to run out of clean clothes.  Hygiene jokes aside, I did indeed manage to work through the power outage.

I've made it pretty clear thus far in the blog that I believe maps are a major component of RPGs.  It should come as no surprise to anyone, then, that I chose maps as a starting point for writing code.  I chose to build off the classes I outlined last time and write a class for rendering maps to the screen.

However, before I started writing code, I needed a way to describe the maps that will eventually become my input.  XML is a natural choice for what I'm trying to do, since it is both human- and machine-readable.  Although a more complicated scheme might lead to performance or space optimizations, I have no interest in pursuing one since it would just be harder to make sense of while debugging.  Also, I'm not operating under any particular performance or space constraints.

An XML map specification consists of three main parts: the tileset description, the map data, and any special events that apply to the map.  There's also a tag for a default location, which is where the map places any characters who aren't explicitly given a coordinate location.  XML for a simple map might look like this:


<map name='my_map'>
     <default x='1' y='1' />
     <tileset res_x='32' res_y='32'>
          <tile id='0' passability='0'>./content/test/tiles/test_0.png</tile>
          <tile id='1' passability='1'>./content/test/tiles/test_1.png</tile>
     </tileset>
     <data>
          <row>1,1,1,1,1,1</row>
          <row>1,0,0,0,0,1</row>
          <row>1,0,1,1,0,1</row>
          <row>1,0,1,1,0,1</row>
          <row>1,0,0,0,0,1</row>
          <row>1,1,1,1,0,1</row>
     </data>
     <special x='0' y='2'>GO TO my_map_2</special>
</map>


This is pretty straightforward.  The res_x and res_y attributes of the tileset element indicate the x and y resolutions of all the tiles therein.  A Map has exactly one tileset, and all tiles must share the same resolution.  The tiles do not, however, have to be square.  A tile element has id and passability attributes, and also specifies a file path.  I explained how passability works in a previous post, I'll get to id later when I talk about the data element, and the path identifies the location of the tile's image relative to the engine script.  Ids must be integers.  The data element consists of one or more rows, which each contain comma-separated tile ids.  Computerized color-by-numbers is a really good way to think of this.  The tileset section tells the engine which "colors" (really, images) go with which numbers, and the data section tells the computer what pattern to arrange them in.  Each row has to be the same size, but the map doesn't have to be square.  Finally, each special element identifies a (zero-indexed) map coordinate and specifies an special effect that happens there.  These are basically stubs at this point, since I haven't fleshed out the special effects system yet.

Two related thoughts come immediately to mind about this schema.  First, it's really easy for humans to read.  It makes intuitive sense.  Second, the data section is going to be an enormous pain in the ass to create by hand for maps that are tens or hundreds of rows or columns large.  This is probably a good time to mention that, although an editor application would be relatively straightforward to implement, I don't have any plans to write one right now.  My hands are full enough with game engine as it is.

One nice thing about XML is that since it's all text-based, which means it compresses really well.  One optimization I might be able to make to the engine later could be to enable it to deal directly with compressed files, thus reducing the size of scenarios.

Speaking of scenarios, this is only one part.  I haven't finalized the scenario hierarchy yet, but my thinking so far runs like so:  The root scenario directory, .../scenario_name, contains exactly one global.xml file, which describes various universal properties of the scenario, and many subdirectories, one for each distinct map in the scenario.  scenario_name/map_subdirectory will contain a map specification (which I described in this post), as well as NPC, item, and monster specifications, a subdirectory for audio resources (such as music and sound effects), and a subdirectory for graphical resources.

EPI #6.5: Unplanned Posting Hiatus

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.)

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:

• 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.

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:

• 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.

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)

• 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:

• 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.

These notes help me do two things.  First, they help me internalize my source material in an abstract and intuitive way.  Second, they help me identify details about The Tempest I (might) want to work into the game.  Several examples:

• 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.