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.