This week, most of my work hasn’t been in implementing cool new features. Since I switched to full-time on the project a month ago, I’ve been doing nothing but coding coding coding. But, since I’m also responsible for pretty much all of Jellyfish’s admin work, I’ve been neglecting the legal, accounting and management aspects of the company.
So, I spent my week on the phone on hold with various government offices, going back-and-forth with our lawyer with contracts and learning everything there is to know about small-business accounting. Thrilling, I know!
This week I finished integrating combat (remember, this includes mining!) into the mission structure… pending a fix for one edge-case bug where characters don’t have armor equipped. And pending no other bugs that was masking.
I also took a look at other things that can happen in the mission, because while we need combat integrated for obvious reasons, missions primarily aren’t about combat (unless the player plans a mission for that specific purpose).
This week I’ve worked on getting visually modular weapons in, mainly melee weapons. I did a bit of work on character portraits and I also created the first visual drafts for a couple of the datapad UI’s.
As always, post in the forums to tell us what you’d like to hear about in upcoming dev features! Have a great weekend, Astro-Friends!
This is a continuation from part 1.
In this post I talk about items. Several of you on the forums asked specifically about itemization, so here it is!
The goal of the Astrobase Command item system is to equally support procedural item generation and crafting (user item generation). And also in a broader sense to further refine the uniqueness of a player-created species, and the uniqueness of procedurally generated species a player might encounter.
Keep in mind Astrobase Command has no tech tree.
The technology “power” can conceptually be thought of as the items (and ships and modules) you know how to make, that you have the resources and production capability to make, and that your characters are skilled in making and using. There is no set path, no set technologies, just what you want to learn based on what you already know (or what alien device you’ve found)
So, let’s start from the basics:
What is an item?
From the perspective of Astrobase Command, an item is a collection of game stats.
The clearest example is weapons, which have stats that determine damage type, damage amount, AP cost, reload cost, etc. An item also governs the skill (or skills) when a character uses the item, and the resources and other costs it takes to make the item. There is also a game action (or actions) associated with its types — do you use this item in combat, to mine resources, to scan, etc.
Furthermore, game actions use formulas which take these parameters to create an output (you hit for 10 kinetic damage!), and balance items against other items. In the case of combat, it includes the target as well as the attacker. So an item is really the sum of all these things.
How items are made in Astrobase Command
In the game, the atomic unit of aggregate game stats is called a Part.
A part either adds or subtracts game stat values. When we procedurally generate a part, we follow the specific set of rules that govern its creation. Part X might add or subtract stat A, add or not have stat B, and only subtract stat C. Part Y might do something completely different to stats B, C and D. When we generate a part procedurally, we make some rolls and follow the rules.
Also rolled up into this is what resources the part takes.
Players need to discover a part type to be able to design a part of that type, and have access to the resources to be able to build it, and have characters with appropriate skills in order to manufacture it. It’s absolutely possible to design “theoretical” weapons your race can’t even can’t begin to build (yet), much less train marines to use. And humans do this all the time in the real world.
Items are made by combining parts, and in terms of game stats an item is exactly the sum of its parts.
Item and Part Types
Parts are typed. Some example of types are: Action, Barrel, Energy Device, Emitter, etc. And these have subtypes. To use projectile weapons as an example, a projectile weapon takes four parts — Action, Barrel, Chambering (Ammo Type) and Frame. Within these types there are subtypes: Simple Actions, Repeater Actions, Automatic Actions, etc. All of these have different rulesets, and some are more complex than others.
Where it gets interesting is that weapon parts also govern damage types. So an “Energy Sword” might be buildable combining the right parts from energy weapons and melee weapons. And this is up to the player to discover, and invent new ways of combining things.
When the player picks up an alien device on a distant planet, there is an implicit choice.
Give it to a Marine who figures out how to use it? Or take it apart and figure out how it’s built (with the chance of destroying some or all of it). If the player has never seen the Part Type before, it must be researched before new parts of that type are manufactured. Learning new types and new templates might be useful in creating the next generation of standard issue weapons.
And yes, you can name your weapons.
The player designs a weapon, calls it “Pewmaster 34″ and sends it to production which builds and assembles the parts out of resources, using the skills of the characters in charge of manufacturing. And does a production run of 10, 20, however many units.
So it’s possible that as a player you prefer well-made low-tech items over shoddily-made high-tech ones. Note the M1911 has been in service over 100 years, and the USMC just ordered a pile of them in 2012. Meanwhile, we’re developing autonomous flying combat drones and robotic battle-suits. In Astrobase Command it should likewise be viable (and even realistic) to have a healthy mix of old-and-proven with new-and-shiny.
Note: In the first version of Early Access, we have procedurally generated parts (and therefore items). Next step is to have crafting/manufacturing, and finally procedurally generated / user-created Part Types. The latter is currently working in code, but it won’t be turned on for EA because we need play-testing data on everything else.
Generated / Crafted part types is essentially a procedural tech tree — you’ll start tweaking rule-sets and pushing stats higher (or lower) to optimize your items.
We have a “self-countering system” with respect to weapons vs armor, and in the general sense offense vs defense. This means something may be considered a “best weapon” only in the context of an opponent whose situation makes it weak against that weapon.
For example, projectile weapon parts have rules that often give it susceptibility to corrosive environmental damage. Energy weapon parts are susceptible to both corrosive and electrical. Melee parts never have stats that do this, which makes them functionally immune.
So while energy weapons can by nature be quite powerful based on the rules which govern their stat allocation, they might be weak on a planet with electrical storms and salt flats simply because their durability doesn’t last very long. Or, if the player is invading an alien space station and there are reactor fires and other environmental hazards. This is in addition to specific mitigation for energy damage (absorb shields). Absorb shields won’t work against an axe.
If the enemy knows you’re coming, he can prepare. And if you know that HE knows you’re coming, you can prepare. This is essentially what is meant by self-countering, there is no absolute best… simply a contextual best given the situation.
Also, training characters take time, so you will have to choose where you focus their combat expertise. And because the game is Ironman/Permadeath, there is another layer of decision making between highly trained elite squads where every death is a genuine loss, or poorly trained cannon-fodder (redshirts) that you feed into a meat-grinder. Or any mix along any conceivable sliding scale. And also how these choices affect morale, and other station activities.
All items fit into this system, which is used equally in procedurally generation and player crafting. And for players to pick up a procedurally generated item, break it down, and learn something that helps them craft in the future!. So it’s about real choices, with rewarding consequences.
I’ll take a look at the associated forum thread for the topic next week! Or if there is anything else you guys want explained.
This week I worked on more mission logic, and mission AI. This involves the Mission Leader sending out either solo characters or smaller groups of characters to perform tasks and complete objectives in different areas of a zone.
Does he split up his team and have characters complete objectives simultaneously, or does he find safety in numbers and is willing to have a longer (but presumably safer) mission? Does he avoid the crashed alien ship he discovered that wasn’t detected by long-range scanners, or does send in the marines?
His AI and personality has to determine all these things, and the tasked units need to follow orders given their own personality and how much they respect the mission leader.
This week has been an iconic one. Or at least, it’s been about making resource icons.
Since crafting is going to be a big part of the player experience, we’ve come up with a list of 17 mundane and exotic resources to work with.
I want to build immersion by designing icons that look like they’d be found on a control panel in a real space station, rather than those that are commonly found in games. This can make things interesting, because many of our resources don’t have solid real-life references to draw from.
It does give plenty of room for the imagination to wander. After all, degenerate matter isn’t what Astrobase Crews make when they get some shore leave.
Hello! Still working on portraits and nothing is available that is good enough to show to the public. I did however put together this gif that cycles through the 64 visual variations of blunt(ish) melee weapons. Of course allowing for color variations will give many many many more visual variations.
Hey everybody! This week was another big one for crew jobs and station life in general. I’ll stick to the things you care about.
First off, I integrated the social pillar of station life (basic pillars are eating, sleeping, working and socializing) by integrating a Bar. So, when people have time off, they’ll go hang out there and mingle with other crew members.
Next, since Dave added genders to characters for the purposes of using the right words when formulating mission reports, I used the opportunity to go from 1 to 4 character models for characters. So, for our 2 current genders, there are crewmen and officer uniforms, which reflect their current rank.
Finally, I added skill gains to characters when performing jobs. There are two types of gains: a basic time-based increase when they work their shifts and job-specific action gains, like when you accept a new recruit your recruiter sent you.
We’re likely going to be moving our Dev Update posts to Fridays in the future to give us more breathing room between this and the Dev Feature.
As always, come visit us in the forums if you have requests for Dev Features in the future?
Disclaimer: this description of the combat system is from a design standpoint. So it gets pretty technical and delves into the nuts-and-bolts. You have been warned!
What is a Combat System?
From a design perspective, RPG systems can be thought of as organized sets of statistical contests which combine to form game mechanics.
Typically these contests are wrapped in a narrative context. An RPG with a lockpick mechanic might generate a random number, and compare it to a threshold determined by the value of a character’s lockpicking skill modified by the difficulty of the lock. We call these simple contests. Basically, it’s a roll compared to a number, with thresholds for success and failure derived from character stats. The contest usually has a discrete result: “You succeeded in opening the safe.” In the D20 system, you know this as a Skill Check.
In contrast, a combat system is the label we give to a complex statistical contest which typically occurs over a time-frame and features player decision feedback. There are a lot of factors that might go into a combat system — hit rolls, damage rolls, mitigation, cover, movement, and the over-arching concept of time management which can be represented by anything from cooldowns to an action points / turn mechanic. Unlike simple contests, combat does not have a simple statistical outcome. Instead combat may modify values anywhere in the character state, or game state.
I find it useful to demystify combat, and simply regard it as a complex mechanic for evaluating relative statistical power between multiple combatants, and the player skill in managing that power to form combat tactics.
Needs of the Astrobase Command Combat System
Game systems are designed to meet needs determined by the larger game design goals. Every combat system is different because it has been customized for each individual game. Good combat systems simply meet the needs of the game better than bad ones, and also better identify those needs. And players can feel this intuitively, and might say combat in a given game “feels natural” or “feels frustrating” or “is grindy” or “is fun,” etc.
The needs of the Astrobase Command combat system are the following:
- Usable by all complex contests in a unified, overarching system
- Character combat, objectives, mining, space combat, etc
- Usable for player-directed tactical combat
- Usable for simulated behind-the-scenes combat without any changes
- Combat log of the simulated combat needs to demonstrate the same strategy implications of the player-directed combat
- Encourage deep player strategy and counter-strategy when selecting the characters and gear to send to battle, and that the player and AI can equally execute these strategies in a satisfying manner
- Provide a purpose for crafting (for example, having item stats that interact in subtle ways)
- Support interesting procedurally generated items
- Different damage types and their counters should feel both natural and meaningfully differentiated
- Other combat parameters that relevant auxiliary combat stats can impact
- Fit with overall character progression, and item balance
- Prevent “this is the best stat, this is the second-best stat” situations
- Should provide for strategy, and counter-strategy rather than DPS-fest
- Support multiple sides of an encounter (each with their own objectives)
- Allow for satisfying AI behavior where the AI has the ability to make smart (or deliberately dumb) decisions, or decisions based on personality
- Should be implicitly hard to have broken behavior
- Be fun and interesting on its own!
This is a pretty long list, because combat is super-important to the game!
A Description of Combat
The correct design term to describe the Astrobase Command combat system is “simultaneous-turn tactical combat.”
In a nutshell, combat occurs over turns. In player-directed combat these turns occur over time frames (you can think of a turn as a combat second). Every unit submits his actions to the turn — this could be shooting a plasma pistol, or reloading, or using a device, etc. At the end of each turn the actions are resolved simultaneously, so it’s possible for two characters to shoot each other and both die. In player-directed combat the turns are seamless, meaning you don’t see the turns – you just see characters doing stuff.
Under the hood, it’s about Action Points (AP) optimization within a fixed window rather than cooldown optimization.
In Astrobase Command, AP is derived from the Mental stat on characters. Every character action is associated with an AP cost. If an action takes more AP than a character has, the action can span multiple turns. So you’ll never get in a situation where something is equipped and a character simply can’t use it. This incidentally opens up item generation and creates an interplay between front-loaded and back-loaded damage. The game can generate any item and equip it to any character and combat won’t break.
For example, if Ensign Alice has 6 AP and her rifle takes 8 AP to shoot, for first turn she’ll be aiming and the weapon will fire during the second turn. For visualization purposes, you might see her animation play 1/3 of the way into the second turn (2 AP remainder out of her 6 total) or throughout the whole turn. But all damage is resolved at the end of the combat second.
For non-visualized simulated combat (such as with Away Missions where you put an officer in charge), it works exactly the same. But in this case, the simulation can be run instantaneously. So the results of far-off battles can be calculated as needed.
One of the benefits of simultaneous turns is that it models realistic behavior for environmental damage and area-of-effect weapons (such as grenades).
Environmental damage can be applied consistently every turn as simply another vector of damage rolled up with any other combat damage the characters take. We explicitly didn’t want a system that favors the characters/side that gets to go first (so we have no concept of “going first”). A character will run up to throw a grenade while taking enemy fire, rather than take his turn, run to position, throw the grenade, and run back while everyone else sits idle.
Astrobase Command is essentially an Ironman-style game (permadeath + anti-save-scum), so above all the combat system needs to be fair! No character will die because he or she had the misfortune of going last, unless it’s because an action takes multiple turns to execute (because the item has a higher AP cost than the character can handle in a single turn).
This is getting a bit long, so I’ll break the topic up into two posts. Next time we’ll dig into the generated / crafted item system (all items in Astrobase Command are either crafted or procedurally generated) and how this ties into the combat system.
So we’ll be covering items, crafting and procedural generation, damage types, mitigation, and balance. Maybe we’ll have a part 3.
It’s been another week of jobs and section integration.
The first ones I knocked out were dining areas (cantina, cafeteria, mess hall). Now, when a character gets hungry, they go to their nearest dining area and eat (Food is also a resource in storage now). I also wrote it in such a way as to lay the groundwork for people to go eat at the same time. That way, friends can hang out together, which will make it even more obvious to the player what relationships they have with each other. It will also work nicely for social areas like bars.
Next up were medical treatment centers. So, anyone with medical skills can get assigned to a post there and they go about their research and learning. When someone is wounded aboard the astrobase, they immediately seek medical attention at the nearest treatment center. How good the doctor’s medical skills are determine how much medicine is used from storage, how long it takes, as well as how quickly the wounded character will recover.
Finally, I took care of sensors. So, someone operating the sensors terminal currently scans for new systems to explore. Their skills determine how quickly they find something, how well they can plot a course to it and how much detailed information they have.
This week I have been working on the portrait generation substance (procedural texture) and associated code. Since the results are still in a graphically rough state I won’t show a screenshot. Aside from that I wrote a tutorial on how to make a star field procedurally in Substance Designer for this week’s dev feature.
A few days ago I finished up integrating procedurally generated narratives into missions, as well as character relationship changes as an outcome of those narratives.
Good news: missions are working! And by this I mean “coder done,” in that their entry and exit criteria work, and a mission runs from start to finish across multiple zones on a planet. The mission leader tells people what to do, and they do it, with outcomes based on personality interaction. And the output is correct, and ready to be hooked up to the Datapad GUI.
This week I’ll be writing the objective system and add the first and most basic objective — mining! Mining as a standalone feature is working, so this is a matter of creating a flexible architecture that can empass mining but also all the other objectives we plan for missions!
As always, pipe up in the forums to tell us what you’d like to hear about next! See you next week!