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 - 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 - 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.

Arcade Machine Madness - Part 4

The Long Road to Completion

It's all functional so that's pretty cool.  But I still have quite a bit of cosmetic work to do on the cabinet and in the Mala frontend.  There was a gaping hole between the control panel and the front part of the cab and I really didn't just want to slap another piece of wood on there to cover it up, so I found some ornate vent covers for cheap down at my local hardware store.  I cut it to fit, screwed it in and I'm really pleased with the results.

I intend to put a blue LED strip behind it to add a funky glow.  But for now, I've mainly been working on going through all of the games again, weeding out the ones that just don't work well, and building screenshots and control graphics for each game.  I don't think I fully understood how much work this would be, but I'm already up to the L's with the screenshots, so I guess there's no turning back now.

I also want to put some fake coin slots in the front of the cab.  When we disassembled it, I think we might have accidentally thrown away the originals.  Stupid, I know.  But I figured it would be easy to locate replacements online.  Turns out it's harder than I thought.  I've contacted a couple of different online vendors, but they've been less than helpful.  I'll keep searching, but for now, it looks like this.

I also had to replace the PC I was using with an old laptop I had laying around.  The original PC was starting to make a high-pitched whine that was really annoying.  Swapping it out for the laptop wasn't too bad.  I had to re-size my graphics to play nice with the odd aspect ratio of the laptop.  On the plus side, the games actually run a lot better so overall it was a win.  I hope to start reviewing these old games on my blog soon.

Done Machine is Done

Arcade Machine Madness - Part 3

Windows Dressing

It's entirely possible to run MAME without any kind of additional user interface.  It won't be pretty, and you'll need to use your mouse and keyboard to select your games, but it will work.  When envisioning how I wanted my arcade machine to function, I wanted conceal the fact that it's running on a PC (though obviously it is).  That meant making things like game selection and any commonly used MAME functions accessible through the control panel.

Fortunately there are many user customizable user interfaces that work perfectly well in conjunction with MAME.  After some research, I went with MaLa because it is extremely flexible and I would be able to expand should I want to run additional emulators on my machine.  In additional to simple game selection, MaLa can display associated material for each game however you like.  And there are tons of pre-made layouts should you want to get up and running quickly.  I elected to design my own using my somewhat limited Photoshop skills.   I knew I wanted to do some kind of spacey grid thing and that I wanted to display a screenshot of each game as well as a graphic of the controls.   After a couple of weeks of on and off work, I ended up with this:

It's functional and I'm pretty happy with it.   I decided to carry the grid theme to the control panel as well, so I whipped up a simple design which looked like this:

I figured I could print this out at Kinko's, glue it down on my panel, and then apply several coats of polycrylic. That didn't work as the printed out material bubbled and wrinkled almost immediately.  So an intense sanding job later, I was back to square one.   The answer came from Eric's work colleague who was kind enough to rework my design and print it out on a vinyl cutter.  I lost the color I was looking for, but gained a really awesome looking control panel.

For the sides of the machine, I decided to stencil some spacey designs in three colors.  So I grabbed three cans of spray paint and got to work.  I had never done this before and I think it turned out ok.

Quite pleased with the little rocket ship.

There's that grid again.

All that was left was the marquee, which is a pretty important piece.   I knew I wanted to pay homage to the arcades of yesteryear, so I named my machine after the best arcade in the greater Burlington, Vermont area.

Upton's was a fixture on lower Church Street for years. Starting out as a sandwich shop and ice cream parlor in the 40s, Upton's switched to video games in the 70s.   During the arcade heyday of the late 70s and and early 80's, Upton's was hands down the best place to play video games.  Friendly staff, well serviced machines, and new titles shipped in regularly.  As home consoles and arcades fell out of favor by the mid 80s, Upton's fell on hard times.  They move a block down the road to a cheaper location, but the writing was on the wall.   Things got grungy.  Drug dealers and riff raff settled in.  It just wasn't the place that it used to be.   But at least now I've got a little virtual piece of Upton's in my living room.

NEXT POST:  Finishing touches.

Arcade Machine Madness - Part 2

In Control

While all that cabinet prepping was going on I had to give to serious thought to how I wanted to control panel to work.  There are so many games that require special controls, I knew I wouldn't be able to building something that would cater to all the games I would like to have.  So I went with a fairly standard setup that covers most major game styles.

The Joystick and button configuration would allow for most two-player games (included standard 6-button fighting games) as well as twin stick games like Robotron and Crazy Climber.  The trackball would cover Centipede, Missile Command, and Marble Madness.   The dial would play games like Tempest and any Breakout clones.   I could have added additional dials and trackballs but the cost would go way up and I'd have to enlarge the panel past the width of the cabinet.

Driving games were pretty much a no-go as I didn't want to add a wheel.  It's technically feasible to play with the joystick or dial, but it just doesn't feel right, so I ditched it.  Other games like Tron wouldn't work that well either.  A bit of a heart-breaker as Tron is a classic, but what can you do.  And no light gun games.  Again, it's too bad but I supposed I could build another cabinet to cater to those kinds of games if I really wanted to.

I ordered all of my controller parts from Ultimarc over in the UK.  They carry lots of quality parts and the customer service has been excellent.  Joystick choices are numerous and quite frankly a bit confusing.  After some research, I settled on the Mag-Stik Plus.  It's an ingenious little controller that uses a magnet to self-center instead of springs (which are prone to wear and tear).  It also let's you switch from 4-way to 8-way directionals without having to access the underside of the panel.  This was really important to me as certain very popular games (Donkey Kong and Pac-Man) don't function well with 8-way joysticks.

As I went along ordering buttons, ball, dials, and sticks I realized that I needed to start thinking about the aesthetic look of my machine.  I knew I wanted a slightly retro arcade feel, and I was getting it into my head that I really wanted glowy blue grid lines to be a dominant feature of the artwork.   With that in mind, went with red, blue and white for the colors of the controls.  Once they arrived, I built a mock-up panel with some cheap wood to see how the controls would feel and to get some practice wiring the whole thing together.

Although it's mostly idiot-proof, I was still worried that I might screw things up.  Both the trackball and the dial plug into the computer via USB, but the sticks and buttons need to be wired to a control interface which then plugs into a free USB port.  Again, the customer service at Ultimarc is impeccable.  Instructions on how to wire this thing up and program the controls are clear and easy to follow.So I took an evening and got half the board wired.

Nasty little piece of scrap wood

I think the green light means it's working

I was pretty happy with the feel of it, and much to my surprise, it worked perfectly.  After some quick modification to the button and joystick placement, I cut another board and got to work wiring up everything.

All switches and buttons need to be connected via a ground wire.

The whole thing wired up

The top of the panel.  Not too shabby.  Needs art obviously.

NEXT POST: With the panel well underway, I now needed to dedicate some serious time to the software interface and the graphic design.

Arcade Machine Madness - Part 1

In the Beginning...

I've always wanted to have my very own arcade machine, but I don't think I could ever pick out just one game to have.  So I'd likely end up owning several machine.  The logistics of keeping them maintained seemed too much to handle.  And where the hell would I put them all?  I mean, don't want to end up like this guy.  Well, actually I DO.   But let's face it.  Unless I experience a windfall of cash, that just ain't in the cards.

But what I could do is build my very own MAME cabinet.  MAME of course stands for Multi Arcade Machine Emulator and it's just that.  It's software that runs on a standard computer that will run nearly any arcade game you can think of.   Stick the PC in a video game cabinet, toss on some fancy pants controls and boom, you've got an arcade in your living room.   After years of talking about it, I finally did it.  Hooray for me!

This isn't a "How To" post.  There are plenty of other people who have done an excellent job explaining what it takes to build one of these things.  I will say that it wasn't as hard as I thought and even though I made a ton of mistakes, I'm really happy with the results.

This is Eric

Credit must go to my friend Eric who stumbled upon some guy looking to unload a bunch of old arcade machines in his garage. Most of the stuff was junk, but there were three cabs in pretty good condition.  We got them for $15 each.

Mine was an old Rally Bike machine.  Hardly a classic.  We hauled them back to my cousin's barn.  In exchange for storing these monstrosities, we'd build a MAME machine for him as well.  We spent a good deal of time gutting the machines, cleaning them up, sanding them down, and basically getting them ready for all new parts and a fresh coat of paint.

Before the gutting

We sold most of this on eBay

Sanding revealed an interesting design.
Anyone know the story behind this?

The technical manual for the game was still
inside the cabinet

All cleaned up

Eric painted his green. *sigh*

And painted!

You suck at watching television

Dear Hardcore Gamers,

You know I love you guys.  We have had more than our fair share of laughs at the expense of the hordes of Dark Elves and Space Marines who have stood between us and our goal.  We've discussed at length the wonders of games like Shadow of the Colossus, Portal, and Civilization all the while wondering why more people; more non-gamers haven't given a care to play nor even heard of them.  I've got a fair amount of respect for you, my brethren.  But listen, there's something you need to know.  You positively suck at watching television.

I'm not saying it to be cruel. Really I'm not.  I just think that perhaps all that game playing has clouded your perspective of what other media do well.  Let's take a recent example of gamer nerd rage against a popular television series: The Walking Dead.  I'm not here to proclaim that this show is the greatest thing ever, but it's fairly obvious to any moderately intelligent consumer of TV what The Walking Dead is and what it isn't.

The Walking Dead is a character drama about a group of survivors during a zombie apocalypse.  It's about how the people on the show react when everything they know and understand it taken away.  Walking Dead is not actually about the zombies and it is most certainly not about how a group of people will devise some clever way to dispatch said zombies each and every episode.  Even the graphic novel the show is based on focuses less on the zombies themselves and more on the seemingly directionless travels of the survivors.  It's almost like the survivors are actually *GASP* the titular Walking Dead.  Their life is over.  They just don't seem to know it, yet.

It ain't rocket science people.  So why is it we have continued criticism that the show isn't delivering the requisite number of zombie encounters per episode?  Why do people scoff when the survivors don't act rationally and fail to execute a perfect set of plans?  After all, if we encountered a zombie apocalypse, we'd totally have our shit together, right?  Right?

I think what's going on here is a contingent of genre-loving nerds have forgotten that linear drama doesn't play out like a video game.  In a game, players are expected to strategize and execute their plans perfectly in order to progress.  If you fail, it's no big deal. You just start over.  By the time you've gotten well into the game, you understand the rules and the gamespace so well that you can handle anything the game throws at you.  And if the games hasn't prepared you for the challenge and you have to try to figure it out, it's called a bad game.   When a TV show doesn't prepare the characters for the challenge and they have to try to figure it out, it's called drama.

So when gamers watch a show like Walking Dead, they are first looking for concrete examples of how the world works so that they may exploit what they know in order to win the scenario.  Are the zombies slow?  Can they use tools?  Can they climb?  Hey, they weren't fast last episode, but some of them are running in this one.  THAT'S NOT FAIR!  THIS SHOW SUCKS!   Actually, it's completely fair.  Yes, TV shows need a certain amount of internal logic to function, but only so much as needed for the characters to get on with what they are doing.  Everything does not need to be spelled out for the viewers from the get go.  In fact, doing this would be considered very bad television.  The rules will be explained on a need to know basis.

Gamers also tend to dislike characters who don't behave how they would perceive themselves (as the hero of the story/game) as behaving in the same situation.   When Rick's son is shot right in front of him, his reaction is entirely believable precisely because he did not act like a strong heroic type.  He was scared and confused.  He made bad choices.  He abdicated his responsibility to the group.  You could say that up to this point, season two has been about characters who are all about following rules (Rick was a sheriff before the ZA) are learning how to live in a world where the rules no longer apply.  So when an episode or two go by with characters wrestling with these issues, that's not boring my friends, that's riveting television.  That's good character drama.  That's what TV is good at. 
Games on the other hand, are horrible at character development, but decent at plot progression.  It's no wonder gamers can't stomach all that "soap opera" stuff.  They have grow accustomed to moving from set piece to set piece with the belief that all the character stuff in between is complete rubbish.  Well, if they are talking about video games, I would be inclined to agree.  Most characterization in games IS rubbish and you're probably better off skipping whatever the hell Solid Snake is pondering in Metal Gear Solid.

But television is different.  It's those moments where characters wrestle with their reality that carry the real weight.  Yeah, it's fun when the zombies arrive and rip someone apart.   But can you imagine that happening every single episode?  Can you imagine the survivors going from place to place, mowing down hundreds of undead while scarcely muttering more than a phrase or two?  I can.  It's called Left 4 Dead and it's an amazing video game.  But it would make a horrible TV show.