Rank: Warmaster Development Blog

Hi everyone. This is the UI/UX Artist Paul with another update on the Building Screen.

The list on the righthand side has been expanded to include all 15 lines of text display so that everything will be visible at once without needing to scroll. A backdrop has also been added to "hold" the text fields themselves. More icons have had to be added for the extra info being displayed. Many preexisting icons were sufficient for this end, however other fields prompted the necessity of new icons.

A spacer element was also added to separate the information display on the right and the action buttons on the left. This will likely evolve as further ways of organizing this screen follow through.

The building screen is a simple one-horse show. There are no additional subscreens and its function is relatively straightforward, so that's that for this post. Next time I'll have the Corporation Screen made more presentable to show!

Hi everyone! Jorden, here with just, as the title says, a quick update.

Not a whole lot to report from the last couple weeks. I have been busy writing what we're intending to be our final launch trailer (not to say that it will be our last trailer ever but we're intending for this to be the last trailer before Early Access). I've previously described a difficulty implementing our tutorials and scenarios due to a lack of infrastructure. This has very recently been addressed and we're going to be using Articy: Draft 3 as our scenario constructing software along with an importer and campaign engine that Art has been constructing. So I'm also very busy implementing our tutorials into Articy as well as writing and implementing our third tutorial which is focused on larger empire logistics. The two previous tutorials along with this new third one should be a full and complete training course for our game. I just have to make sure that all of them are fun and interesting.

Like I said, I'm very busy but I don't have a ton of cool progress to show at just this moment so that's all for today. I should have more news in two weeks.

Hi all! This is your UI/UX Artist Paul here. This week I have something new to show: the Building Screen.

A relatively minor screen, the Building Screen allows players to see a full report on each individual building in their city  installation, and gives them direct control over that structure. This is a one-page screen so there isn't so much to present beyond this preview image.

In another update I'll have previews of the more meta-level Corporation Screen, which is where players choose their faction or more accurately create their own.

Hey everyone! It's Jorden again with another quick update. (I just finished writing the blog. It wasn't that quick. I'm sorry).

Today I just wanted to let you in on what I'm currently doing. Bit of a preview of something we're hoping will be in the game at Early Access. Now, I have to give the disclaimer:

There is still work to be done to prepare the game for Early Access and we want to give our players the most content possible. We want everyone to come away from their first experience with our game feeling like it was well worth the time and money invested and so I really can't make any guarantees as to exactly what will or wont be a part of the Early Access release of the game. Nonetheless I can say that if all goes well this particular thing will either be in the initial release or very probably in the first content patch.

With that out of the way, I'd like to talk about the first dynamic scenario of the game, "Raiding the Lost Ark" (working title, subject to change). As I mentioned two weeks ago, dynamic scenarios are the largest events in the game and are intended to shake up the status quo when they occur. Currently the primary game mode is intended to progress in open stages or "zones". Zones are a little complicated to go over without their own blog post but they're basically how we structure the narrative of the main campaign mode. There will be other options that won't have zones or will have different zones but the important aspect is that zones are not "maps" in the traditional RTS sense, they simply represent the player's progress through the narrative. They're relevant here because my current intent is to have one dynamic scenario trigger per zone. That does not mean there will only be one scenario written for every zone, rather that each zone should have a dynamic scenario as a sort of climax for that zone and that ideally a dynamic scenario will always trigger before the player moves on to the next zone. For Zone 1, "Raiding the Lost Ark" will be one of the potential dynamic scenarios and since it's the only one I've come up with so far it will probably trigger every time you play the campaign until we get some other options in.

So what is it? The setup is pretty simple, something falls to the ground out in the Martian desert and impacts pretty heavily. Because this is a dynamic scenario it isn't only the purview of any one empire so all the current empires in Zone 1 (a small section of Mars to get your feet wet) will recieve the same alert about this event. Something to the effect of a message from Ares stating "Our sensors have detected what appears to be an orbital strike. The location has been marked for you, I recommend immediate investigation. If another corporation has the ability to bring the sky down on us, we need to know about it." (I wrote this just now in the blog, it may very well change). The player is given a nav point where they simply need to send any ship with sensors to go investigate. When they get to the location they find an ordinance box that can't be scanned but which is clearly from before The Isolation. There's no way to know what's inside but Ares will tell the player that it's possible it might even be technology from the height of the Asteroid Engagements (this would be well beyond the player's current tech level). The first conflict of the scenario is that the AI empires will have also sent scouts and maybe even fleets. Only one corporation can claim the box so the player will need to fight for it. Once any corporation manages to perform a salvage on the box all corporations will recieve an alert that the box will open in five minutes. This changes the conflict from simply eliminating enemies in the area to a sort of "King of the Hill" situation where the area near the box has to be successfully held until it opens.

What happens when the box opens? You'll have to see, but there is something inside the box. It won't be the same thing every time you play, though, it's one of three options (eventually four but the fourth option is more complicated and will require a ton more playtesting so the first version of the scenario released to the public will likely see only three outcomes). The current obstacle to this scenario being part of the first Early Access release is the state of the enemy AI. Currently the enemy AI is a state machine, as Art likes to say, so it doesn't react to the environment. This means that we cannot make the box a desirable objective for the current AI and so the scenario can't serve it's primary purpose, which is to kickstart a conflict in the early game and force players to act quickly. Upgrading the AI is a critical part of our pre-Early Access work but the inclusion of this scenario will depend heavily on how long that upgrade takes and whether it leaves us with enough time to fully test out the scenario and squish any bugs. Still, I hope this was an interesting look into what I'm working on and I hope you're as excited to play this scenario as I am to bring it to you. That's all for this update, see you next time!

Hey everyone! Jorden, here. I've had time to get a lot more work done on the game's scenarios, which are my primary responsibility, and I thought I'd talk about how that works. Briefly, since I have to get back to it soon. We basically have three categories of events that can happen in game: static discoveries, random events, and dynamic scenarios. None of these are in the game right this second but we have started to lay the groundwork and planning for how they're going to be run.

In order:

Static discoveries will be placed at world generation; these are stories that you find as you explore the map looking for the enemy and for good territory to expand in to. They tend to be pretty short but they will alter the short term outcome of your exploration and you'll be finding them all throughout the game. The enemy can find them too and reap the benefits or pain associated with any given discovery (some of them are very dangerous).

Random events are fully controlled by the Storyteller AI and are triggered over time; these stories come to you. At the most basic the only determining factor for these events is a simple dice roll which would be run every few minutes to determine if you get an event and which one. That being said there will be a lot of other factors to try and ensure that random events do not trigger too freqeuntly or too rarely or that an empire does not experience so many challenging ones in a row that they get destroyed. Basically we want to protect you from the whims of the dice (or random number generator to be specific). AI empires can also experience these but generally random events will be somewhat localized and only affect one empire at a time.

Dynamic scenarios are the most intense and they have specific, individual triggers; these stories are never random and will usually have wide-reaching effects. The main campaign events are all going to be considered dynamic but there will also be many additional scenarios which a player will encounter. They don't really like to share the spotlight with one another but they can be triggered in all kinds of ways. Some of them will probably end up being placed at world gen like the static discoveries; never drop your guard while exploring. Dynamic scenarios will usually affect all or most of the empires currently in play and the results will have long term impact on the future of the game. Some dynamic scenarios may even result in permanent, solar system wide buffs or penalties that will force all empires in play to adopt new strategies in order to be successful.

That's just a quick look at what I'm working on, currently there are quite a few static discoveries written and a couple of really good random events. There's even an early dynamic scenario. I'm hopeful that all of these will be present in the game at Early Access but as always I cannot make any promises. Looking forward to seeing you encounter my stories!

Hi all. This is your UI/UX Artist Paul here. This week I have updates on the Flight Cursor!

Last time we saw the Selection Cursor which is used for navigating menus and other interactive in-game controls. The Flight Cursor is what appears in the Sim Screen or cockpit, when you are actually flying your ship. As such, the Flight Cursor has an interactive design based on the three-dimensional nature of space flight. Aesthetics are being kept minimalistic as, with any mouse cursor, the end design is going be very small in terms of screen real estate. The main function is going to be an indicator of how much one's ship's anti-inertial thrusters are firing (or in other words, how much one is turning.)

Below are a few concept sketches:

The general idea being explored is of a segmented arrow that "fills" or "grows" as the ship turns. Aiming the mouse at the edge of the screen is how one turns hardest, and thus will fill the Flight Cursor to its fullest form. Conversely, keeping the mouse centered (or hitting the grave key to disable flight controls) will change the cursor to a null state and portray a circle. The arrow form will rotate like a compass needle as the pilot maneuvers their ship, always pointing in the direction of steerage.

Further evolutions are forthcoming!

Hello! Jorden, here. Quick update.

We had our group lesson about making IAUS AI using the Curvature program on Friday. Art is a very good teacher so it went pretty smoothly, albeit kind of long, but I wanted to share a bit of my perspective when it comes to working on this stuff as someone who just isn't a professional computer person. Now, to be clear, I've always been interested in computers and on a couple occaisions I've entertained the idea of learning to code but I am not and probably will not ever be a programmer. Nonetheless this AI creation process does involve a sort of "programmer thinking". Basically what I have the ability to do with the Curvature program is I can define the actions and considerations that I would like an AI to use and it will do it. For a brand new AI like the Storyteller even if I put a whole project together there's a lot of things that would need to be hooked up by Art before it would actually mean anything, but I could right now go into the AI for the ships and adjust how it behaves and it would have real effect on the game. My understanding is that the hooking up process is actually the easier part of the whole task, what we do with the curvature program is much more in depth and complex. It's definitely not something I've ever studied for when I was learning writing in school.

So, my perspective? It feels a bit like being required to build a printing press. Not to invent a printing press, mind you, but to build one in order to facilitate the spread of the stories I'm writing. Assembling this tool doesn't add content to the scenarios I'm writing, nor will it make implementing them go faster once they're written. But the Storyteller will be absolutely integral to those stories making their way to the audience in the way I inteded them. While being a writer has not prepared me for the process of building this tool being the main writer for this game means that I understand better than everyone else what features this tool will need to have to be the very best printing press for us. It's going to take me a little while to get it done, but I'm hoping it will be a really cool printing press soon and then I'm going to be able to run off a million copies of my little stories for all of you to read.

Hello everyone! This is your UI/UX Artist Paul. Today I've got more updates on the Game Cursors.

The Selection Cursors are what appear when navigating menus and clicking on icons. They are designed to be simple yet interactive and visually pleasing. For this week's blog post, let's take a look at the "Disabled Cursor" that appears when the mouse is hovering something that has been explicitly turned off or otherwise made unavailable.

Here's the cursor, and its accompanying texture in the 2D vector graphics application. The artboard is sized to the texture file specifications, in this case 256x256 pixels. The black is the vector object that will be converted into geometry, and hence its coloration here is moot.

To ensure crystal clarity, the cursor is being built as an actual 3D geometric object. Here is a preview of the cursor in the 3D modeling environment. 

The cursors will have overlaying / underlying effects applied to them, so their associated textures were made with transparency in mind. Though the color image looks solid, here's the alpha channel of the same texture file. The white parts are 100% solid. The black areas are completely see-through. The gray is where we will have some color (in this case green) but also the ability to see past it, and this is where flowing textures will appear to give the cursor some life.

With this implementation, we will be able to have multi-colored, high graphical-fidelity mouse icons that change color and selectively show special effects applied to them. Further work is under way to achieve this goal.

Hello! It's Jorden, again. I'm just gonna dive right into it today.

Those who know me know that I absolutely love tabletop role-playing games such as Dungeons and Dragons, Chronicles of Darkness, Shadowrun, and Stars Without Number to name a few favorites. I played those games all through high school and college, usually in the Dungeon Master or Storyteller role, and when we went into quarantine and could no longer physically visit our friends and family I began running a game for my family as a way for us to keep in touch and make sure everyone was ok. As I have worked on writing scenarios for Rank: Warmaster I found myself drawing upon those collaborative writing skills I had sharpened in my teens and early twenties. Once again I find myself in the Storyteller role, setting the scenes and deciding on the behaviors and personalities of the people that are encountered in those scenes, but just like in those tabletop games the other half of the story is provided by the players. I find myself making decisions about the challenges each scenario should present in exactly the same way that I would plan an adventure for a group of players; asking myself about the skill level of the players in quesiton and the tools and abilities they have available and even about how bad I'm willing to make the consequences for failure. On top of that, Art recently suggested that we probably want to put another AI in the game using the IAUS style that I mentioned a few posts back. This AI would be the Storyteller and it would serve to make decisions about when scenarios should trigger and which ones. I'll likely be doing a lot of the work to determine how this particular AI makes decisions and what it considers to be a fair or unfair challenge, which would of course be based on how I would run things personally. We're basically planning to put a stand-in for me into the game to try and give everyone a better experience.

What this all means is that, in a way, everyone who plays Rank: Warmaster is going to get a decent idea of what it would be like to play a tabletop role-playing game run by me. I hope I can be a good Storyteller for you.

Hi all. This is your UI/UX Artist Paul with more bit-by-bit developments on the new upcoming mouse cursors. 

The mouse cursors in-game are going to be (like all cursors really) context sensitive and therefore change appearance depending on the situation. For now, the main contexts are basic, over-clickable, and over-disabled. This is once again an exploration into minimalism, as the cursor will never be too large. Below are some examples of the "default" cursor in its "inactive" state (just existing), when it's hovering over a clickable item in-game, and when it's over an item that has specifically been grayed out or made non-available. The latter has two conceptual forms to get a feel for how to convey a button has been disabled. An "X" is universal, but making the cursor implode or "shrink away" might be another visual element to consider.

Further work on this is to come out with feedback from development team members.