Category Archives: Game Development

Overworld Madness

I’ve had some pretty great results so far with generating my terrain and dynamically placing road decals as needed.  The Easy Decal 3D solution ended up being pretty great.  The folk at &u Assets were super-helpful, and with clever use of their baking and decal combine features my roads went from 20 fps to 200 fps.  So, basically solved, and it’s worked out pretty well for putting interesting terrain features when staring down at splat-mapped Unity terrain starts to get tiresome.

I feel pretty good about the look and feel of my overworld, as well as the scale (which was a concern since it’s extremely exaggerated, even though I wanted a gritty feel).  I still have a ways to go before I can finish up my core loop and release a build, but things have leveled up a fair amount.

Overworld Development

I know it’s been a while since I’ve updated, but there hasn’t been a lot going on that’s particularly showable.  My Perforce checkins show that in the past few months I have…

  • AutoHomeChar08132016Used a landscape generation tool called Gaia to generate custom baked landscapes that I can use for specific locales or pre-constructed sections of the overworld.
  • Created a home base area for the player to start in.
  • Project movement grid information on the ground to help navigate some areas.  I’ll still work on making sure that they are clearly traversable.
  • Added charRavennaacters from Fuse in there, using some of the pretty good tools to grab some animations and basic clothing setups.
  • Enlisted the help of my wife Sandra to help get some characters together!  Nice being able to construct characters as easily as you would in a game like Skyrim.  And so far it’s free (knock on wood).
  • I’m still considering how I want to show characters in general.  I liked having them when I had a 2D game because it was easy to see what everybody was, but by going 3D I’m going to have some trouble with parseability.  I’m already scaling things up larger-than-life, but even more might be needed for humans.

AutoQuest08132016

  • Got together some basic quest granting, as well as a main stats screen for players to track the quests they’re on.
  • I also realized that I probably didn’t want a traditional quest system…  I’m not out to make Wasteland 3 or anything.  So, I’ve got the system but I’ll be working on evolving it to work even better with generated content.
  • AutoOverworld08132016Started thinking harder about the overworld experience.  There’s a lot of back and forth that happened here…  very briefly I thought about creating only one overworld zone and generating only content within.  However, performance considerations, as well as the interesting gameplay that can happen in the overworld, I decided to break it into sectors that include both generated and prebuilt areas.
  • Started to move towards the exaggerated scale I want to hit with chunky buildings and roads, but areas on the map with interesting states to deal with.

AutoDecalTest

  • Experimented with a number of ways to put roads on a generated terrain mesh, and so far have settled on Easy Decal 3D, which is a bit quirky but that’s pretty standard with Unity asset bundles.  I think it has a good set of features and make it run performant, if I can just work around some of the funky bits.
  • I’m hoping this approach will work.  It is the most dynamic, and would hold up best for generated terrain, but it’s also eaten a good chunk out of my frame rate and needs optimization.

This is all on top of investigation, data loading/saving, performance, and other things.  Hmm.  So yeah, I guess I was actually pretty busy over July.  Still hoping to get back to working on city combat stuff soon.

Auto Fire: Skid Marks

After a couple of evenings over the last couple days, I got skid marks working fairly well.  I had considered it a fluff component, but I also knew in my gut that skid marks could fairly easily show the player where a vehicle came from and whether it is under control or not.

Drawing arbitrary skid marks on the fly!

Generating mesh polygons on the fly in Unity was a new experience, but it wasn’t so bad.  The odd thing is that I spent an unnecessary amount of time trolling the docs and forums for info on supporting quads, and whether I’d have to define things in strips and fans and all that.  Instead Unity just asked for every triangle defined individually, and shared edges were not even an option.  I guess it’s been a long time since I had to deal with individual polygons, and the graphics layer has become just that much more sophisticated.  Does that make me a 90’s Voodoo/TNT relic?

Besides, I’m dealing with maybe 50-100 polygons here, so I’m hardly taxing the system…

Auto Fire: Technical Debt

As I am gainfully employed, my time working on AutoFire is mostly relegated to mornings before work plus weekends.  I don’t have any pretty pictures for you from this past week because I’ve been ripping out the guts of the game, getting it into a smoother-running and more manageable shape.

You wouldn't believe the number of pictures with stick figures holding up the word "debt" there are.
The internet contains precisely 51,245,721 stick figures holding up the word “debt”.

In programming there is a phenomenon commonly referred to as “technical debt”.  In short, it means if you take shortcuts  and the “easy way” for quick results, you usually pay the price down the road.  Those temporary fixes and band-aids that you applied in lieu of carefully planning and documenting your work gets built upon again and again…  Eventually that foundation of toothpicks and dried spit can’t bear the weight, and you realize that your work cannot be maintained.  You throw up your hands and say “This has to be completely redone!” This is the day your technical debt comes due.

In game development technical debt is common…  Early in a project you want to prototype all the gameplay quickly to give everyone a sense of how something works.  You try things, you iterate on an idea to make it better, you try to “fail quickly”…  You do all those things that the best game companies hold up as their credo, which means you have to focus on speed and agility.  Try that crazy new control scheme, add a strategy component to your FPS, see what all the goats look like with hats, or whatever the team comes up with.  This behavior does not encourage proper architecture, and often involves what a programmer calls “a hack”.

BUUUUUT game making also is a business, and there is always pressure to move forward because the last problem is in the rear-view mirror…  This comes from folks like producers and publishers, but isn’t just about the folks in ties and suits:  a lot of people on the team can get antsy if they don’t see new things on a weekly basis, because morale is everything in a creative endeavor.  Programmers get tremendous pressure to move on to the next big issue, and frequently they will warn the powers that be of the technical debt that is being accrued.

Of course, when the day comes that the debt must be paid off, it will involve days and days (sometimes weeks!) of time when nothing changes… in fact, the goal of this cleanup is that everything should work identically as when you started.  It’s very hard for an outsider to understand…  One day long ago I witnessed a manager straight-up ask “But can’t you just hack the entire game?”  No… not if you want something that won’t fall apart when thousands of eyeballs and eager mouse clicks are set upon it.

Nonetheless, “hack the entire game” is precisely what the 7DRL is about…  You need results now and you don’t apologize for it later.  You’ve got 168 hours to get to the finish line and you don’t care if you trample over every “Write Smarter Code” author who ever was.  And I certainly did that.

It's finally time to ditch the last of those 2D pixel art sprites...
Now I finally have time to ditch the last of those 2D pixel art sprites!

For AutoFire my control and world update system was my cross to bear…  I piled my inputs and the control of my entities in Unity’s “Update” system, where each object gets called every frame.  I cobbled together some bullshit traffic-cop system to move things in the right order, except Unity plays it pretty fast and loose…  There isn’t really a great way to guarantee that, say, the function that tells a car where to go would run before the function that actually moves it.  Frankly, I started to not fully understand how the damn thing worked at all.

I knew the debt was coming due…  Players didn’t always feel their commands were registered.  10% of the time the smooth movement of an entity would inexplicably twitch.  The enemy vehicles just spontaneously stopped working.  But I knew fixing it would be a slog, which is why I procrastinated by working on some pretty terrain last weekend instead of doing what I should have been doing.

When you have to rewrite someone else’s code, you can get pretty grumpy about that person.  But when you have to rewrite your own code, you decide that months-ago you was either an idiot or a complete dick.  “What was I thinking?” gets uttered out loud several times, as well as “What the crap is this?” and the classic “How the hell did this ever work?!?”

But a week later and all is well.  The code to control everything is about 25% of its original size.  Everything is carefully managed.  Your input is now queued up and doled out to your vehicle on demand.  Now I can get back to the fun part of making things blow up.

Oculus Rift: Weekend Puttering Part 2

I borrrowed the Oculus from work again this weekend and put just a few hours in…  This time I experimented with setting up targets and creating a mechanic where the player can move slowly to new locations by pointing and right-clicking.  Overall it seemed like a worthwhile experiment…  Actually the motion was some of the best part.  I think perhaps just a constantly orbiting viewpoint could work all right, with maybe a few choices as to where to move next.

The goal is to create motion and control that won’t make my wife sick…  Have yet to put her in it, but it might just work.

Oculus Rift: Weekend Puttering Part 1

My company (Hidden Path) was kind enough to let me borrow one of their Oculus Rift DK2s over the weekend to do some experimentation.

I got it working in Unity pretty quickly, and proceeded to experiment with a stationary camera position with a mouse-aim cursor.  After a couple of experiments, I ended up with a model where the cursor points at a single point in 3D space, manipulated by the mouse.  If the player’s view moves away from the cursor, the cursor gets “dragged” with it.  It felt pretty good and snappy in the end.

I also did a simple dumb character using WASD controls, with motion relative to the viewer (ala Mario). That part was easy and I can see the appeal (although with my test sprite character it’s a bit lacking of course).  It was fun to mess around with!

Dungeonmans has shipped!

Hey, did I mention that my buddy Jim Shepard has finally finished his epic, Dungeonmans, and it is fully purchasable on Steam?

He’s done such an amazing job…  I spent a few weeks helping out a little on traps when I was awaiting a move to San Francisco back in 2010, and it was the very thing that made me realize how much I had missed game coding.  I can’t lay any claim at all to the final product because probably 1% of the code I wrote back then made it into the final product, but it was a meaningful moment to me nonetheless.

Back in November, Jim and his long-distance contributors/friends decided to gather in Seattle for a week-long push to get Dungeonmans that much closer to the finish line.  I put in a day or two (as a designer this time) and helped create a couple of “master dungeons”, and it was amazing to see how much the game had improved over time.

dungeonmans old-new
From the early days…                                                       …to release!

 

The coolest part was having an honest-to-god game studio, Adventurepro, in my basement for a week!  These are amazing guys, each with years and years of grizzled veteranmancy (a word I just crafted now) behind them…  They deserve every new success.

Dungeonmans crew

Side Projects

I’ve had to take a break on the article-writing to immerse myself in my work.  Theory is fun, speccing can be rewarding, and hooking up is good, but sometimes I’ve found myself missing real hands-on gameplay programming.

A friend of mine has been creating a Rogue-alike as a side-project labor of love for the past few years, and recently it went from sporadic updates to a full-on development flurry.  This of course made me very jealous, as tile-based engines allow for amazing freedom in creation…  There are few limits and implentation is a breeze.  It’s all about the gameplay.

The game is Dungeonmans, and he releases updates openly as an in-progress effort…  It obviously revels in its old-school presentation…  although the graphics are getting better by the day.   He’s created an overworld and NPC quest system as well as invested a great sense of humor within, so in some ways it outpaces similar indie dungeon-crawlers already.  It even can gather play stats that get collected at the home base for analysis and high scores.

Recently he made the codebase available to a few of us, and we’ve all been diving in and having a blast.  I’ve been working on a trap system recently, and I gotta say it’s the most fun I’ve had with development since Heretic II.  It’s been a while since I’ve worked on something past midnight without even noticing.

It’s not Diablo III, but fun doesn’t have to be developed in 3D by hundreds of people…   Check it out.