Development Log: January Engine - Week 3

I took a break from working on the battle system to make an overworld map system.  I think that by working on both sections at once, I can bounce between them when inspiration strikes, and if I'm stuck on one I can just go back to the other for a while.

Colors!

Currently, the navigation system works as a grid where the player (the "P")  can move through empty spaces, but not into spaces with "X"s in them.  You use the arrow keys to move.

Ridiculous sidenote:  I wanted the player to be able to also use WASD controls, but there is something weird going on with keyboard commands in Flash recently, and it's not limited to just this.  It may be a Chrome bug or a Flash bug in general, but I find that whenever I play a Flash game, a host of problems occur when I try to use the letter keys, from the program thinking I'm holding down the button when I let go, to it thinking every key I press is the same key as the first I pressed, to the opposite problem where a single key changes to a new keycode every time I press it (so I press "wwww" and it comes out as "wert" etc.).  This nasty bug happens with every Flash program I use, so it basically makes WASD controls untestable, so I decided to just throw them away until Flash or Chrome or whatever the problem is fixes itself.  When this gets fixed, I will quickly add WASD controls to the engine.

Walking into an enemy (the things labeled "E1") causes a battle to occur.  When either the enemy or the player loses all their health, the battle ends.  (There is no game over screen yet, so even if the player loses, the player actually wins.)  Then the game goes back to the overworld, and the enemy is beaten.

The player can also move through the path to the left and end up on another screen.  The map system works kind of like the original Legend of Zelda, without the fancy scrolling.

And without the fancy... everything.

One bug to keep in mind is that the flash player needs to get the focus, so you need to click on the screen before you can use the arrow keys.  And for some crazy reason, you have to click every time you shift from one map to the next, which is a bug I'm still trying to figure out.

As for the coding itself:

I discovered the Vector data type, which is an Array of only one data type, while an Array can hold many data types.  Besides being more convoluted to declare, the Vector is less computationally intensive, I would have to guess, so most of the things I made as Arrays have been switched to Vectors.

Each individual map is a Vector of Strings, which gets created into the visual grid when the player moves into it.

To figure out which map to load as the player moves between them, I made a Vector of Vectors, which holds the smaller maps in order so I can just reference them by their location in the overall map.

I've got a few tasks to do for next week, including making the enemies move randomly around the map (or even follow the player to attack), making a game over condition, and fix a few battle bugs.  But the fun task that I'm looking forward to is making some NPCs with dialogue boxes that pop up when the player approaches.

PLAY WEEK 3 HERE.

Deconstruction: MYST - Part VI: Getting to the Mechanical Age

From this point, the Player has the option of visiting the four other ages in any order, so a linear discussion of what the average player experiences breaks down from here until all four ages are solved and the climax unfolds back on MYST island.

I used to watch this all day.  Weee!

Some players might rotate the tower to get a view of the most interesting object on the island (whatever it may be for them), others might save the most intriguing for last, or come up with some other line of reasoning to generate an order to their adventure.

For this, I'll be going simply by order of which object is locked onto first as the tower rotates, which is the gears.

So, supposing the player chooses the gears, then goes up the tower and gets a small view of the gears.  Heading to the other side, the player will notice a plaque with the vague clues:

Credit where credit is due, lparchive.org has a great little walkthru with many of these pics.

Here (or at the first puzzle to any of the ages, in fact), the player will learn that much of the island is interconnected.  The first number appears to be a time, and the only object on the island that allows the player to control the time is the clock tower.

Naturally, clock towers are full of gears.  Hopefully the player will catch the theme, and instead of heading for the gears, will instead head for the clock tower.

When the player changes the time to 2:40, gears from the ocean will emerge, allowing the player to cross (and while they're at it, flip the final marker switch for kicks).

The clock puzzle basically gives the player the answer in the rotating tower, but it is the understanding of where to use the code that is the true puzzle.

This kind of puzzle, where the answer cannot be guessed or figured out, but rather given, is often the building block to many terrible "Escape the Room" games, a subgenre of Adventure.  It is unfortunate that so many of these games don't provide the challenge of these puzzles, because instead of having to figure out where to input the code, even that is obvious.

Possibly the inspiration for "Saw".

In this particular puzzle, the answer is also fairly obvious considering the format (a time), but other tower clues (such as the one to reach the Selenitic Age) are not so intuitively understood.

Once the player enters the clock tower, s/he is met with the second puzzle, a puzzle of gears and levers, and it is here the player will probably understand that the three numbers in the tower clue are the solution to this puzzle, simply because the gears are demanding three numbers.

Trial and error teaches the player the controls, and eventually the player figures out how to get to the solution.  This puzzle is more of a traditional puzzle, in that it is self-contained and the player may feel as though they are "stuck" on one screen until it is solved.

Two puzzles in a row; of two completely different kinds, and they appear at the opposite end of the island than the player intended to go.

Yet, when the second puzzle is solved, a display gear in the clock tower mimics what the larger gear outside by the dock is actually doing.  The player may understand this, or may need to explore and find their way back to the gear to discover that the miniature is a copy of the actual.

Miniatures or facsimiles representing larger objects is a common theme in MYST, and after understanding one, the player will probably realize the theme and understand intuitively from then on.

Makes you wonder if earth is just a ship in the birdbath of space.

Once the player hightails back to the large gears, s/he will find the book to the Mechanical Age.  The player may come to understand Atrus' message now about how the books are hidden in "places of protection."  Certainly, solving two puzzles on the wrong side of the island, plus understanding the rotating tower is plenty of protection.

The player views a flyby of the Mechanical Age, similar to the one from opening the MYST book at the beginning of the game.  If the player has read the journals in the library, the fortress should look familiar, and the player may pause to revisit that journal and take notes.  Otherwise (or afterward), the player will plunge into it, and explore a new island.

The player may expect from the journal entries that these other ages will be populated, since Atrus discusses interactions with natives in his journals.

The player will be disappointed.  And later horrified.

Read Part VII: The Mechanical Age

Development Log: January Engine - Week 2

Well, not much appears to have been done on the surface, because I spent the majority of the week cleaning code and making it smoother.

And the cards are shaped like cards.

Now, the enemy can do everything the player can do, and uses the same functions.  A simple Boolean keeps track of whether it's the player's turn or not.

I also created a separate message box (in the bottom-right) for most text.  The text above the health of the player and enemy are there mostly to show what their current condition is (stunned, confused, etc.).

I think some of the messages still go unseen because I don't have enough timers to wait between messages, so there still needs a bit of work to be done in figuring out exactly where the timers are needed.

I have also capped each character's health (at 10 for the test), so neither the player nor the enemy can heal above their max.

At the moment, the enemy chooses a card at random, which can result in the enemy doing some very silly moves, so eventually I'll have to come up with some AI for the enemy so they don't act so dumb.  They should act as if they have a five-card hand as well, and pick the best card for their situation.

The battle ends when one character loses their health, but since there is no overworld to go back to, it simply ends, and erases everything after a second.  I need to add a pretty win statement in the message box, but at the moment, have no fear when the screen goes away; it's not broken.

I currently have the win/loss check on ENTER_FRAME, but I think there ought to be a better way to do it, such as only when a character takes damage, but the win condition check is in Main, not in the Battle class itself, so things might get a little convoluted for a while.

I am finding I have to reference strings multiple times, and that always makes me a bit uncomfortable.  Often, a case will throw out an error because of a typo or change in vocabulary that I did not completely implement.

The "Confused" condition adds a secondary case (since if you're confused, either your move doesn't work or affects the opposite of the target), so I'm thinking of getting rid of it, just to simplify things a ton.  Besides, while confusing the enemy is fun, being confused is not, and I want all player actions to be playable by the enemy as well.

I've also added some code to make sure the player doesn't have duplicate cards (an odd recursive check ensures that the index of the card in the deck array is not the same as any other card in hand).

I think I had a non-recursive function originally, which lowered the odds of having duplicate cards, but did not wholly take care of the problem.  Now there should be no duplicates.  (The player may have more than one of the same type of card, because there is often more than one of each card in the deck, but since the player only has one Confuse card, for instance, the player should never get two of them in hand).

I think I may still have an error or two in the logic, because being stunned appears to last way too long (unless the enemy is stunning me multiple times, and the output is not particularly clear).  I have an int that keeps track of how many turns a character has been in a condition which -=1 each turn.

Man, I feel like I need to write daily notes, rather than summing up a week, because I forget what I've done since last week.

PLAY WEEK 2 HERE.

Article: The Importance of Design

I have often heard it said that "anyone can design" and that the jobs that require skill in videogames are art and programming.

Well, this is true to the point that if anyone can design, then anyone can draw stick figures and anyone can program "Hello World".

Trace("Hello World!") // Game complete!

Because design is such an abstract field, people think it must be easy, or of no consequence, and I see many companies want combo Artist-Designers or Programmer-Designers.  If you can do both, or even all three, all the more power to you, but you're even more difficult to come by and most people will put one of those disciplines before the others.  Often, design falls by the wayside.

Sometimes a programmer with a great knowledge of how systems works can design a mechanically interesting game, or an artist with a grand vision can design a very cinematic game.  However, designers -- who primarily call themselves designers -- with some knowledge of the other two fields, can produce games that are both mechanically interesting and cinematic, and much more.

To discover the true importance of a designer, look no further than a wholly designed game -- games which do not rely on art or programming at all.  Scratch out anything digital to get rid of programmers, and scratch out board games or other toys to get rid of artists.

So consider some children's games, like hide-and-seek or tag.  These are purely designed games.  The rules are simple and children, on the fly, create the boundaries their game takes place in, be it the house, or the backyard, or the neighborhood.

Reminds me of "Lord of the Flies" for some reason.

But these games are ancient, and no one knows their origin.  They've been time-tested and are very successful.  So let's look at a terribly-designed game.

Icebreakers.  Icebreakers suck.

Ever been in a new group, and someone wants to play an icebreaker?  An icebreaker is when people play a game to learn about each other, such as "Two Truths and a Lie" or other such games.

There are a few standard icebreakers, but many times, the leader of the group will invent a new game wholecloth, and it is never fun.

The reason these games suck is because they are made up in a moment by someone with no experience in design.  They take was "sounds good" and expect it to be fun.

Designing fun is not as simple as "that sounds good".  Designing any sort of experience is not that simple.

Ultimately, every work of art and entertainment is trying to make an emotional or intellectual appeal.  And when the objective is intellectual, the player must still be emotionally invested or interested in order to want to think about it.

Ever read a scary story that wasn't scary?  Watched a comedy that wasn't funny?  Didn't care whodunnit?  Fell asleep before the world was saved?  Walked by a painting with barely a glance?

I don't think you're supposed to nod off at this part.

These are all failures of emotion; that is, the writer, director, painter, or whoever is in charge of the artwork did not grab you and make you emotionally invested in their work.

And the designer's primary task in designing a videogame is figuring out how to evoke a particular reaction from the player, whether it be a fright, an adrenaline rush, a laugh, or simply a sense of fun, of having a good time.

Artists in videogames help to achieve this, of course, as videogames are a collaborative medium, but a great designer has this as a primary task, not a secondary one.  The designer may start with "this sounds good", but then works the idea like dough until something great comes out, or throws the idea away and tries again.

Designers understand how to create the moment-to-moment experience.  Level designers, mechanic designers, and writers come together and create the experience from beginning to end.  Indeed, design is so complex it is further broken down into subtypes!  Can someone who is primarily a different field design something that stands as a work of art and entertainment?

Sure, some people can, but they are the Da Vincis of game development.  Most of us stick to a single discipline and work to perfect that.  Those who split their effort between multiple disciplines risk making bad games.

Development Log: January Engine - Week 1

I have now created a simple card-based battle system.  The pretty pictures and epic music score comes later.  Also, the descriptions on the cards word-wrapping.  Details, details.

And the cards should probably be card-shaped.

Anyway, the player is given a starter deck of forty cards, and is dealt a new hand of five random cards every turn.  The player can choose among them what to play simply by clicking on them.  The odds of drawing some cards are very high (a card dealing two damage is 3/10) and others are very low (Confuse is 1/40).

I have currently created the most basic variety of RPG moves:

Simple damage

Heal self

Confuse

Stun

Block

All of these work (I think), except that Stun is a tad buggy (the enemy stays stunned unless you Confuse or Block).

Also, Block may appear to be ineffective, but Block only blocks one damage point, so if the enemy deals two or three damage, the player still takes some damage (normal damage - 1 for blocking).  Only if the enemy deals one damage does the player completely block the attack.

Sometimes you can't see what's blocking you.

(I'm sure that the system is horribly imbalanced and doesn't give particularly good feedback, but that doesn't matter at the moment.  Details, details.)

The enemy is also given a deck of cards and chooses randomly among them.  However, for this simple battle, the enemy can only do direct damage.  I will later add the same functions for the enemy (or clean my code and make the player and enemy functions one and the same).

Also, the player cannot see the card the enemy has chosen, and at present I am not sure if I want the player to actually see it, or just feel its effect.  I may play with that idea and decide what is best.

There is currently no win condition, and both the player and the enemy's health can go below zero, and it is next on my agenda to make victory and loss conditions.

As for the work done, I found it a small challenge getting back into the swing of coding AS3.  While I began with reservations about how much I would remember, much of it came back to me quickly.  Code is just like learning a foreign language:  when you have to use it after you've forgotten it, you remember more than you think you do.

English on the left, AS3 on the right.

But for problems with coding:

I am always annoyed at adding event listeners, because the function you put in as a parameter cannot have its own parameters (or if it can, I am not sure how to do it).

To get over this, I created a class called Battle which acts as a manager for the battle, not only holding various functions such as dealing cards, etc, but also holding variables which could not otherwise be passed.

The creation of timers to delay messages were similarly handled.

I've considered recreating my own versions of these built-in functions to fix that, but at the moment I'll take the path of least resistance and just walk around the mountain, rather than climb up it.  It may become necessary in the future to do so, but for the moment, as long as I am getting basic functionality, I'll worry about cleaning my code later.

PLAY WEEK 1 HERE.

(If the screen is magically green when you try to play, just refresh and that should fix it.  I think it's a Google Chrome bug but I'm not sure.  Other browsers may or may not have this problem.)

Deconstruction: MYST - Part V: The Library

While seeking out marker switches, the player may have entered the library; if not, the player will do so from later exploration, finding mostly dead ends everywhere else (interactive objects like the planetarium viewfinder appear to be pointless at this point).

"Everything is broken on this piece of $#*% island!"

If the player has not flipped any marker switches, they will find the map on the wall to be interesting, but useless for such a small island.  If the player has flipped all the marker switches it is possible to reach (the one by the clock tower is currently unreachable), then they would surely touch the blinking icon and intuitively understand that the tower is turning based on the grinding sound; the player would also notice the hitch and that the line turns red when it lands on some icons.

The player may not necessarily make the conclusion that the marker switches are connected to the interactive map, if no switches have been flipped, or if all have been.  However, if the player, on exploration, flipped a few switches, but not all, they are more likely to realize what the marker switches are for, and will flip the rest of them.

The fireplace will appear to be a strange dead end, similar to the generator room or planetarium.

However, the player will come to understand the blue and red books quickly, finding static without the nearby page placed within, and less static with it, revealing Sirrus and Achenar.  It seems clear that the men trapped inside need pages of their respective color to lessen the static and talk without interruption, at the very least.  Sirrus is calm, while Achenar is desperate, but they both urge for pages.

"We gotcher red pages, yer blue pages, whatcha need?"

The player may come to the conclusion that the brothers are trapped in those books, and need pages to get out, but it is somewhat more likely that the player will think that the books are more like videophones, at least for now, since those books do not offer flybys (as static-filled as they might be) like the book of MYST did.

In any case, Sirrus and Achenar need the player's help, yet Atrus just warned that one of them (probably Achenar, he claims) burned most of his books.  It certainly seems that Achenar is the crazier of the two.  The player may consider helping Sirrus, but he seems a little too relaxed, and keeps the door open for suspicion.

Besides the prison books, the main shelves of the library hold the books Atrus mentioned, most burned badly.  A few did survive, and they become easily identifiable by their pristine spines.

The player may read these and find them fascinating, as well as note the clues for later puzzle-solving, or the player may find them boring and think "I don't want to read when I play a game."

Now, this secondary type of player will be completely weeded out by this point, if they have not given up previously.  These four unburned books are keys to accessing nearly the entire game.

Oftentimes, in RPGs, there are big blocks of text in the gameworld, tomes the player can read for no more than background information about the world.  They are mostly flavor text, while pertinent or necessary information is mostly found in cutscenes, small pieces of text, or other non-readable format.  In MYST, the solutions to puzzles are found in diagrams in these books, not in the text itself, but even so, an impatient player would be deterred.

I think Atrus doesn't know how to write sheet music.

However, the text of these books does what it can to be entertaining apart from the content, giving mystery and intrigue that encourage the player to read them.  The journal for Channelwood, for instance, has ink in multiple colors.  The text for the Selenitic journal disappears.

The final pieces of interest in the library are the paintings, which, when touched, open and close a secret passageway behind the bookshelves.  The passage leads to the tower, which Atrus previously mentioned rotates.

Upon entering the tower, the player will explore and discover a clue opposite the window, and it is here that the player will discover the first 'real' puzzle of the game.

Read Part VI: Getting to the Mechanical Age

Development Log: January Engine - Week 0

I enjoy a good turn-based, top-down, NES-style RPG, so I've decided to create my own RPG engine that takes that classic experience style and mixes things up a bit.  Or a lot.

This menu business is the first to go.

First, I will be taking a look at the battle system, as that is the heart of gameplay in an RPG.  I've decided to dispense with the menu-driven battle system, but keep the turn-based nature of old RPGs.

So I've come up with a simpler solution: make the battle system feel more like a CCG.  Instead of normal attacks, magic, or items, the player has a deck of cards, and randomly draws five cards each turn, and picks from them.

This card battle system also dispenses with MP, a notion that always seemed silly to me.

While this limits the player's options, it makes the interface simpler.  All the player has to do is select their card of choice, and all five are displayed up front, so there is no digging through menus.

Once the basic battle system is in place, I will move on to other aspects of RPGs, taking things one at a time, until a full engine is in place that can be used to make a small sample RPG that uses each function of the engine.

So next week you'll see how far I've come to creating the battle system, and you'll get to play what I have.  There won't be much in one week, of course, but the basic (placeholder) interface will probably be done, if not the functionality.

Three months in...

So I've got two new updates this month.

First, you may have already noticed that articles and deconstructions now have pictures.  I went back through all the old ones and added some pictures, and new articles and deconstructions will have pictures as well.  This is just to break up the monotony of walls of text and make the site look a little more casual.

Second, I'm working on a new project, which means a new development log.  This one is a flash game.  Every week I'll be posting a dev log, and I'll also be posting a new version of the game so you can play my progress, rather than just read about it.  You'll see more details about the game itself in the first development log coming out this Thursday.