GeneriQuest

Let's call this version 0.2

2010-07-26T11:55:00.000-07:00

You can pick up the sword, see it in your inventory, and drop it. Coming right along.

Adding Items

2010-07-22T10:37:00.001-07:00

I'm working on adding items, now, if anyone was wondering (not that anyone was, because nobody is reading this). I put a sword in my empty room. You can't do anything with it - not even pick it up - but it's there, which is a good start.

GeneriQuest v0.1 is done!

2010-07-13T07:31:00.000-07:00

You can walk around an empty room! Yay!!!

Note to self

2010-07-12T12:07:00.001-07:00

I came up with a great idea on Friday for solving something, and now I can't remember it. So I'll use this blog as a way to remind myself of ideas that I'm going to come back and solve later.

Anyway, Future John: create a temporary map cell object when you need to call canEnter or onEnter. Update the map with a new code if anything changes, like opening a door will change from a closed door cell to an open door cell.

Interpreter

2010-07-12T12:02:00.000-07:00

Fear not, little flock. I'm working on the interpreter now. The whole SpriteInfo / Sprite split was actually a useful learning experience for the class / object distinction that I'm working on now. Fun times.

Parser

2010-07-01T19:44:00.000-07:00

The parser is done, at least in outline form. All it can really do is "return true" or "return false" statements, but enough of the pieces are there that adding mathematical expressions, if-then-else statements, and do-while loops shouldn't be too hard. Now I'm working on writing the program that will read the game file and map files, and produce an actual, playable game. And it's only been a month!

Wow... been a while...

2010-06-28T09:55:00.000-07:00

Looks like it's been about 6 months since my last attempt. I've written basically the same sprite engine about 4 times now, and I think I've finally gotten the hang of it: I've got a SpriteInfo object that holds the sprite name, image filename, width, height, and animation sequences. The Sprite object has the x and y co-ordinates of the sprite, and the current animation sequence and frame within that sequence. I'm pretty happy with it.

What I'm not happy with is the Java Swing GUI toolkit. I guess I got spoiled with Microsoft's Visual Studio / C# combo, where making text fields and trees and grids is SUPER easy. But what I really hate about Swing is that the events are triggered in nonsense order. When you're editing in a text box, and then click on a tree, the tree node is selected first, then the text box loses focus, then the tree gains focus. Why doesn't the text box lose focus first? It's like making a scrambled egg by frying the egg, THEN breaking it open, then eating it. Ewww. So basically I have to watch every single keystroke and update my data structures every time a key is pressed in a text box. Sheesh.

Anyway, my next step is to add Map Cells, from which I will build Levels, and then I can actually start on the program that lets you play the game!

Inspiration Strikes!

2009-01-13T14:37:00.000-08:00

Hi everyone, sorry I haven't posted anything lately. I got bogged down with all the details of sprites and storage, and it kinda stopped being fun for a while, so I didn't do anything with it. But then, my wife got a call from an old friend of hers, and her husband is a game programmer. I looked at his sites (http://www.lastchancemedia.com/ and http://www.semisecretsoftware.com/), and I got all excited about games and game programming and stuff. So I'm back on the wagon! I did a bit more work on the game last night, trying to figure out how to create a Texture2D object without a GraphicsDevice object. It's not easy, lemme tell ya. But I think I got it. Oh, and I've re-vamped the boxes-within-boxes chart:
Now, the Content is separate from the Level. The Content is descriptions of the monsters, items, etc., while the Level just has the maps and locations of monsters and items. The Content was originally part of the Game; I should have known to split it when I needed two paragraphs to describe it.
I'm hoping to have a Content editor done soon; then I'll make a level editor (that will probably be the easiest, since I'm having to make up the Engine and Game as I go along to make the Content editor be able to read and write Content). The comes the Interface, and we'll have a playable game!

A Step-by-Step Guide to Making a Macro Lens for your iPhone

2009-01-06T18:34:00.001-08:00

The iPhone camera lens can't focus on very close things. This is a bummer if you downloaded a sweet bar-code recognizer application and it doesn't work. Colin Devroe published an article about a year ago with a quick overview of an idea; I tried the same thing and it works! So I thought I'd be a good netizen and make a step-by-step guide to making a macro lens for your iPhone.

Step 1: Buy a used camera from your local thrift store. Cost: $2
Step 2: Disassemble camera.
Step 3: You now have 3 lenses (on notebook) and lots of camera guts.
Step 4: Hold each lens up to the iPhone camera and see which one works best. Here's the original bar code picture, with no lens:
Here's what it looked like with the first lens:
Yeah, worse. I was a little discouraged by this. So I tried the second lens:
Much better - too good, actually. I couldn't get the entire bar code in the frame and still be in focus. Here's the final lens:
Perfect! So with a rubber band and some scotch tape, I made a thingy to keep it attached to the phone:

Pretty snazzy, eh? I tested it out on some Lysol wipes we had (note this is not a picture from the iPhone / macro lens combo, this is from our real camera):
And here's what it had to say about the bar code:
So yeah, it found it. Mission accomplished.

Overview

2009-01-02T13:06:00.001-08:00

So, I thought I'd take a minute here to step back and give y'all the big picture about how this game is going to work. I envision it in 4 main pieces:
I think it's easiest to explain top-to-bottom.
1. The User Interface (UI for short) draws the player, walls, floors, monsters, items, etc., and handles input from the keyboard and mouse.
2. The Level Content contains the maps for each level and starting locations of the monsters, so the UI knows what to draw where. It also contains the cutscene information.
3. The Game contains the rules of the game. It describes what attributes the player has; for example, you could have AD&D 2nd Edition Strength / Dexterity / Constitution / Intelligence / Wisdom / Charisma, or just Strength / Intelligence, or Fortitude / Cleverness / Wisdom / Book Smarts / Street Smarts / Holiness / Flexibilty / Agility / Nimbleness. Anything you want. You also define your combat system here, using attributes from the player and monster to come up with equations for the probabilty of a hit happening, and how much damage it does. For the first version, this will be hard-coded into the Engine, but I'll make a Game editor later on to allow for some serious customization.
You also create the monsters and items here; the difference between the Game monsters and the Level Content monsters is, the Game tells you what a Goblin is (how many hit points, how hard it hits, how much gold it has, how much exp it gives you), while the Level Content tells you where the Goblins are.
4. The Engine applies the rules in the Game to the player, monsters, items, etc.

Bear in mind that this is an RPG creator, not a general-purpose game maker. Thus, there will be certain things that will be the same in every Game:

1. The game has a Player. The Player has experience points, which are gained from killing monsters and completing quests. The Player has an inventory of Items.
2. Some Items can be worn on the head (hats / helmets), neck (necklace / amulet), body (armor / clothes), wrists (bracers), hands (gloves), fingers (rings), feet (shoes / boots). Some items can be eaten or drunk (food / potions). All items can be held and wielded as weapons, though some will be more effective than others (swords / maces).
3. Monsters try to kill the Player. Killing Monsters will give experience points. Some Monsters have items that are dropped when they are killed.
4. NPCs talk to the Player. Some are Shopkeepers that buy and sell items. Some give quests. Some don't do anything.

So that's what's been swimming around in my head since Tony asked me to make a game. Don't fret, I won't do the whole thing all at once. Like I said, the first verison will have the Game built in to the Engine, so I won't have to make a Game-maker application and all the parsers and solvers that go along with it. We'll let C# take care of that for us. For now.

XNA, eh?

2008-12-29T09:41:00.001-08:00

Ian recommended the Microsoft XNA framework for making this game. I've looked into it, and it looks like that's the way to go. Thanks, Ian! (Even though you called me Mr. Savage and made me feel old. But I guess I should get used to that, seeing as how I'm old and all.)

Update 12/18 - So Much for SpriteManager

2008-12-18T19:24:00.001-08:00

So it turns out the Sprite Manager idea was unnecessarily complicated. It made sense for the map cells to have just one instance per cell type (one wall, one grass, one dirt, etc), because they never change. Creatures, however, move around, they get hit and lose hit points, they pick up and drop items... it was just too annoying for each creature to have some sort of index key to find the image in the list of images. So now each creature will have its own sprite. It's a lot easier to code, but it just doesn't feel right to waste that memory. Even if it's only a few kilobytes.
So now that I've got memory management sorted out, it's time to start making more progress on the playable-game goal! Huzzah!!

Update 12/15/08

2008-12-15T14:41:00.000-08:00

I'm just making up this game as I go along, so expect a bit of back-tracking here and there. For example, the images that will be used for the walls.
I had a file called cellList.txt, which was just a list of the file names of the .gif files that will be used for walls, floors, water, etc. Then I realized that some cells are walk-through-able (floor, grass), while others (walls, water) aren't. So I added a "True" or "False" after each filename to indicate whether or not it was a wall.
Then I started to make another file called creatureList.txt, with a list of the file names of the .gif files that contain the monsters, player, npc's, etc. But creatures need a lot more info - attack, defense, range, hit points, etc. So I decided to put the info into an XML file instead.
Then I realized I was duplicating a lot of code between the cells and creatures, in terms of loading and saving the list of images. So I created a new class called SpriteManager, which uses a master list called "SpriteInfo.xml", with a list of ALL the image file names, what type they are, and any relevant info for that type.
I have a very rudimentary level editor:

There's not much to see at the moment because I'm in the process of creating the afore-mentioned SpriteManager, but the editor allows you to create a new level, specify the width and height, and add / remove walls. That's about it.
My next goal is to get the game into the simplest possible playable state - add a player, and let the user move him around in the level. Keep in mind, though, I'm writing this in C#, and C# was (to put it mildly) not designed for making games. The hardest part of this step will be handling the keyboard input and re-drawing the screen at the same time. Fortunately, I happen to know some voodoo magic that will allow me to do cross-thread window updating. For you techies out there, this means I can handle keyboard input in one thread, and update the window in another thread, without C# complaining about invalid cross-thread operations.

Because I'm sure Certain Persons are Anxious to Know...

2008-12-15T14:37:00.000-08:00

Hi all,
My brother Tony commissioned me to make a game for him and his friends. Since this will take a while, I thought they might like to have occasional status updates as to how things are going. And, if anyone out there is still interested in the old-school 2d sprite games, this might serve as a little tutorial for how to make one.

- John Savage