Hero Worship - Better Living Through Surfaces

Apologies for the lack of updates.  As the semester just started, I've been otherwise preoccupied. Students can be somewhat... needy.  Deservedly so.  In any event, I've continued to plug along.

I'm making decent progress on getting explorers/ soldiers into the game so the player can go on the offensive. Of course I discovered that since I don't want this to work like a traditional RTS, I needed to first work on how the player will cast spells.  Spells, which currently consume Mana (generic, I know.  Sue me!) will in part be used to suggest to the villagers places on the map to explore.  Think of it as a "Mission from God".  If anything interesting is discovered, I would hope to either have the villagers react appropriately, or perhaps give the player some more direct involvement.

Spells vs The Current Interface

But before I could get spells working, I had to rethink the interface a bit.  It was initially tied to the town center building.  Click on the town center and it brings up the build / cast interface.  Well, that's pretty stupid.  What if I have to build or cast something all the way across the map?  So I detached that functionality from the town center completely.  Click anywhere on the screen and you'll get the interface.  Move your mouse far enough away and the interface will disappear.  Click near the edge of the screen and the interface will offset so you can see the whole thing... most of the time.  There's probably a better way to make this work than what I came up with, but since I'm going to move to gamepad controls, I'll be redoing the whole thing again anyway.

Here's what it looks like now.  Active buttons highlight on mouse over and I added tooltips to explain what they do.   Standard Disclaimer about Programmer Art!!

The other thing I wanted to get working was the build distance limiter.  I decided to go with each new building extending the build area.  The logic to get it working wasn't too hard... still a quirk or two that I'll eventually work out.  But I want to make sure the player is absolutely clear where they can or cannot build.  Currently your cursor turns red when you can't build at a location.  It needed to be more obvious.  I first tried just drawing to the screen and while it worked, I kept getting strange visual errors.  I flailed around in color blending and other effects, but upon remembering someone recommending I investigate "surfaces" in game maker, I hit the websites to see if this was what would work.  And it was.

A surface is just another visual layer.  It's highly versatile, and from what I understand has low overhead.  I thought it was going to be complicated, but as I'm discovering more and more, you just need to take it one small step at a time.  Get one part working, make sure you understand what you did, and move on to the next bit.

Here's the script:

"overlay" is just a variable holding the surface I created for this task.

 surface_set_target(overlay); //need to tell GM which surface you are drawing to.
            draw_set_color(c_red);
                with(obj_buildings)//do this with all building in game
                {
                draw_set_alpha(.2);//my circles should be transparent
                draw_circle(x,y,buildRadius,false);
                draw_set_alpha(1);//set transparency back to normal
                }
            
            surface_reset_target();//done drawing to surface
            draw_surface(overlay, 0, 0);//now draw surface in the game

That's it.  It works!  See?

There's the build radius around the town center.  Note the house cursor is in red.

With a new house built, there's an additional area to put down this stoneworks building.

My little village is growing.  The workers are busy gathering wood and stone.

Hero Worship - Time + Distance = Fun?

Spent some some time doing a little housekeeping.  You know, cleaning a few things up, adding some additional feedback, etc.  Much of this was focused on the build buttons.  Now they highlight on mouseover and alpha out if a building option isn't available.  It's little stuff that will likely be tossed out when I redo the whole control scheme.  But I think it's very important to do this early and often.

I have encountered projects where things like UI and player feedback aren't really considered until the last possible minute.  Then towards the end of the project, they only take one or two passes at it, and it ends up pretty crappy.  And a players' understanding of what's going on in the game is at least as important as the game mechanics, no?

So, to recap.  I have buildings:  house, sawmill, stoneworks, watchtowers, and (now) barracks.  Workers appear from the sawmills and stoneworks, seek out the nearest resources, walk over, gather some, walk back, drop them off, and so on.  They move around obstacles, avoid enemies, and react appropriately when things don't go according to play... for the most part :)

But what about construction of the actual buildings?  In a full-on city building game, the player would select a location on the map, the little villagers would scurry about collecting the required resources from some stockpile, carry everything over, and then slowly build it. I initially thought this was what I was going to do, but before committing to a completely new set of on-screen villagers with their own set of logic, I figured it would be a good idea to think it through.

Right now, building placement is somewhat arbitrary. As long as you're not trying to place a new building on an existing one or on top of some other object, you're free to plop it down wherever you like.  It will instantly appear and begin to function.  This works but doesn't give the player that much in the way of making interesting choices. Some thought needs to be given when placing a sawmill or a stoneworks because the villagers need to travel back and forth from resource to building.  Build it too far away and your economy will be sluggish.

So what can we do about this? As I mentioned, one thing would be to have villagers travel from the town center to the build location.  That would require another villager type and I don't think I want to do that.  What happens if the build site gets attacked/destroyed? What if the villagers get ambushed on the way? What happens to the resources?  One thing I don't want to do is give the player direct control over the villagers so I can't just have them drag select some idle villagers and assign them build duty. Nor do I want the game to just generate new villagers from the town center and send them off to their doom.

No.  In the end, I implemented a build timer.  Once you place a building, your resources are committed.  The building is then slowly constructed.  It's weak in this state and if attacked it will likely be destroyed before it's completed.  I messed around with it and so far I like the delay.

But that still doesn't address the problem of where you can place your buildings.  For that I look our real-time strategy friend, StarCraft.  (Go ahead. Play it. I'll wait.)  For the uninitiated there are three playable "races" in StarCraft: Terran, Zerg, and Protoss.  Each have unique way to build their bases.  The Terrans have no build restrictions and in fact many of their buildings are mobile. That's close to what I've got now.  The Zerg can only build on an expanding carpet of "creep" that gushes forth from certain constructions.  Hmmm, interesting.  And the Protoss may only build near special "pylon" building that are designed to power everything within their radius.  Again, interesting.  It's really a pretty neat set of systems that have all kinds of advantages and ramifications for players.

For me, I'm most interested in limiting the player from instantly expanding all over the map, but requiring the player to eventually expand.  Here's where I think I'll be starting:

• Buildings need to be constructed within a certain radius of the town center.
• (Potentially) A certain type of building will provide an additional pocket of build-able area... like the Protoss pylon.  It can be built anywhere.

• (Potentially) Any building provides their own build-able radius but needs to be constructed within the radius of another building.

I still think there needs to be something more than wandering monsters to push the player back and give him something to struggle against.  I've got an idea, but that is for another post.   :)

Hero Worship - Now You See Me...

There's no fog of war in Actraiser.  You can see everything that's happening on the map at all times. I wanted to mess around with it for Hero Worship, but I've never attempted anything remotely like it before.  I could have researched the "best" solution or sent out a plea on the numerous coding forums, but sometimes it's fun figuring stuff out by yourself.  And sure enough, I came up with a working system that ain't fancy, but it does get the job done in the way I imagined.

It's really very simple.  So simple I call it the "Poor Man's Fog of War".

First, here's what I wanted:

• Monsters and enemy buildings are unseen unless a villager or village building is near.
• If monsters move further away, they become unseen.
• Once monster buildings have been "scouted" they stay visible on the map.
• Terrain is not affected by any of this.  It's always viable.

And here's what I knew how to do:

• Get nearest instance of any object or category of objects.
• Determine the distance between a monsters (or building) and any near object.
• Adjust alpha of the sprite based on distance.

And that's it.

It works the same way with enemy buildings.  In fact, the code only exists on the enemy units and structures because those are the only ones that need to know if they can be seen.  The Villager AI doesn't know or care either way.  But that's ok, because they're reaction to enemy proximity is based on their own "sight" radius.

Here's the script.  It's in the step event of the monster:

This will hold the friendly object that's closest to the monster.

var alphaMod;  

Gather our data

person = instance_nearest(x,y, obj_walkers);

personDist = distance_to_object(person);

personDist = floor(personDist);

place = instance_nearest(x,y, obj_buildings);

placeDist = distance_to_object(place);

placeDist = floor(placeDist);

This determines if it's a building or a villager.

if(personDist < placeDist) 

    {

    alphaMod = personDist;

    }

    else

    {

    alphaMod = placeDist; 

    }

Here's where it will adjust the alpha based on distance.

The formula "(alphaMod - 300)*(-.01)" makes the transition smooth.  It looks pretty neat.

    

if(alphaMod >= 300)

    {

    image_alpha = 0;

    }

else if(alphaMod < 300 && alphaMod > 201)

    {

    image_alpha = (alphaMod - 300)*(-.01);

    }

else if(alphaMod <= 200)

    {

    image_alpha = 1;

    }

The only difference between the script on the monster and the one on the monster building is an additional "Detected" boolean.  This flags true once any villager object gets within 200px of it.  If it's true, it sets the alpha to 1 and then stops checking for distances (since it's been located).

There are still some things to consider:

• If I introduce creeping corruption, should that be affected by fog of war?  Right now I think so.  If players can see the corruption spreading they will be able to figure out the location of the source and I don't think we want that.
• What about line of sight?  Mountains, forests, etc.  Should that have an effect.  I don't know how much value it will add the to the game.  The interactions aren't really about the tactics of unit position or movement.  It's more of an economic / exploration thing, so I'm going to table it unless it becomes something I absolutely have to deal with.

For now, we soldier on.

Hero Worship - Deep Thoughts

So far everything functions fine, but there's no game.  No goal, no challenge, no progression.  No meaningful choice.  In fact, it's all rather pedestrian, with me relying on tried and true concepts from other titles.  But I don't just want to make a complete knock-off of some generic strategy game. But I want to use the great Actraiser as inspiration.  And I really need to look more closely at what makes that game tick.

What the hell is an "Actraiser" anyway?

If you're not at all familiar with the game, Actraiser was a mix of god-sim and side scrolling action.  The game progression goes something like this:

It was a fairly linear game.  From what I remember, access to more difficult territories was based on your level, so your progression from one place to the next was fairly fixed.  For Hero Worship I think I'll be tossing out the progression from one land to the next in favor on a single, one map / one fight experience.  The game will begin in the town building phase and eventually end with an action phase once all requirements are met. Let's ignore the action phase for now and focus on the town.

Despite its simplicity, the sim phase in Actraiser was really pretty interesting. Let's look at what you did as a player and how I think I'm going to approach it in Hero Worship.

Here's the first map of the game.  The town starts in the center and is represented by a temple surrounded by a road.  On the outer edges of the map are monster spawn points.  As you are building your town, monsters will constantly emerge from these locations to wreak havoc.

Although the game runs in real-time, your villagers can only build once at the beginning of the day.  You can direct where they should be building. One of the goals for each map was to direct your villagers to build up their town right on a monster spawner.  Once they were close enough, they would destroy it, making the land a little safer.

As your villagers made their way around the map, they would discover special technologies (such as bridge building) that they could use to further progress.  They would also find "spells" that they would offer to you so that you could help them out as well.  With these spells you could summon rain to help crops grow or put out fires, or lighten bolts to kill enemies or clear away rock.  There was a very light puzzle-solving element involving locating these technologies and spells in each map, and using them correctly.  It important to note that the whole thing was very simple and very linear in terms of progression.

The other thing the player would do is direct the little cherub guy in the center of the screen around the map and use his (her? its?) arrows to destroy any monsters wandering around.  The villagers are completely defenseless are were prone to being kidnapped or having their houses destroyed.

Here's a quite decent let's play I found on the You Tubes.  The sim stuff comes in at around the 5 minute mark.

Once all of the spawn points were destroyed, the villagers would pinpoint the "ultimate source of EVIL" on the map and request that you come down and squash it (which is something you're all too happy to do during the action phase).

So how do I plan on keeping the spirit of Actraiser while making this game its own thing?  Here are some thoughts:

• Direct control of town building.  This is a pretty major departure from Actraiser.  But I think there's more moment-to-moment engagement to be had from the player choosing which buildings to place when and where.
• No direct villager control.  This is not a game about amassing a huge army and steamrolling over the enemy.  The villagers will react and defend.  There may be offensive units, but they will mostly act on their own.
• God powers to assist and influence.  Like Actraiser, the god spells will assist the villagers in achieving their goals. It can be direct like a lightning bolt to take out enemies or it can be a subtle suggestion to investigate an area.  I'll need an additional resource (mana, belief, etc) to cover this.
• Minion for direct control. Right now I'm thinking no.  The cherub in Actraiser worked in part because there wasn't much else for the player to do.  
• Encroaching doom.  I had been playing a lot of the excellent Creeper World 3 and I just love love love the idea of fighting against this overwhelming wave of... stuff.   My initial thought is that the spawners, in addition to creating monsters, will spread corruption around the map.  This would slow units, destroy buildings, and render resources unclaimable. God powers and perhaps a special building would be able to counter the effect.
• Destroying the monster spawners.  Same basic idea. However, in Hero Worship they will have to be discovered.   I've implemented something I call the "Poor Mans Fog of War" which I'll discuss in a later post.  Basically, these spots will remain hidden until a villager gets close to it.  Once discovered, it will be permanently visible on the map.  A discovered spawner will cause a specific building in the town to create a raiding party to travel over to the location and destroy it.
• Summoning of the Hero.  This is what will end the "sim" part of the game and begin the action phase. In Actraiser, the action phase was triggered once the location of the "Ultimate Source of EVIL" was discovered.  In Hero Worship a shrine will need to be erected at a special location on the map.  The location will be revealed by destroying the monster spawners.  The shrine itself will require massive amounts of resources to be ferried to the location. Once built, the hero (the embodiment of god) will be summoned and the action phase will begin.
• Additional villager types. A generic warrior/scout will take care of exploring and patrolling the map.  A druid will "seal" the monster spawners and build the shrine.

Obviously there are many more details to consider, but this should keep me busy.

Hero Worship - Tower Defense

With villagers running around properly and monsters happily eating them, it was time to get some kind of defensing structure working.  The answer of course was that tried and true RTS mainstay, the tower.  Really nothing fancy here.  It's a building that requires resources to construct.  It has a range and a fire rate.  Once an enemy comes into range, the tower "locks on" to it and will fire exclusively at that enemy until it's either destroyed and it moves out of range.

The bullets generated by the tower move towards the x/y coordinates passed by the tower.  They do damage on contact so depending on the speed of the bullets and/or the enemy, you can make the towers more or less accurate.

That's one way to do it.  You could also have the tower insta-hit any enemy that's been locked on so you wouldn't even need to bother with collision detection at all.  Or you could base your hit on a percent chance modified by things that "accuracy", "distance", or "armor".  All pretty easy to implement, but I wanted to see the bullets fly and it's kind of neat to see them miss every once in a while.  Just remember to kill the bullets if they don't hit anything.


curDist = distance_to_point(originX, originY);

if(curDist > 150)
    {
    with(self)
        {
        instance_destroy();
        }
    }

The biggest takeaway from getting the towers in and working was not just how easy it was.  It was how simple it was to slip it into the existing game.  I have building selection and placement set up so once I have all the sprites and objects build, I just add the new one to my "buildings array" and it just works (with minor tweaking).

Right now my buttons appear just above my town center in a straight line.  I'd like them to appear in a circle.  I'm sure there's some simple math here but I haven't stumbled upon an answer in my journeys.  It's super low priority as I think the whole selection process will be changing when I move to controller input.

With the basics in place, it's time to make it work more like a game...

Hero Worship - Here There Be Monsters (Part 2)

When we last met, our intrepid monster could successfully wander around aimlessly and eventually head towards civilization. The next bit was to get them to attack buildings and people.  It started simply, but then I quickly got lost in numerous "What if?" scenarios.

To shake the monsters out of their funk, I needed to add an instanace_nearest check for either a building or a person of any kind.  Game Maker allows you to parent objects, so I created generic "obj_building" and "obj_person" objects and childed my buildings and villages.  If there's one within a certain distance, the monster will cease wandering and start moving to attack.

The monster stuff was easy.  Once it collided with a villager or building, it would enter an attack mode, slowly depleting the hp of the collided object.  Once the hp reached 0, the object would be destroyed and the monster would seek a new target or go back to wandering. In order to achieve this, the monster has three states:

• Moving - I'm wandering around looking for stuff.
• Aggro - I've found something I don't like and I'm heading towards it.
• Attacking - I'm in combat mode.

Under a simple test with a building, it all worked perfectly.  I added a health bar to the building with the Draw event so I could track hp depletion.  Here's the code.  The numbers are placeholder until I get them all stored somewhere else:

draw_self(); // you need this so it will still draw the sprite

if(hp < MaxHp) // only show health bar if damaged
    {
    draw_set_color(c_gray);
    draw_rectangle(x-32,y-27,x+32,y-16,false); //healthbar background

    draw_set_color(c_red);
    draw_rectangle(x-30,y-25, x+(hp*6)-30, y-18,false); //healthbar: this gets smaller with less hp.
    }

Here's where it got tricky.  Villages don't stand still.  They are off doing things, so they also need to know they are being attacked (or they are in danger) under different circumstances.  At first, the villages were completely stupid.  They did not react to a monster nearby.  This lead to villagers running right into a monster already occupied.

They needed a panic mode.  The initial implementation was actually pretty simple.  If there's a monster nearby, run in the opposite direction until you are far away, then resume what you're doing. Again, instance_nearest comes to our aid.  Here's the basic script:

monster = instance_nearest(x,y,obj_monster);
monsterDist = distance_to_object(monster);

if(monsterDist < 50 && !panic)
    {
    //panic mode
    path_end(); //stop following current path
    path_delete(myPath); //delete path: you need to do this to prevent memory leaks
    myPath = path_add(); //prepare for new path.
    speed = 0; //stop moving for a moment.
    panic = true; //you are now in a state of panic

//get point to run to
    dir = point_direction(monster.x, monster.y, x, y);  // gets a vector pointing from monster to villager
    radius = random_range(dir+45, dir-45); // this helps randomize the final direction to run in.
    
    targetX = x + lengthdir_x(200,radius);
    targetY = y + lengthdir_y(200,radius);
    targetX = floor(targetX);
    targetY = floor(targetY);
    
    //check to see if it's a valid destination and then go there
    r = mp_grid_path(grid, myPath, x, y, targetX, targetY,1);

        if(r)
        {
        path_start(myPath, GameControl.villagerSpeed,0,0);
        alarm[2] = 90;
        }
        else
        {
        panic = false;  // if not valid path, setting panic to false resets this condition and it starts over again
        }
    }
 

That worked ok.  But what if the villager was heading to a resource?  What if the villager was heading back to his building?  What if the villager was actively gathering resources?  All of these things need to be accounted for.  I already had variables I was tracking to cover these possibilities.  Here are the ones for the lumberjack:

• onTree - I'm busy chopping down a tree.  At first I just made it so the villager would not run away.  But what if the villager finished chopping before the monster is done killing him?  He starts walking away, but the monster remains frozen in place because he hasn't completed his task.  So I also made the villager stop gathering.
• myTree - The holds the instance_id of the tree to be chopped.  Zero means it's not an instance_id and any other number means it's an instance_id.  Now I know which path I need to create if the lumberjack leaves panic mode.  If it's zero, create a path back to the sawmill.  If it's any other number, create a path to that instance.

But what if the sawmill is destroyed by a monster?  What do the lumberjacks do?  It depends. Are there other sawmills?  Was the lumberjack already headed to that destination?  My solution was this:

The lumberjack does an initial check for the existence of any sawmill (and then the nearest one) and then goes there.  If no sawmill exists, the town center becomes the destination.  When the lumberjack reaches the town center, the wood is deposited, and the lumberjack disappears.

If the lumberjack is already heading back to a sawmill, there is a check that happens every couple of seconds to see if it's still there.  If it's not, recalculate a path based nearest sawmill or town center.

All of this took a lot more time than I expected, but at this point it all works.  Monsters and villagers swarm around doing what they should all on their own.

Hero Worship - Here There Be Monsters (Part 1)

What if?

What if? What if? What if? What if? What if?

That quickly became my mantra.

When implementing any kind of enemy behavior, simple or no, you wind up asking yourself "What if?" a lot.

And not just "What if?".  You have to think about a lot of things.  I'm always reminded of Liz England's excellent The Door Problem on what game designers actually do all day. There's just a lot of stuff to consider.  And when one small part of it doesn't work, it all comes crashing down.

In coming up with behavior for my generic monster type I had two basic states in mind:

1. The monster had to wander around the map in a seemingly aimless manner, yet also slowly make his way towards the village.
2. When close to a villager or building, go destroy it.

Wandering Monsters

For the first state, I already had some experience with this very behavior from my game Truffle Shuffle. (WARNING: doesn't work in Win8 for some reason...)   In it, the trippy shroom clouds float around the level and eventually make their way to your base to damage it.  The logic is pretty simple.  For 80 percent of the time, the cloud will choose a random direction to move.  The other 20 percent has the cloud moving towards the base.

With that as my starting place I created a case statement to fire off every 2 seconds or so.  It has three states:  wander aimlessly, head to the town center, and go idle.  The idea here is to give a sense that the monsters are just doing their thing, and yet they will eventually force a confrontation with the player.  I can tweak the percentages to get more or less aggressive monster types.  Right not the idle state doesn't appear to do much, but when animations are in, they could growl, look about, scratch an itch, etc.

The resulting behavior is pretty good.  I set the time interval  between changing states to be based on distance traveled (which is assigned through a random_range).  This way the monster doesn't walk the same distance each time.

Random distance and direction is accomplished by picking a point on a circle of a random size around the monster.  Here's the script:

//move in a random direction.

point = irandom(360);

radius = random_range(50,100);

radius = floor(radius);

targetX = x + lengthdir_x(radius,point);

targetY = y + lengthdir_y(radius,point);

targetX = floor(targetX);

targetY = floor(targetY);

//check to make sure destination is within the room boundaries.

if(targetX>0 && targetX<room_width && targetY>0 && targetY<room_height)

    {

    moving = true;

    move_towards_point(targetX, targetY, GameControl.monsterSpeed);

    }

    else

    {

    event_user(0); //not a valid destination.  Try again!

    }

There's a conditional in the step event (AKA the update function for your non Game Maker people) that checks to see of you've reached the destination and re-fires the case statement to give the monster new orders:

if(moving)

    {

    dist = point_distance(x,y,targetX,targetY); 

    if(dist < 5)

        {

        moving = false;

        speed = 0;

        event_user(0);

        }

    }

This all came together pretty fast.  I should have known the other part would be far more complicated.

What if? What if? What if? ...

Hero Worship - Village People

What's a village without people?  Unlike Actraiser I want the villagers to actually walk around and do stuff. In Actraiser, you would occasionally see people walking around and tending to things, but it was all window dressing.  There was no simulation beyond the how upgraded your houses were (and even that happened automatically).

So in borrowing a huge chunk from Real-Time strategy games like Age of Empires I present to you, the humble lumberjack and his buddy the stonemason.

These guys emerge from their buildings, find resources, gather them, and return.  It's pretty simple behavior, but presented a couple of interesting puzzles to solve.  Both of these guys work the same way, so for the purposes of examples, lets just talk about the lumberjack.

The obvious thing to do here would be to make the lumberjack find and go to the nearest tree.  That's all well and good, and thanks to "instance_nearest" in Game Maker, it's a piece of cake to implement.  But what if you have several lumberjacks.  They will all go after the same tree.  The game would still function correctly, but it would look silly.  I want them to spread out, with each lumberjack finding his own tree to chop down.

There are several ways to possibly do this.  I had been reading up on a couple of features in Game Maker. Specifically Instance Ids which are unique identifiers for each instance in your game, and the funky way Game Maker handles functions.  Basically what I did was have the lumberjack find the nearest tree and find the instance id of the tree.  When the lumberjack and the tree collide, it checks against the instance id and if it's the right tree, it starts gathering the resource.  Almost all of this information is packaged up and sent to an external script to be implement with the results being returned to the lumberjack object, or stonemason object, or any other villager that needs to collect something. Super re-usable.  When the lumberjack is full, it heads back to the building and conveniently forgets the tree. More on why in a later post.

This still didn't solve the problem of all the lumberjacks going to the same nearby tree.  I could have created a Boolean variable in the tree object and flip it when it was "taken" by a lumberjack.  But then in order to get the NEXT nearest tree, I'd have to loop through all the trees in the room and check each one.  I'm lazy and didn't want to write that much code so I had a tree object (obj_tree) that was tagged by an incoming lumberjack swapped out for an different, but identical looking tree object (obj_treeC).  That way, the next time a lumberjack looks for the nearest tree, it finds a different one.  This also fixed some weird collision issues I was having because the lumberjacks now only check to see if they are colliding with obj_treeC objects.

The final bit was to implement some kind of pathfinding so the villagers wouldn't get stuck on impassable objects like buildings, mountains, and whatever else ends up in the game.  Game Maker has several solutions.  I first attempted to use the "dumb" pathing which just redirects a moving object if it bumps into something (kind of like a Roomba vacuum).  That mostly worked but they would still get stuck on occasion. That's when I discovered that Game Maker has the A* pathfinding algorithm build right in.

I thought it would be difficult to implement, but the documentation is excellent.  The pathing grid is set up at the beginning of the game.  Before any village moves it checks and creates a path to the goal and then goes on its merry way.  All of this is done in a script that's called from any villager objects in the game whenever they need a new path.  When a new building is plopped down, it's location is added as "impassable" to the pathing grid.  Then a message is sent out to all the villages to recalculate their path based on this new information.  The result is villagers dynamically altering their paths when necessary.

I felt pretty pleased with my progress and with myself.

Then I added monsters...

Hero Worship - It takes a village

I've been knocking around a game idea for a while and finally started messing around with it in prototype form.  It's a love letter to one of my favorite games from the 90s.  The genre-busting SNES classic, Actraiser.  God what a weird and wonderful game.  It took elements of city building and mixed it up with side scrolling action.

See??   City Building AND Side Scrolling action!!




In reality, the city building part, while fun was quite anemic.  All you really needed to do was hold the enemies at bay while your villagers slowly built up their town until they reached a point where you could move onto the next part of the game.  You could help them with magic spells and by loosely directing their build efforts, but it never really required much thought.

So I figured it would be fun to make the city building part a little more deep while still retaining some of the things that made the original so interesting.  More on that in a later post. For now I wanted to get some basic city building concepts up and running.  And that starts with the humble village.  I'm using Game Maker Studio because it's quick, easy, and I really like it.

I already knew this was going to be more complicated than I originally thought, but having no preconceived notions about what I would be able to accomplish has been strangely liberating.  I love city building games and have played tons of them, so I just started taking bits and pieces of different ones just to see if I could get them to work right.  Honestly?  So far, so good.

The story so far

Disclaimer.  This is all programmer art. blah blah blah.

It all begins with a Town Center.  In Actraiser there was a temple where each "sim" level in the game began.  I don't remember if you could lose it (because I don't think I even lost those levels) but in Hero Worship, losing your Town Center will mark the end of the game.  From the Town Center you can build your basic buildings, currently: houses, sawmills, and stonewerks.   Already this is a major departure from Actraiser.  You never actually built anything in your game.  You only controlled the direction of development on the map.

The blue squares are to check collision.

I was able to quickly rough up a working selection and placement system and well as push scrolling for the game map which is several times larger than the screen. I really think I want this whole thing to be playable with a game pad (even though right now it's mouse only).  I have some ideas on how it's going to work, but for now, I plan on avoiding using common control paradigms like "right-click to cancel".  This immediately presented me with a problem.  What if the player selects something accidentally and needs to back out?  For the Town Center I implemented a proximity check.  If you selected the town center by accident, once you move your cursor far enough away, it automatically deselects.  This is in line with how people generally behave when they do something wrong.  They try to move away from the problem.

So at this point I've got four buildings, a way to place them in the world, and the basic checks to make sure where you are attempting to place them is valid.  My first pass at resources goes something like this:

Currently there is population, wood, and stone.

Town Center:

• Placed automatically at the beginning of the game.
• Give a maximum population of 5.
• Population will increment slowly up to max.
• Allows building of Houses, Sawmill, and Stonewerks.

House:

• Cost 5 population.
• Increases max population by 5.
• Slight increase in population increment rate.

Sawmill:

• Cost 10 population.
• Generates 5 lumberjacks over time.

Stonewerks:

• Cost 10 population.
• Generates 5 masons over time.

The problem with Interactive Hyper Narrative

What's the problem with Hyper Narrative in an interactive space?  I'll tell you what he problem is.  It's a great big pain in the ass. That's what the problem is.  I also chose to explore this for my Thesis in Emergent Media. This is what I've been spending the last number of months working on.  I knew it was going to be difficult and I think I'm raising more questions than answering them. Here's a little background for the uninitiated.

I'm currently building a short story that's meant to be read multiple times.  You can read all the way to the end of the story, making choices along the way and come to a (hopefully) satisfying conclusion. If you re-read the story and make different choices you will come away with a more complete picture of the events that transpired.  Nothing earth shattering here.

Where I'm trying to push things is through the notion that the choices you make as you are reading will unknowingly shift the story from one track to another, and that the protagonist appears to be the same person in the same world experiencing a different reality of events.  Where on one track the protagonist is a high-functioning success, another version is struggling. To further complicate matters, it's possible to meet your other selves and through that discover that you all have the same agenda. Ok, it's a little weird, but I'm hoping it at least comes together as an interesting experiment.

I'm a little over half-way done and what I've learned so far should have been obvious to me.  Academically, I knew this was going to be difficult.  Writing one decent story is hard enough.  Writing three at once is clearly more complicated.  Weaving them together so the reader can jump around and still follow what's going on leads to vomit inducing headaches.

To that end, I've come up with a few rules for myself to keep the project on track and in scope:

1. No Dead Ends - The story continues to move forward.  There are no choices that lead to a premature and unsatisfactory ending to the story.
2. As an extension to rule #1, time must continue to move forward. This is a departure from more traditional forms of Interactive Fiction where the player could move back and forth between areas as much as he or she wants.  In this format the story would only progress when the player did the right combination of actions (like finding the key that unlocks a door). This has led to some trouble making sure the choices presented are interesting.
3. If the reader jumps to a different track, the story can and should reference what the reader (and the protagonist) knows from the other track. This is extremely hard to do and difficult to keep track of, but I think it has added a lot of flavor to the story.  In Inklewriter, the tool I'm using to build this, tracking variables is fairly simple and highlights a major difference between Hyper Narrative and something you would experience in a Choose Your Own Adventure book.
4. Keep It Short - The interactive nature suggests that choices need to come quickly and regularly.  Too much time reading the prose tends to encourage the reader to skip ahead to the choice.

I don't yet know how all of this is going to pan out.  And now that I'm in the thick of it, it has become very hard to show my progress as anyone reading through it will see less than 1/3 of what I've actually produced and won't have a full picture.  I can only hope that once it's done it will make sense.  I think it will.

Creativity on a schedule

Many moons ago when I was producing pithy 3 minute packages for Television News Magazine shows, my workflow went something like this:

• Assemble crew and gather footage / interviews on location.
• Review footage, write script, and choose relevant material for the next day's edit.
• Have no idea how I was going to direct the edit.
• Put everything out of my mind, go home, sleep.
• Wake up the next morning and know exactly what I was going to do for the edit.
• Walk into the edit suite with a large cup of coffee a bust out a great package in 6 hours.

It was automatic and it worked every single time.  You would think that by now I'd have my creative workflow figured out.  I've worked on creative deadlines all my life and it's never been a problem.  Until now.

My thesis has turned into one hell of a bear to wrassle with. It's an exercise in creative writing and pegging down a multi-threaded narrative.  I have direction or at least I'm pretty sure I know where I'm going with it.  But the actual act of sitting down and writing is proving to be far more difficult than I had originally anticipated.

At first I thought it was a case of working some creaky old muscles I haven't worked in year.  And even through I think the writing is coming along (or a least improving incrementally) it's the act of just sitting down and engaging in a session that's just not getting any easier.

15 years I was younger and had fewer personal responsibilities.  I look back on it now and can't fathom how much free time I had.  And I think that's the crux of my issue.  I need moments of quiet reflection to get my head in the space to process what I need to do and put me in a position to execute. These days I have precious little time.  I have my job which demands the lion's share of the attention day to day.  I have kids.  I have adult responsibilities with adult worries.

Occasionally I get a burst of inspiration and if I'm able I rush over to the nearest computer and can get a fair amount of work done.  Most of the time, though, it's like pulling teeth.  So what's the solution here?  I need to get this done.  I'm making progress, but not as much as I would like.  And it's honestly not a good as I'd like it to be.  Still, IT HAS TO GET DONE.

I suppose I need to make peace with the process and use whatever creative juices dribble out.  And when there's nothing there, just solider on and do the best I can.