Hey everybody! For those who missed it from the Tuesday post, we’ll be holding off on Tuesday Dev Features for a few weeks as we get ready to start closed first playable playtests. This also means we’re crunching like mad, so these updates will be chock full of features!
Hi everybody! This week has been spent creating a Frankencomputer by melding the better parts of my old PC with the better parts of my “new” PC. Followed by trouble shooting and software installations to bring balance to the force of computers in my home. Once everything was up and running I was able to get back to working on portraits.
This week I worked on designing procedurally generated storyarcs. Now that missions are working and generating narrative (and all the things characters can do on a mission — combat, mining, objectives, etc), we want to be able to guide the narratives into some cohesive storyarc that digs into the personalities of your crew.
Nothing here pre-scripted! The storyarcs will happen organically based on the decisions of the characters on the missions, and who they are as people. This is super-exciting to us because it means the mission reports will read like vingettes or mini-episodes where stuff happens and story is created based on who your characters are!
For the last few weeks, I’ve been waiting on a patch to a third-party AI solution we’re using for character pathfinding through the astrobase. This meant that a lot of critical features that relied on this working had to be put on hold.
So, this week was spent mostly working on features that wasn’t impacted by this. I started by creating our first iteration of a main menu. It’s got what I think is a cool visual concept that we’ll be able to refine later. Gameplay-wise, it now allows to actually create a species rather than rely on one getting randomly rolled for us.
I also worked some more on cameras and input. Since we’ve boiled things down to an external camera for overall module viewing (ideal for reports and module construction) and an internal camera for crew and section-specific interaction, I’ve had to do some work sorting out what a player is trying to do when they click or mouse over. Are you trying to preview the section or the character inside it? Things like that.
It also gave me the opportunity to create an ugly placeholder contextual floating menu when you select modules in the external view. Eventually, it’ll allow you to set the state of the module (normal, evacuation or lockdown) as well as destroy it, but for now all you can do is rename it. They start out as “Module 1″, “Module 2″ and so on, but we wanted players to give names so they have easy ways to refer to areas of the astrobase, as well as personalize things a bit.
I also added some additional camera rotation control on the mouse. We’ve been relying on a lot of keyboard input for things and I’m trying to lighten that up a little bit.
As I’m writing this, I just managed to fix the aforementioned pathing bug, so I’ll probably be spending some time fixing all the little bugs that will come with people going about their daily routines (eat, sleep, work, socialize, wander) and how they execute them. I just noticed a bug where people are sitting on each other in the cantina. So, fun times ahead! See you next week!
Hey everybody! It seems I derped when I tried to schedule this post for Tuesday. Sorry about that!
I know you’ve all loved these Tuesday dev features but we’re going to hold off on them for the next few weeks. Good news is we’re doing this because we’re crunching to get a closed playable build out to you in a few weeks!
We’ll still be doing our Friday updates so we’ll keep you posted on our progress.
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?