content top

Brain Dump – Passive Combat


One of the systems I’ve thus far avoided thinking too much about for Project Universe is combat. Combat is popular. Combat is endemic. Combat is the least common denominator of game mechanics because it’s a stand-in for so much: multiple people enter, one person leaves, loot drops, XP is gained, story is advanced, conflict is resolved. You can’t get that kind of satisfaction from, say, crafting swords.

I’m as much a fan of combat as anyone, but I’m also a fan of other systems, which is why blowing things up has taken a back seat to mechanics like economics and event systems. But I can’t put combat on the back burner forever. At some point I’m going to need to come up with a way to present the scenario that as a space trucker, you’re going to come under fire from those who want to take what you’re carrying.

I had been entertaining two methods. The first was the most obvious: real time reticle-based space sim firefights. Think Wing CommanderElite: Dangerous, or more appropriately Starpoint Gemini 2. You point your ship at what you want to shoot at and pull the trigger. You’d also have at least one alternate fire weapon you could trigger with the other mouse button or hotkey. I think this would be the most expected method, but I have some concerns there, such as enemy AI that needs to be smarter than the AI that people smarter than me haven’t been able to model, as well as re-purposing the mouse to handle flight and fight as opposed to the free mouse cursor mode I’ve got now. The second possible combat method was what I thought of as the FTL model. In this style, the game would enter into a combat screen with the player on one side, and the enemy on the other, and there would be some kind of back and forth that could happen until one side surrenders or explodes. There’s really no exciting action going on here, but the player could still call shots by using hotkeys on cool-down to unleash better attacks and upscale defenses.

Yesterday while taking my afternoon walk around the neighborhood, I came up with a third potential option: passive combat. In a way, I actually prefer this method for reasons I’ll explain, although I also realize that I think a lot of people will absolutely hate it. 

The conceit of the game is that you, the enterprising space trucker, are trying to make a name for yourself as a reliable courier of other people’s stuff. You will start out with the junker hauler — it’s all you can afford — that has limited cargo space and limited defenses. But you will have defenses, because no one expects pirates to grant new pilots a grace period while they find their space-legs. The ship you pilot isn’t is nimble fighter; it’s a ponderous cinder block that can best be described as an engine attached to a cargo hold with a seat at the front. It’s massive, and you’re just one person. You can’t be expected to mind all of the stations at once, especially in critical situations.

So you need a crew. Your crew will handle functions around the ship that need handling, allowing you to concentrate on getting your cargo to it’s intended destination. Crew duties would include engineering, navigation, and tactical stations (possible others). Eventually you’ll be able to hire real people to fill those spots, but initially you have a crappy AI CPUs to handle the responses in those jobs.

The passive combat, then, is intended to simulate the fact that you, the Captain, are in charge of getting the ship to it’s destination. That means that should you come under attack by unsavory characters, it’s the tactical officer’s job to do the fighting. Each station would have skills that contribute to the percent chance at success, so your tactical officer would have skills related to hitting things with weapons. Of course, the viability of the weapons you buy would also factor into it, resulting in an autonomous system that would start shooting at offensive targets as soon as you give the order to open fire. Meanwhile, you keep flying, because while you’re not totally defenseless, you’re not a Top Gun bad-ass: escape is always going to be your first priority.

What benefit does this system have over active combat, or the turn-based/timer-based combat? First and foremost, it keeps with the tone of the game in that this is about economic warfare, not pew pew warfare. There’s plenty of games that focus on blowing things up, and I want to try something different. Second, it provides a layer of management mechanics, improvement, and progression via the crew system. A crew system would allow you to upgrade your ship and it’s abilities, as well as provide a much needed money sink for your growing fortune. The best crew will cost more in salary, but you can’t stay with the default AI crew forever if you want to survive more hostile systems. Third, it could be seamless; one minute you’re heading for the jumpgate, the next minute you’re giving the order to open fire on pirates that have swooped in to take what you’ve got. You could easily escape by reaching the jumpgate, but with the proper weapons and a good crew, you can repel the invaders, repair any damage you take, and maybe collect some salvage in the process.

As I mentioned, I kind of like this system over the others because I think it’s different, but I understand that the “hands off” approach will really turn some people off. I don’t want to implement a system just because it’s expected, and I don’t want to design a system in a way that’ll become tedious or that frustrates or interferes whenever it triggers. A passive system allows the player to keep playing the game — a game of interstellar commerce — while not skirting the notion that being in the middle of nowhere with no help in sight is the perfect place to get jumped. When I think of this system playing out, I think of all of the battle scenes from Battlestar Galactica (the new version) where the Galactica fired off clouds of cannon-fire towards the Cylon base-stars. That much firepower was pretty awe-inspiring, but it’s primary purpose was to keep Raiders away so the fleet could escape. In the same vein, I want combat to be about defense, not about bounty hunting or picking fights when you’re supposed to be building a shipping empire.

Read More

Trimming The Fat With Playmaker – Spaghetti Edition


I had to share this update because it’s kind of wacky, and shows what you can get up to with Playmaker.

The way I was approaching things, I would have had to make a different prefab for each NPC type because the FSM is attached to the object, and certain NPCs would need slightly different behavior. For example, merchants will dock and jump, but police need to just know they entered a trigger so they can turn to their next node.

For some reason I thought that was kind of unnecessary to have individual prefabs, since the core script was modified to work with all NPC types. With the script being so accommodating but the FSM being specific to the prefab, I would end up confusing myself (which I know, because I already did, and that was only with two prefabs!).

So I thought: why not set a property in the script so I could define the type of NPC, and then automatically have their behavior change based strictly on that setting? That’s technically how I had the original movement script, and that was cool, but since I was working with Playmaker, I needed to change the FSM to match the more generic application.

The bulk of the changes are applied to the Move state. When the NPC enters a trigger (station or jumpgate), we need to transfer the state to the node of the appropriate type. In the Station and Jumpgate nodes, there’s a property checking Action that looks at the “NPCType” setting from the script. It fires an event based on the value of that property, which is why you see the different NPC types attached to the Station and Jumpgate events. Each NPC type event routes the action to the appropriate next state. For merchants, a jumpgate will destroy the object, but for the police, it just routes to the Select Next state. Similarly, merchants will route to the Dock state when they encounter a station trigger, and the police route to the Select Next node as usual.

It looks messy, but it worked great, and there was practically no modifications needed to the underlying script, aside from adding the “NPCType” property (an enum) and a special translation property “NPCTypeForPM”, because Playmaker can’t recognize enums as a valid property type for reading purposes.

Read More

Trimming the Fat With Playmaker

Not a major update, but I wanted to talk about an experiment I ran last night in Project Universe.

One of the aspects that I have in place right now is NPC routing. I had a need for some life-like activity within a sector, represented by merchants, police, miners, and pirates, so that a player doesn’t feel that she’s the only person in the game world. Merchants seemed like the easiest critters to create: they would spawn at a random jumpgate, head to a random station where they’d lay over for a few minutes, and would then re-appear and head to another random jumpgate and vanish from the scene.

I had spent a long time developing these amateur-level AIs for three of the four types (pirates involve combat, which is a system I’ve not approached yet) using a combination of code on the objects themselves, as well as on the scene controller for traffic management. When I say long time, I mean a few weeks. I had struggled with getting the NPCs to aim at their destination, to make sure they picked the proper destination types, and to make sure they didn’t overshoot, and that they took appropriate action when they reached the trigger of their waypoint nodes. The system isn’t clean by any stretch, but it works; my merchants jump in, dock, and jump out; my police patrol between public elements like stations and gates; the miners will hang out at asteroid belts and will occasionally return to stations to drop off their goods.

What I wanted to try was to mimic these behaviors with Playmaker. For those who didn’t catch my old posts from my defunct GameDev website, Playmaker is a visual state machine add-on for Unity. It allows a developer to define “states of being” for an object — idle, moving, jumping, docking — and to transition between those states based on criteria like player input or variable assignments. It obfuscates code by presenting states in a visual flow-chart style which sees the state nodes connected by event flows. I’ve been a long time fan of Playmaker, but had opted to try creating these AI guys by hand just to see if I could.

Last night I had set up a new FSM (finite state machine) in Playmaker for the “merchant” object in a new scene in my working copy of Project Universe. I removed all existing NPC scripts and created a new, single script that had only a few responsibilities:

  • Set the movement plan: Determine which nodes the merchant is going to visit
  • Select the next leg of the movement plan: Where should it go next?
  • Movement: Getting from the current node to the next node
  • Jumping: When the ship enters a jumpgate trigger, destroy the object
  • Docking: When the ship enters a station trigger, pause, and start a timer
  • Undocking: When the docking timer reaches zero, set bits that allows the NPC to move to the next node

That’s pretty much what the original NPC movement script did, but whereas the original script had 445 lines of code, this new version only has 102, and is nowhere near as dense, and doesn’t contain anywhere near the cross-script dependencies that the all-code version does.

Playmaker’s role in all of this is mostly to call the methods of the script based on conditions. You can see the FSM in the screen shot below:


  • Idle: calls the method for setting the movement plan (choosing the nodes to visit) and aligns the NPC with the first node.
  • Move: Calls the method that sets the “IsMoving” boolean on the NPC. When this is set to true, the Unity engine’s “Update” statement moves the NPC ahead towards the destination.
  • Jumpgate: If the Move state detects that the NPC has entered a jumpgate trigger, this state calls a method that destroys the NPC. Later, I’ll have to update it to “jump” the NPC, because I use object pooling for NPCs and don’t want to destroy it. Later later, I want NPCs to “live” and actually travel through the game, so I really don’t want to destroy them.
  • Station: If the Move state detects that the NPC has entered a station trigger, this state calls a method that sets “IsMoving” to false and “IsDocked” to true. Unity’s “Update” statement has a section for “IsDocked” being true, which is to check a time difference between “now” and the time the NPC docked. When that difference reaches 10 seconds (arbitrary value), the “IsDocked” is set to false and “IsMoving” is set to true. This is an incomplete system, since the NPC should be hidden while docked, and in order to do that I had to disable the NPC. Doing that removes my ability to address the object, meaning Playmaker can’t talk to it to tell it when to re-appear. So control of docking has to be done outside of the NPC itself.
  • Select Next: before the NPC gets underway, this state calls a method which aligns the facing to the location stored at “Current Node + 1” in the route dictionary array so the NPC can move to it’s next destination. Once that happens, the event cycles back to the Move state so the NPC can actually move. If the next node is greater than the array limit, we’ve got a problem unless the NPC has the “IsLooper” set to true. In that case, it’ll just cycle back to Node[0], it’s origin, and start all over. That’s for the police; for a merchant, Node[0] is a jumpgate, which will currently destroy the NPC. I have to handle Node[]+1 scenarios for merchants at a later time.

As pleased as I am that I was able to replicate the same functionality with less code and in less time than I had originally spent with the long-hand script, committing to a tool like Playmaker is not something to be taken lightly. Once you start using it, you have to keep using it, lest you end up with some long hand code and some Playmaker code, confounding debugging attempts and making manageability a veritable nightmare of “where the hell does X do Y?!”. To be honest, I’m leaning towards being OK with relying on Playmaker, since I’ve gotten the simple AI working long-hand and know what it’s supposed to look like; this is kind of just a refactoring of the code for efficiency and cleanliness. And considering I’ve got some rather complicated systems that I want to try and work into the game, having a more visual representation of those systems might not be a bad idea, so I don’t end up confusing my future self when I have to test and debug.


Read More

Unreal Tournament; Development Updates

Unreal Tournament


No one was more surprised than I was to find that there’s an updated Unreal Tournament going on right now, under our very noses. Epic is apparently getting all hip and following the recent trend of cozying up to the crowds by involving the community in the development of the latest entry in the evergreen arena blast-fest.

The site at (duh) lists a whole lot of ways that the community can get involved, from downloading the source code to making mods and maps. Thanks to the free release of the UDK and the amazingly streamlined development process that UDK and Unity have brought to the masses, modding and side-development is a hobby pretty much anyone can get into these days.

I’ve not gone down that route just yet (although the idea of making maps for a shooter, like I did in the old Doom days, is a heady proposition indeed), I did install the game and have played a few rounds. UT is exactly the same as it ever was, and that’s pretty damn glorious, evoking fond memories of massive LAN parties of days gone by. It’s certainly a change of pace from my steady diet of Destiny, what with UT‘s lightning-fast movement and insane close quarters fighting. Modern shooters look elderly by comparison, and it’s taking me some time to re-learn the frantic UT pacing so that I’m doing more than just firing ineffectively at the walls and floors.

The game is currently in “alpha” stage, meaning that there’s a lot that’s just placeholder art, but the mechanics seem to be in place. Last night I was talking about it with Big Daddy T, and we went looking for our favorite UT maps from yesteryear. My favorite of all time was CTF Hall of Giants, which hasn’t yet made it into this newer version, though I’m sure there’ll be both official and several community variations on it at some point as it was a pretty popular map.

Development Updates

My updates re: Project Universe have fallen off suddenly, and that’s mainly due to the fact that I’ve gotten T-boned by other, more pressing concerns. Autumn is kind of when everything battens down the hatches for the impending winter here in the North East, so there’s a lot of last-minute happenings by way of get-togethers and birthdays and the like, not to mention the fact that my daughter is now in high school and is back on the homework treadmill that usually requires parental input after we get home in the evening.

When last we left the project, though, I was working on the pricing mechanism, and if I remember correctly it was working pretty much as intended. I do recall there being some flaws that I needed to address so that I could enact a test whereby I’d buy at one local station, fly to another local station, and sell the goods there for a profit. Being a victim of my own success, though, buying at one station and having the other station to sell to isn’t a guaranteee; I don’t know the buy/sell state until I get to the destination station, which is by design. I should make a mental note to create some kind of UI that will list the buy/sell status of all stations in the sector.

I’ve also managed to score a Blender course from, an awesome site for all kinds of tutorials. This class is from the same folks who created an absolutely mammoth Unity development course on the site, and I highly recommend both for folks who are new to either Unity or Blender (or both). I was spurred back to Blender after attending the high school’s annual open house. My daughter took a 3D modeling course at Harvard University this summer, and has a 3D modeling course at the high school this year. Both used Maya (and we have the free, three year student license for home use), so I figured that we could work at learning the basic modeling techniques together. Oddly enough, her semester project in the class is to create a space ship; I just happen to need a space ship for Project Universe. What are the odds?

Read More

You Get What You Pay For: Sword Coast Legends


This weekend, Sword Coast Legends had it’s phase two head-start access for anyone who pre-ordered the game. This allowed pre-order folks to download the game engine and mess around with it. I qualified that with “engine” because the campaign was not made available for reasons spanning “we don’t want to ruin it” to possibly “it’s not done or refined yet” ahead of it’s September 29th release date.

I had been wonderfully excited for SCL since I first learned of it’s construction capabilities. I had spent a lot of time with Neverwinter Nights back in the day, creating all kinds of cool systems for games I had planned on making within the engine, although I never actually got around to making a game…just systems…but I still had a great time doing it. Based on what I was seeing with SCL, I had high hopes that I could once again find that level of enjoyment in creating stories, even if it’s within a narrow framework of a specific IP and with specific resources and assets.

The “DM tools” is kind of the nebulous name given to the non-player side of SCL, and encompasses two activities. The first is the “live DM”. Here, a fifth player can follow four other players around the game and manipulate the NCPs and creatures, possessing them and fighting as them with and against the party. The DM can also drop in new content on the fly, such as traps and new encounters. The second of these tools is the part I was really after: the construction kit.

I had watched some of the dev streams over the past few weeks, especially those focused on the construction tools. My initial, blind, back-of-the-box-blurb impression was that SCL would be a worthy successor to NWN when it comes to being able to build your own campaigns and modules. The live streams knocked that expectation down a peg or two, as it seemed that the toolset was considerably streamlined compared to the Aurora tools that NWN used. Each of the streams I had watched were pretty focused, or so I thought, on showing how easy it was to create something with minimal fuss, and each stream having the goal being able to set up a scenario for players to run through a mere hours before everyone was set to convene.

This weekend, I found that the easy mode wasn’t a choice; it was the only mode available during head start. I had to immediately banish any ideas that this was going to compete with NWN‘s ability to create a distribution-worthy campaign. There was no option to create unique maps; the system generated them based on some internal algorithm and then “baked” them so what you received is the only layout you had to work with. Outdoor areas were tiny. Indoor areas were almost insanely large, even when I specified that I wanted a “small” map. Placement of creatures was handled by using the floating d20, and in using that method, the only way to place creatures was by accepting a random sample the system provided. You could place individual creatures as you like without using the d20, though, and while you could create your own characters (NPCs and standard D&D racial types), the overall system felt like it lacked a sense of control. One of the worst realizations was that there didn’t seem to be a way to create in-depth quests. Everything I saw was relegated to a three-act “grant-advance-complete” structure, all of which ended only in giving the players an item, cash, or revealing a new location they could travel to.

Even the DM mode seemed to be impossibly under-powered, although I didn’t have a chance to actually try it out with live people. While I could possess NPCs and monsters, I couldn’t actually act as them. Possession seemed to be for combat only, not for using an NPC or creature as a mouthpiece to interact with the players.

Needless to say, I was terribly saddened. This was not the game I had been excited for. Even the actual gameplay was weak and uninspired, like a more shallow and repetitive version of Diablo. I gave it an honest shot, though; after my initial (angry) foray into the DM tools, I decided to calm down and sit down to actually try and work within the confines of what I had in front of me, but I couldn’t make it happen. There was always something about the results that didn’t  look right and which I couldn’t change, or some mechanism which was either way too much or far too little for what I felt I needed it to be in order to be satisfied with the outcome. At best, I figured that these tools would offer a decent method for making a module for multiplayer that relied on only the most bare bones of narrative reasoning. There’ll be no modeling of some intricate, Dragon Age level interpersonal intrigue here, but if you want to run yet another module whose purpose if for you to retrieve a lost item or to kill a named boss, you’ll be happy to know that SCL has your number.

But then I stepped back and realized that none of this is the game’s fault. It’s mine. I had expectations that really never fit with what the game was selling. Nowhere did SCL advertise (that I saw) that this was anything like NWN in terms of creative horsepower. I watched the videos and thought that they were cool and all, but that their limited interactions must be holding something back for release, or because it was unfinished, or it was just a focused presentation. I assumed there had to be more to it, because it’s always “go big or go home”, and there’s no way what I was seeing was big enough to not get this game sent home. My impressions were all about what I expected, not what I was actually witnessing.

I always maintain that “games don’t suck”, that any non-technical flaws we attribute to the game are results of our own misplaced expectations, and this is a perfect example. I had expected a spiritual successor to Neverwinter Nights in both gameplay and toolset, but Sword Coast Legends is neither. It’s its own game. As a single player game, it’s terrible; as a multiplayer game with a DM looking over shoulders, it’s probably pretty damn good. It’s more Gauntlet with an Overlord than it is Baldur’s Gate. The tools are more to support extensibility than they are for creating sweeping narrative experiences, but considering there was nothing that I could see that indicated that SCL was even about sweeping narratives, the tools work towards the purpose they were intended to work towards. This is a multiplayer dungeon crawler with dynamic, real-time interaction by a (somewhat) all powerful DM…basically, it’s original D&D.

I can’t say that I don’t still harbor a bit of resentment at SCL not being more than it is. I had hoped that it would build upon NWN‘s legacy, or even Star Trek Online and Neverwinter‘s “Foundry” tool set (which is more powerful than the tools found in SCL), but that’s an unfair comparison and shouldn’t detract from what SCL will be bringing to the table. SCL looks to be a good game for those who want the tabletop experience of D&D but don’t have a local group or are daunted by or uninterested in virtual tabletop gaming. In fact, SCL is more akin to a souped-up virtual tabletop program than it is a game, and even the limits observed in SCL (like not being able to talk through a possessed character) can be gotten around with come creative thinking.

Now, before I close out on this hopefully more-positive-than-not note, I wanted to add that my turn-around not only came to me when I realized that I needed to put my money where my mouth usually is and think of the game based on what’s in front of me, but also because I saw a few folks on the official forums talking about how the game might be purposefully missing some key features beyond just the lack of the main campaign. This gives me hope that there’ll be an update waiting for the 29th that will address at least some of the disappointments I have with the product. Even if those posts were just wishful thinking, I’m hoping to be able to try the game as it was intended to be used: with others in a traditional dungeon crawl scenario and a DM at the helm.

Read More
content top