Weeellllll here it is. A total of about ten hours of development, and perhaps not the cleanest code in the whole wide world, but it is done. And already I have several ideas for a sequel.
Category: Programming
Kingdom
This is the first draft of my version of one of the first video games I ever played. Variously called Kingdom or Hammurabi, it is a simple economic game. I first played it in the Impressions 5 Science Center in Lansing, Michigan. I must have been about eleven years old.
You are the ruler of a kingdom. Your duty is to acquire land and peasants. You do this by planting crops, feeding your peasants, and indulging in simple land speculation (buy low, sell high). Chaos enters the system in the form of rats eating your grain, peasants dying of plague, and variation in the price and fertility of your land. The “bushel of grain” is the standard unit of currency.
Right now the balance of values is as follows:
-Each peasant eats 20 bushels of grain a year
-It takes 2 bushels of grain to plant an acre of land
-Each acre of planted land will grow between 2 and 5 bushels of grain
-If you under-feed your peasants, they will starve to death.
If you try to spend more grain than you have, the game will simply do nothing when you click the button. And this leads me into the “to do†list for the game
-alerts which tell you when you are spending too much.
-adding logic so that each peasant can farm no more than 10 acres of land
-allowing a set number of years so the game does not continue forever
-if too many peasants die, the survivors revolt and cast you from power
I like this kind of game. It packs a nice amount of complexity into a very small package. I imagine that the idea for Warcraft grew out of something very like this.
Just Checking
Yup. We now have Flash working inside of TextPattern. This is the Crown of Jewels. It is one of the first things I did when I started learning Flash, back in 2001.
The more things change, the more they stay the same.
Tamagotchi Tutorial
In my pursuit of learning Actionscript 2.0 I am working my way through a tutorial created by the excellent and brilliant Colin Moock. To wit, I am creating a Tamagotchi.
You remember Tamagotchi. They are/were the little keychain pets which you had to feed and play with and clean up after and allow to grow and evolve and eventually go to the Land Where Tamagotchi Are Eternally Blessed. Apparently, as with all things Japanese and electronic, there is a sizable internet subculture around electronic pets. I actually found a few built in Flash including Godzilla and Charles Manson, but you can go looking for the CM one your own damn selves.
Hmmmmmm…yep.
Anyway, when I am done creating my little Tamagotchi I will post it for your Viewing Pleasure.
Playing With(in) the Rules
In Twisty Little Passages, Montfort distinguishes between three types of story or narrative: Diegetic, Hypodiegetic, and Extradiegetic (from diegesis). The 1001 Arabian Nights is useful for describing the differences: The framework story is diegetic, each of the individual stories is hypodiegetic, and the physical book itself, the paper and ink, is extradiegetic.
In the world of Interactive Fiction, Diegetic commands are those which control the “player character”. Extradiegetic (e.g. meta-) commands are those which control the game itself. Hypodiegetic commands are those which are made through the player character, and which influence other characters in the game.
Moving from Interactive Fiction out to User Interaction, we find some parallels. Using the navigation links in a website is diegetic. Using the web browser controls is extradiegetic. Perhaps using in-system tools (e.g. a price calculator or a store locator) could be considered hypodiegetic.
Someone pointed out a few years ago that web developers and usability experts, nominally working in a “new” field, could take many lessons from the video game industry, which has been working on many of these same problems for more than 30 years.
Gaming and Surfing
As I dive deeper into the theory and structure of the training courses, I realize that a lot of basic usability features of web pages and applications map closely to the features of adventure games which we consider vital and part of “good gameplay”.
Consider personal inventory. You are in a small room. You are wearing a backpack which contains a coil of rope and some food
. Compare this to any of the numerous checkout screens at Amazon.com. Your shopping cart is used in the same way: You put something in it, and while you move from page to page (room to room) the things you put in the cart stay in the cart. They are available for you to use whenever you need them.
Consider navigation. In an adventure game it is considered poor form to put the player in a room from which there is no escape. By “no escape” I mean that the player character is alive and well, but cannot backtrack and cannot go forward. The only way out is to restore a saved game or manually restart the game (play with the game rather than within the game). This is analogous to hitting a page in a website where there are no navigation elements and the only way to move to a different part of the site is to hit the web browser’s “back” button (restore a saved game) or type a new URL in the address bar (restart the game).
I am sure there are many more parallels, but these seemed to be the obvious ones.
Acronyms In My Life (AIML)
SCORM
AICC
LMS
SME
ADL
TEDS
API
Almost A Game
I took a few days off of this thing, then returned with a vengeance. The arrow keys [UP,DOWN,LEFT,RIGHT] control the direction you move. [Z] fires your gun.
The Game, Day 3
Another hour of coding and re-coding. Now we have a multi-layer background, and the enemy ships explode when shot. Left Right and [Z]. Click here to launch.
The Game, Day 2
Another hour of coding, and the .swf is up to a whopping 3.97k. Now the enemies fire back. As before, left and right arrow keys to move, [Z] to fire. Reload the web page to restart the game. Click here to launch.