PsySal

10:58 am - Detour: World Design

Been awhile since I posted. Here is a juicy screenshot, it's the courtyard in the real world:



I have made a probable mistake, or rather meta-mistake in the design process! It turns out that I need an alternate world, these are little areas of the castle that you visit to obtain certain items. I decided to create this world "realistically", that is, in parallel with the real world. I carefully positioned the doors to this alternate dimension close together, so this area would not be too large, but alas it's really a large large amount of level design.

Anyhow that's what I've been doing for the last six weeks, really. A bit of a detour, to be sure, but it will work out alright in the end. And I have to admit, it's pretty fun crafting levels/items/objects using this game engine and my now-solid skills with it.

10:32 am - The Blue Door

Well, it took some searching but I found the story design docs I did that I need to progress. I'll worry about the player/enemy interaction issues that I wrote about yesterday later on; it will make more sense in the context of a greater overarching story sequence, anyhow.

The first stage in implementing this story is to put in the "blue doors". These represent your links to the real, real world, and also play into the system of upgrading your guns, so once they are in I will probably put the system in place that you need in order to get your guns. There won't be much in the way of obstacles to do this, but I can at least put the basic sequences in that you have to walk through in order to get your weapons. This represents effectively the backbone of gameplay progression.

08:40 pm - Next phase: story! And player/enemy interaction issues...

It's time to move into the implementation of the story. I plan on taking what I have, which is sort of a rough outline, and implementing it-- a rough sketch of the overall gameplay but without too much in the way of actual constraints. So the events/places/items/etc. will be laid out something like how they need to be in the final draft, but without worrying about constraints just yet.

So, if the gameplay graph is a requirements graph with nodes and lines between them indicating requirements (i.e., "to get to Y you need X") then the first step is just to put the nodes in without worry to connections. Interestingly, this is the same approach I have taken with enemy AI. Draw a graph of the enemy's behaviour, and then implement each state, then worry about the transitions separately. Works smashingly!

On the technical side of things, I'm starting to run into some trouble with the player interaction model. Essentially, drones (enemies) could "take control" of the player; for instance, a mummy drags the player underground, so to do this, we freeze the players control and then the mummy AI takes over. This works, but only to a point, since what happens if two mummy's want to grab control? Or worse yet, what if a story element takes place?

My idea is that this control scheme has to be transferred onto the actual player. So the player becomes it's own state array, with transitions in between states. This isn't perfect; I think that the individual AI states will need to have a "default" behaviour. Imagine if there is a player.set_state_dragdown () method, which causes the player to be dragged underground. This will return true if it was possible to transition to this state, or false if it wasn't. The mummy needs to call set_state_dragdown () when he wants to drag the player underground, but also needs to respond to the true/false conditions.

This is probably the cleanest solution to this particular problem, and not difficult to implement and keep organized. Since the enemies already have a broad range of effects they can carry out on the player, it's important to keep these all in one place where the relationships and transitions between them can be carefully analyzed, rather than spread out ad-hoc over all the enemy AI routines.

10:40 am - The Creative Ebb

So my creativity is ebbing. This is simply due to a massive outpouring over the past 3 weeks or so, where I've implemented to great success some "enemies" for Texas. The latest enemy has required much more concerted effort, not due to any inherent difficulty but simply that that internal life force that drives this for me is spent a little bit; it will simply need to recharge. Nonetheless I'll discuss one design element that can help bring clarity.

A game can be player-oriented, or world-oriented. In a player-oriented game, everything that happens is oriented around the player, and the concept of the world existing autonomously is an illusion created by the clever game designer. In a world-oriented game, the player is just another actor in the world and the world itself operates according to complex rules of economics.

The important realization for me today is that a player-oriented world is infinitely easier to develop than a world-oriented game. Just as an example, it's far easier to build an enemy who targets just the player, than it is an enemy who can target anything. This was a mistake I made with the last enemy which has proved a roadblock and will have to be reworked. All other enemies are player-oriented, but this one I made world-oriented. What happens is very quickly I have to start implementing systems to define rules in a much more general sense between non-player objects. What a nightmare!

And not just as overhead for implementing one enemy, but a design nightmare in general that the prudent indie game developer should stay far, far away from. Will I take my own advice?

11:02 am - New Enemies

So I've been really doing a great job coding up enemies, and plan to just keep on doing this until I absolutely run out of ideas. I am almost done the salamander, which is a fun little critter, and I just thought of where I want to head next: a floateye.

I made this game a long time ago, called Floateye, which was really fun. Anyhow my idea is to have these giant floating eyes with tendrils coming off them (I can reuse my tentacle code) that they shoot at you. The shots don't do anything other than push you back/impede your movement. However they might not quite be killable. Here's my idea:

- they float around, with "dumb" pathfinding, chasing after anything in particular (not just the player, but even other floateyes; whatever comes close)

- they shoot something, launching a barrage of tentacle-shots at the target, each of which moves the target back a little bit.

- when they run out of tentacle shots, they sort of float around peacefully.

- every so often they decide if they want to attack something nearby; this will happen if T seconds have elapsed since the last decision, and if something is close. the more tentacles they have grown, the more likely they will attack.

- the drone itself will handle the modeling of tentacles, so that the eye can animate smoothly (this is a technical note I guess)

- you can kill them with enough ammo, maybe they turn into rocks though when you do which impede your path?

10:52 am - Notres for Salamander

/* notres for salamander:

- draws a pentagram in fire
- splits into two
- vanishes except tail (trick death)
- leaves tail when it really does die
- turns your head into a pumpkin

ANOTHER idea:

- player gets tired, zzzs appear, starts to stumble and fall asleep

*/

01:53 pm - New Enemy Ideas

I have a few ideas for new enemies, which lurk in the caves:

- A "gel" enemy that is like the slimes in U6. This enemy sort of spreads amorphously around, slowly creeping across the ground. It would be neat and jelly-like, maybe spitting acid at you unexpectedly.

- A cave pirate. The idea here is that a sword would fly in from off-screen and make a thungggg-ggg-gg-gg... sound, then the pirate would swing in dramatically on a rope and begin swashbuckling with you.

- A grabber plant. This would your basic, see a spot appear on the ground, move away from it because something is gonna grab you from there sort of enemy.

- A rat, and/or a snake. Actually the snake could be called "niblet" and it would be like nibbles.bas (i.e., worm) and crawl around eating numbers and growing, that would pretty awesome.

Here is a site with more ideas for me: http://www.enchantedlearning.com/biomes/cave/terrestrial.shtml

- I like the idea of salamanders, even just as scenery. Even raccoons could be fun, they could run up, swipe something from you, and run off again.

- Eyeless shrimp, and blind crayfish could work well in the damp underwater lake section. Everybody loves marine life. I can't imagine any really interesting patterns for these, though.

- A lake tentacle would be a nice addition, it would rise up out of the lake and smash you down.

04:45 pm - Awesomest Sound Effects Ever

The "combat" side of gameplay in Texas is much more tactical than for instance Zelda. You don't so much have HP and collect hearts as you slog through many enemies. Instead you have to try and maneuver through tricky situations. One nice offset of this is that I can get a little bit hilarious with the enemy AI. So for instance, a bear doesn't just sort of half-assedly nip and you. Oh no. It roars, and when it roars, you shiver, and can't move. Then it jumps on you, and proceeds to maul you, blood spattering everywhere. It's completely hilarious!

And bats, well, the bats are so funny I am not even going to describe them.

The icing on the cake though, is the sound effects. I've discovered there is nothing so amusing as a pleasant "chomp" sound effect to coordinate with an animal biting your avatar. There is something inherently funny and a bit visceral (in a good way) about getting bitten by an animal!

09:43 am - Bats!

Bears are in, but in caves there must also be bats. My idea with bats, is that they will swoop you and possibly latch on. The latch-on lasts a few seconds and slows you down, but also makes it more likely for other bats to latch on. If you ever end up with too many bats latched on, you die!

Bears turned out *just grandly*, so I'm excited for bats, today.

10:23 am - Bats 'n Rats

I'm putting in bats, and rats. Something basically to populate the caves. What else lives in caves? Maybe a bear? Hmm... I think a bear would be very exciting!

01:30 pm - Sheep!

Michelle says that my game needs sheep, and I agree. So I've added them. Other than that, there are now cows and I'm filling in some more terrain; there were still some areas that were pretty blank-ish. That's all for now!

09:26 am - Renderables, Soundables...

I discovered that I have an ugly inconsitency in how the sound effects are getting played.

First of all, there ought to be an analogy for the structure used for drawing things (which I call renderables) and those for sounding things (lets call them soundables). These are differentiated from the graphics and audio engines, in that they operate on a more abstract level. The graphics engine for texas is OpenGL, and the audio engine is Aurex (something I made). The whole infrastructure supporting "renderables" is well worked out, but not so for soundables.

At first I tried combining renderables and soundables. This actually makes a great deal of sense, since the interface is basically identical.

Let's define a RenderPass as a function from a particular range RenderState to OpenGL. RenderState contains certain information like where the camera is positioned, and so forth; in fact we can include whatever we want (e.g., is it raining, should everything be blue, etc.) A Renderable, then, is just a class that has a RenderPass (RenderState) function, and an Update (T) function. Mathematically, maybe this is something like a function (RenderPass, T) |-> RenderPass; I don't know.

A SoundPass should be then a function from SoundState to Aurex. Likewise a Soundable would fit the above description and be a class with an Update (T) and Sound () function, where the sound function puts the sound into Aurex.

In fact, due to the nature of sound (we specify a certain duration of sound, not a static sound for a single frame) we actually need a slightly different model. Only the Update (T) function is neccesary, but it should also have access to SoundState; so it's really an Update (SoundState, T) function.

In the case of Renderables, we really want everything to be in C++. There are just a whole lot of OpenGL calls each frame, and a lot of sorting out to do in terms of what to draw. But in the case of Soundables, we really don't need that; it's sufficient to have it in Lua because on a given frame there will probably not even be one call to Aurex; during the majority of frames there is no sound starting or changing information (and in fact Aurex could not handle this many voices anyhow).

The solution, then, is to build the abstract-level sound infrastructure in Lua and save myself the work that would be building it in C++. Of course, as a caveat, this only handles "gameplay" sounds, interface sound effects are handled in a straightforward way already.

11:48 am - Enemies, AI Rethinking...

I've put in a few enemies now: there is a ghost-type enemy, and a mummy/zombie type enemy that both haunt the graveyard. The combat system is awesome and I'm really into the swing of it. I think it will be quite fun!

In VtV I used an AI system similar to the one I'm using now, with a key difference. In VtV there was a distinction between an "AI Instance" and an "AI Pattern". Instances were a collection of variables; i.e., hit points, physics information, associated visuals, and eventually this grew to sort of an ugly structure. Patterns themselves were just a tree-like structure which represented different time-evolving changes to this structure; e.g., there was a pattern for flying from one location to another (this was the most complicated one), another for facing towards the player, another one that let me build up state-machines, etc.

It seemed neccesary to have the Instance structure; just imagine if one pattern is responsible for regenerating HP and another pattern is responsible for making a choice based on total HP. They both need to reference the same variable.

And yet, not every AI pattern cares about every variable! This is even true of for instance physics or visuals information, since some Patterns are responsible for spawning enemies but themselves aren't an enemy. Worse, I had to create sort of an Instance-level variable scope which was nasty to deal with. Even worse, since each Pattern had it's own local state, the AI state was now spread between the flat, shared Instance structure shared by all relevent patterns and the Pattern itself. And this was all in C++, ugh!

In Texas, there is no Instance information (almost; I did something a bit wierd with NPCs that could/should/probably won't get fixed). Instead, as the AI is structured into multiple layers, each layer that needs to reference some kind of shared value just asks for that in it's constructor. So in the above example, both the HP-regenerator and the HP-decider Patterns would ask for a shared "HP" variable that they would then reference. Anything that wanted to make use of these patterns would then have to appropriately supply the reference to the appropriate variable, which is just logical consistance.

This is all very lovely, makes great sense. The Instance and Pattern model only really makes sense if the Patterns are actually just flat, i.e., Instance becomes the parent structure that determines based only on it's own state what AI routines should run, rather than a shared kernel of information between Patterns.

12:25 pm - Bandits for the win!

I've added bandits, which move around and shoot you. I'll probably upgrade their behaviour to include also "peaceful" behaviour; i.e., they might be sitting in the grass smoking cigarettes until you get near, or they should sleep at night, or even at random hours, or just stand around staring at stuff. At any rate, it's good for now.

I feel I've gained some real momentum over the past week or two. Today I'm adding some more enemies, a ghost that latches on to you and probably a zombie/mummy cross enemy that follows you with it's arms out (it will be the only enemy with arms, if indeed I decide to give it arms) and takes a lot of hits to kill.

03:31 pm - Golden Rule of Adding Moving Gameplay Elements

So eventually you're going to have to put in moving/walking/talking elements of various varieties in most any game. Maybe they are lemmings. Maybe they are AI controlled bot opponents in an FPS. Or maybe they are soldiers in an RTS, or enemies in a hack and slash. In any case it's daunting to add these gameplay elements because the behaviour will ultimately require so much tweaking and experimentation. Where do you start?

Carefully creating a system for managing/handling such creatures is... somewhat uninspiring work. And worse, what kind of result do you get? Did you end up forgetting some crucial detail, or do you get a very complex, neural-net-enhanced AI that just acts stoopid? Good luck!

When you see your little guys moving around, only then do you start to see what practical changes you can make to their behaviour. It doesn't mean you can't have larger scale frameworks in place, it's just that even with these frameworks (e.g., pathfinding) it's not too obvious how to code the heuristics until you are into.

This brings me to my Golden Rule of Adding Moving Gameplay Elements:

First, just add something that stands still and you can zap.

Of course, "zap" might stand for anything. Maybe zap means clicking an RTS unit. Or talking to an NPC. But your first implementation should not worry about movement or anything. It should just create the actual unit, place it. You can start to work out your enemy placement/spawning system at this point, or start to think about how they will behave. But either way, what you really need before you can get started on any practical level is to get it placed. And in order to do that most easily, just forget everything else that will have to go into it for the time being.

I would do well to remember this in the future. This way of thinking avoids me spending all kinds of time mulling over millions of options without anything to start experimenting with. With a purely dumb element placed, purely dumbly, I am able to start the kind of wheedling experimentation neccesary to make it work.

09:04 am - Causal Chains and Snowfall

In searching for game-design tools (in the abstract sense) I came across this:

http://www.theoryoffun.com/grammar/gdc2005.htm

There are a lot of neat ideas in this presentation, the one that has helped me the most is something I'm adapting. Rather than describe gameplay in a linear fashion, we can describe it in terms of causal chains. So we define an objective, and then figure out what sub-objectives there are beneath it:

[Win Soccer Game]
   [Score Goals]
      [Shoot At Net]
         [Move Ball Down Field]
            [Pass]
            [Run]
            [Deke Out Opponents]
         [Protect Ball Carrier]
      [Deke Out Goalie]
   [Don't Get Scored On]
      [Don't Let Opponent Get A Shot]
         [Defend Against Area Around Net]
         [Steal Ball]
      [Screen Opponents Shot]
         [Position Player Near Net]
            [Run]
      [Goalie Makes A Save]
         [Position Goalie Between Attacker And Net]
            [Run]
         [Jump]

10:41 am - Fun as a Survival Skill; Sound effects, item system.

I've begun to add sound effects. Mainly, effects are in place for walking on terrain, as well as for certain menus. I have adapted the sound engine from Venture the Void, which is called "Aurex". I should GPL it sometime, because it's a very clean, well-thought-out engine for game sound effects that integrates well with SDL.

The system is in place for picking up and carrying things, as well as dropping things. It required a bit of mathematical thinking in terms of what it means for an item to be on an area, vs. dropped by the player, but I think it's worked out.

Next I am going to create a document, "elements", in which I will try to create a plan for weaving the gameplay elements together into a fun fabric. I don't want to base gameplay too much on the crutch of existing systems, but at the same time I'd like to develop something resembling a scientific approach to evaluating whether they are fun. The model for fun I will use will be based on the idea of play as an exercise for real human survival. So when trying to decide if something is fun, I will think about whether it's exercising (or emulating, as this is a role-playing universe) a survival skill. That might be a weird way of looking at it, but that's the most convincing explaination of fun that I've read yet!

09:14 am - January Slowdown

Work (where I earn moneys) has been really busy this year, plus there is a usual slowdown after holidays. Takes some getting used to life's rhythm in order to do indie game dev, because if life gets a bit chaotic the dev is usually the first thing to go. Anyways! That said I'm battoning down a little bit and getting to work:

This morning I'm finishing putting the carry/drop system in. Then you'll be able to carry certain objects around, and also drop items onto the ground as well. Some objects can fit in your pack (these are "items") and of these you can have up to 9. However, other ones you must carry in your hands, and when you are carrying them you must holster your gun.

The other thing I recently did, which wasn't on a list, was add a bottom edge to the terrain. Since the world is sort of divided into "blocks" or "screens", there is an edge on every area beyond which is just sky. It's a nice way of organizing the world for the player, something we miss in modern games. But there is a "bottom edge" that used to show up ugly, so I added basically a flat "side" so it looks like it's been chopped with a butcher's knife of terrain generation:

11:03 am - Time for Gameplay

I tend to like to build setting for a game, first. I sort of see it as being a question of setting, and gameplay. Often, the setting is built around gameplay elements as in the case of a game like Zelda: The Wind Waker's dungeons. Those dungeons have lots of puzzles that require clever gameplay solutions, but tend to be structured very deliberately around those puzzles. So each room consecutively builds on the previous rooms gameplay discoveries. It's fun, but not neccesarily what I want. I'd rather have an evocative setting and work gameplay in cleverly, so that you feel like you're exploring an organic world that exists outside of your character.

That said, I have for the most part the setting for the game completed. So now it's a question of putting in gameplay elements. I have a good idea for where to head. First, I will implement basic item collection and shooting. After that I'll look at the whole "carry" mechanic, which lets you carry one large item (but you can't shoot if you are carrying).

What will you end up shooting? I'm not sure, but I bet rabbits and frogs and stuff. Maybe you will get coins for shooting them, or pelts or something?

10:07 am - Setting and the Altar of the Evil Pig

What we have here is a donjon that is lived in!

Games these days often have a functional setting. Buildings are often layed out not first as buildings, but as levels. The net result is that the player doesn't become terribly interested in the setting, but is just focused on getting from point A to point B.

In some ways, this makes sense. We don't want to bore the user with endless corridors, or too-regular level designs. At the same time, there is something to be said for creating a world that feels like it has a backstory to it, that is inhabited by other creatures and not just created for the player's sake.

I tend to create the setting first, and then put the gameplay into it. Besides having a general idea for gameplay elements I might like to create, my goal is to try and create a setting that should support the kinds of ideas I already have for my game, without being too specific. So the "room where you use the mirror to reflect the beam of sunlight onto the idol to unlock the chamber housing the serpentine gauntlet" is not a great place to start; rather, I try to think about what interesting places there might be to visit in a certain area. In The Real Texas, there is a mine. Abandoned mines are about as unique an idea for a videogame setting as haunted castles, granted, so it hasn't a chance of flying on it's own. Some notable videogame mines:

• Donkey Kong Country had mine cart levels where you race in mine carts. Fun, and much-copied! Ultimately not very interesting though; also generally speaking I hate this game.


• Narshe in Final Fantasy 3. This was a great opening setting for the game, since there was something interesting discovered in the back of the mine. The town itself was constructed around the mine in a way that was very interesting and believable.


• Illusion of Gaia had one paradise town, Freejia, which had a dark underbelly; nearby was a mine where slaves were kept prisoner, and lizards with chain whips were around. You had to free the slaves and kill the lizards. IOG had a really evocative feel overall; every area felt completely strange and interesting. This was a great game, and sits in the middle of a little-known trilogy of games, the other two being Soul Blazer and Terranigma (both fabulous games, too). Kevin you should play Terranigma after you play SD3 (you are right now playing SD2 =)


• Ultima 7 had blackrock mines, which were pretty interesting. There was lots of mining equipment laying around, and even some NPCs working in them. Best of all, you could get the mightily explosive blackrock in them!