Search This Blog

Friday, 24 December 2021

Join the Rising!

A quick one today, just to try to cast the net wider with my Phoenix Rising project. For those of you who don't know, this is my iteration of Firestorm Armada, based on the old SG game in terms of play flow and statistics, which I've spent a long time picking through both whilst working with Spartan Games as Spartan Alex, and since.

Join the Facebook group using the QR code here;

There's also a link to my Discord Group 

https://discord.gg/q7GbgehGMm

Come and Join the Rising!




Tuesday, 21 December 2021

Phoenix Rising - Mines

Mines in FSA never really felt like area (volume?) denial weapons, their main use was typically as drive-by bombs. Mines also tended to be dangerous to smalls and mediums rather than large ships (though not exclusively and we all had the odd success more generally). Still, they were relatively easy to deal with - fly something relatively sturdy or disposable into the area, clear the mine and move on. The blast radius was big (4") and persisted in theory, but as that was too big to really drop a template, plus move models etc, it was generally "ruler around the marker" measuring, which could then get forgotten if the mine was removed after detonating. it was just a little clunky, though not necessarily urgently broken, it felt unsatisfying in many cases. Of course there was the whole issue of the "drive by" as well, and this does fix that, but actually my aim wasn't to address this specifically, but more how mines worked at a grass-roots level.

I wanted to go back to basics with mines, and think about their use as volume-denial weapons. They should be dangerous but not insanely so, forcing difficult choices on players. I've opted for the following solution;

  1. Mines are persistent. They stay on the board during the game unless removed by a specific mechanic, so the "kamikaze minesweeper" is gone.
  2. Mines have a smaller area of 2" radius, and as they're persistent, they can be indicated on the board by terrain (card circles)
  3. Ships only have enough mines for seeding a single area, unless a MAR gives them more (preventing the board becoming one huge minefield!) (edited)

This (hopefully) has several effects;

  • Mines are now true area denial weapons - or at least, they deter enemies from certain routes, allowing ambush techniques etc
  • Mines become something you need to time appropriately, rather than just fart out whenever in the hopes of catching something at some point
  • Measuring and effect determination becomes simpler, without cluttering the battlefield with things ships can't be placed on.
  • Although more dangerous to small ships, they also have the speed and manoeuvring power to avoid them most easily, smoothing out their effects across ship types
  • Facilitates minesweeper ship types to remove them
So how does this work? Well mines are laid after movement, placing a Mine Marker (a 2" radius circle with the mine value on) half way under the rear of the models' base. These mines remain inactive until the end of the parent models next activation. This prevents the unavoidable "drive by", as ships in the wake have a chance to manoeuvre away before these go live. I say a chance, because if the player can lay the mines late in the turn and activate before those in its wake, it could get a successful drive-by. Of course your opponent knows this and is going to try to activate before that happens, but then it's a matter of priorities - is that more important than activating your battleship and getting that killer shot?

I went for this as it provides more "meaningful choices" in a game, which good games are all about. It's no doubt that no-one wants to fly into an active minefield, but if those two frigates chasing down that carrier happen to do that because you have higher priorities, that's just bad luck for them, right? On the other hand, maybe those two frigates can take that wounded behemoth down, and they absolutely need to survive. You can imagine situations where a cruiser group could get an optimum RB2 shot if it went through the minefield, or attempt an unlikely RB3 shot by going around it...which is best? Only you as the player can ultimately make that choice, and given 100 people asked exactly that, each will have their own decision and rationale for it - it's not a given either way. I think this also allows some nice scenario possibilities, and adds some real value to the Minefield MAR. Aquan Drone mines become terrifying (though I've an idea for balancing that), but very thematic.

So what does everyone think? Feel free to comment below!

Wednesday, 15 December 2021

Phoenix Rising - Rationale and Musings

So those of you following the Facebook group will have seen that I've renamed the game I'm working on to "Phoenix Rising". It follows from a couple of comments made on some discussions, and I had a think about it and thought, "You know what, they're right, time to rename to something actually chosen!". I like Phoenix Rising because it symbolises the struggles of the broken parts of the human empire, reflecting the old FSA lore, and the Novus Populi symbol also kind of looks like a heavily stylised bird...so yeah...Phoenix Rising it is.

Now I've also been working with a sculptor to produce new models for the game, and I started off by "filling in" some of the blanks in the prior catalogue, as these were a "no risk" option. You'll have seen both renders and prints of them on Facebook again, I hope. Next is the NPN themselves - one of the main protagonists of the game. I wanted sculpts that would sit alongside existing models without looking odd, but also be my own visual style. I hope you like what's been done so far.



I've also been working on overhauling the rules. Working from scratch on such a complex project is tough, especially when you're busy at work with two product launches in the continuing pandemic, but one of the things I have to lean on (and I don't want to lose in my game) is the sound statistical bedrock of what went before. This means I can tweak (or in some cases completely change) mechanics whilst not totally breaking the game.

Another thing I always wanted to do was to link the models much more visually with their game stats. It never made sense in game that these models had the same HP

That's just one example - there are many more. That's because there was a fundamental disconnect between model creation and stat generation - models were made to be cool with a general remit of what was wanted (by Neil), and then the stats were created to fit the remit in a balanced way with the game....it should ideally be the other way round, creating a model that fits the pre-determined, balanced stats which fit the areas in the game needed. 

This was most starkly revealed to be coming unstuck with the taskforce reinforcement boxes towards the end of Spartan's demise, with various "light" versions of models which, while showcasing some of the improvements in multi-part model making and casting spartan had achieved, were put in the area of the rules which had the least room in terms of design space. Here's a graph just to illustrate what I mean, with ship mass (x axis) plotted against Hull Points.


You can see there is a rough correlation, but it's just that, and it really starts to fall apart when you start to focus on individual areas - look at the spread in mass of 10 Hull Point ships - there is a three fold difference between the smallest and the largest which is hard to reconcile visually in game (at least for pedants like me!). Now you could say "Oh well, different races have different ways of doing things", but the inconsistencies aren't restricted to the broad picture, but within races too - here's the same graph with only Aquan ships;


Again, you can see a 4 HP ship which is smaller than a 2HP ship and a 5HP ship, 6HP ships significantly smaller than 5HP ships and 9HP ship smaller than a 7HP. That doesn't really make much sense and doesn't even take into account the "old" sculpts either, which were generally smaller than the more recent Spartan designs.

As I've been looking at this since v1 of the game, now seems an ideal point to implement this adjustment, and it has some interesting effects on factions that make thematic sense. It also leads to some adjustments in stats to make things more predictable and balanced. In fact, when you look at it across the spectrum of models, it actually leads to some fairly indicative racial traits that provide additional flavour to factions. Here's a plot of all FSA ships with HP adjusted by mass;


Now of course the exact distribution here can be tweaked, but broadly speaking the levels are set to change the minimum number of ships possible - so in short, most things stay the same, some change. One of the most notable areas is at the bottom, where a number of smalls drop from 2Hp to 1HP. Whilst some might balk at that change, it actually helps with a couple of aspects in SG FSA, those of the complexity of dealing with calculations for squadrons with high numbers of small ships with some damaged ships, and that of "zombie ship syndrome"...in smalls this is usually due to damaged and reduced squadrons becoming ineffective. Reducing a lot to 1HP wonders makes them die faster, but will also be reflected in their points cost - more on that in the future.

Going back to this example;


This now means that the small corvette has 1HP, whereas the large Frigate has 3HP, which "feels" more in line with the models.

Thursday, 18 March 2021

Future Space Apocalypse - The Why

I started writing this back in January, but back then other events overtook it, and it languished unpublished until now, when I thought it might be a useful insight to some who question my sanity for embarking on this venture...

So at this stage it's very apparent that Warcradle's iteration of v3 of Firestorm is quite a departure from SGs v2 - not in itself a bad thing, but also not quite what many in the community were expecting. To me, the changes made are not necessarily detrimental, but they just make the game feel different - like playing Dropfleet or Full Thrust - games that existed during FSA's existence too, and have some nice mechanics. The thing is, I have Dropfleet, though I've never played a game in earnest, mainly because I had Firestorm and it scratched the itch...and Dropfleet felt different. 

So I come to the main point of this blog - FSA (Future Space Apocalypse). I started work on this even before SG went bust, as a continuation of the work that the FFG and myself had done for SGs FSA v3 before Neil took a different route with its development. The development worked on elements that the community had fed back that needed tweaking - not all of these were universal (for example, movement, which was seen as more of an issue in the US than Europe). So broadly speaking the big areas are;

  • Game speed
  • Movement (making it faster and less "fiddly" with the old template)
  • SRS & PD "wall"
  • Link fire calculation
  • Boarding
  • Cyberwarfare
  • Small faction rebalancing (Aquans & Sorylians were variously called out as stronger and weaker factions)

Then some smaller elements were;

  • "zombie" ship syndrome
  • Number of tokens
  • Iterative dice rolls (part of game speed above)
  • Some fleet building & battle log hurdles (making some ships more or less appealing due to their place in the fleet building or number of BL points they yielded on destruction)
  • MAR "bloat"

Some of these things are relatively easy to fix, some require a more fundamental change, and the underlying aim was not to change core mechanics so the game didn't change overall - widely being seen as being pretty good and one of the most balanced of systems out there.

As an example of game speed, the FFG discussed shields, as this is one example of an iterative dice roll (one player rolls, then the other, before the outcome can be determined) - and talk was had of making shields a sort of static boost or reduction. The problem with that is that it removes player agency and alters the "feel" of the game -especially for shield-heavy factions, so it was dismissed as a concept. However, using different dice mechanics can retain the agency but still speed up the game - hence Shields moving to "basic" or "black" dice, where successes are on a 4,5 & 6 and don't explode. 

At this point I'm sure Terran players are having a heart attack as this obviously reduces the average hit reduction from 0.8 to 0.5, and of course this switch requires adjustment of the shield numbers on ships, but this also has several beneficial consequences - it "caps" the top end, making shields feel more believable in the game (we've all had experiences of an SH1 frigate resisting a huge attack by a string of lucky sixes), but it also makes Shields more reliable - especially at the lower end. So an SH1 ship with exploding dice has a 50% chance of the ship blocking absolutely nothing, whereas a SH2 basic dice shield ship only has a 25% chance of the same null result. This change then also allows you to play with dice mechanics - shield modulators can "bump" the dice up to "blue" or "heavy" dice, making the shields more effective very easily.

So although many people think that tweaking Firestorm is a quick job requiring nothing much more than changing movement, there are many things which are very interconnected. It just so happens that I started looking at this way back in v1 of the game with the custom ship creator, and trying to adapt that to a more balanced thing, and then adapt it for v2. Turns out that's not easy - how do you truly evaluate the effectiveness of a weapon in FSA - a game which is all about positioning and timing in many ways - when so many things affect it...the ships movement, other ships movements, DR, CR, what type of ship is firing, what sort of weapon, what range, what MARs exist on both ships....it's a huge and extremely complex network, and so I started creating what I ended up calling the "Battle Log calculator", which looked at all these elements for every ship in the game. I almost finished it as my time at Spartan ended, and then it lay fallow for many years until now, when I've resurrected it to help me finish Fanstorm.

This project uses probability curves based on al the mechanics of the game, and plots these out per ship, in all squadron sizes, in all damaged and undamaged states, together with modifiers for movement, MARs, Scenario effectiveness across the course of a game etc. It's been a HUGE labour of love (and horrible grind at times!) to create, but I wanted to have something that wasn't just based on "gut feel", but based on facts and data and that could be adjusted to represent changes to ships through design. This also means it can be used to create new ships...otherwise known as a custom ship generator...and give them appropriate costs and BL points.

There are two main elements to this - threat potential and threat resistance. Let's look at this in a bit more detail;

1) Threat Potential

Simple put, this is how threatening a ship - or group of ships - is to other ships in the game. The obvious point to start here is with AD vs DR & CR - that's an easy thing to analyse, and for any AD value you can see the probability curve of how likely it is to breach the DR and CR of a given target. Of course, range has an impact, since AD vary by RB, so now you have four values for each ship. Now, because AD degrade with hull damage, you really need to see the degradation through a ship's damage state, creating its HP value x 4 values....and if its a capital ship then the probability changes if its firing at a non-capital ship, and for a squadron you really need to look at each number of ships in a squadrn at each damage value.....

You can see how this set of probabilities quickly escalates when just considering a single squadron in Firestorm. Then you have types of weapon and firing arcs, and time in the game. For example, an Aft-firing weapon is of absolutely no use in most games for at least two or three turns, whereas a Kinetic FF weapon RB3 & 4 weapon is great in the opening couple of moves, but the likelihood of getting a shot at those ranges later in the game is vanishingly small. A high AD RB1 primary weapon is not of much use to a slow capital ship, especially in the early stages of the game, but to a high-speed, manoeuvrable corvette, that same weapon has much greater utility.

So how do you deal with this huge complexity? Simply put, you model it all out. The numbers seem unmanageable (and they are if you're trying to do it manually), but to a computer this is much easier - it's just data. Putting the data in takes a long time, but when its there the manipulation is relatively easy. So yes, I went through every scenario and looked at each weapon type in each arc, and what it could threaten in each turn through the game. Now it's impossible to look at every iteration (well, not impossible, you could write a program to do it I'm sure, but I'm not that good a programmer), but you can look at areas and probabilities. Ships have set starting points and bounded movement parameters, and the game area is likewise fixed.

So if you know where and when a weapon can threaten an enemy, and what threat that weapon then represents to an enemy, that's a set parameter that can be given for every weapon stat in the game. As they're all contained by the same parameters, they're directly comparable - they're relative measures. As we now have a value for each of these, you can sum them up and create an overall value for any given ship with any combination of weapons. The details are expansive and numerous, but the concept and end result is simple.

2) Threat Resistance

Once we have a measure of the threat potential of ships in the game, Threat resistance is pretty much the inverse of that - how well can a ship resist the potential threats in the FSA universe? Again, this is a combination of DR, CR, range, defences, MARs etc and the threats posed against all of that at each stage in the game. For example, a DR6, CR10 PD 5 SH2 ship 46" away from an enemy fleet can only be threated by Kinetic weapons and torpedoes, most of which have very little chance of penetrating its defences. A DR3 CR5 SH1 PD1 frigate in a small squadron of two at the same range  has exactly the same threats, but they are more likely to be able to breach those defences. If the weapons fired at them also have a MAR like Torpedo Spook, then they are much more vulnerable. Later in the game, the more ponderous battleship might be less able to avoid RB2 shots from enemies, PD flagging from damage making it more vulnerable to torpedoes and boarding, whereas the frigates can manoeuvre out of reach of Fore Fixed weapons, and group up to ensure that their PD remains relatively high and thus making them an unattractive target for torpedoes.

Once again, not ALL circumstances can be modelled, but as long as representative ones are built into the modelling, the relative measures apply. From the work I did on the v2 analysis, the results bore out many of my feelings and suspicions about ships based on play experience and community feedback. 

Of course, I did all this with SGs v2 of the game, and it wasn't quite finished when I let go of the whole thing a couple of years ago...or rather, it was, put it wasn't where I wanted it to be - I could see areas for improvement. Now that I've altered some elements of the rules, I need to redo all of that, which is why Points and Battle Log values will be the last things that get changed/fixed in all of this.

Future Space Apocalypse Fleet Lists

 As I can't post them on Facebook at the moment, here is the complete set of Fleet Lists in the new v2 format.

https://www.dropbox.com/preview/Public/Relizane%20Fleet%20List%20v2.pdf?role=personal

https://www.dropbox.com/preview/Public/Consortium%20Fleet%20List%20v2.pdf?role=personal

https://www.dropbox.com/preview/Public/Dinfore%20Fleet%20List%20v2.pdf?role=personal

https://www.dropbox.com/preview/Public/Sahalia%20Fleet%20List%20v2.pdf?role=personal

https://www.dropbox.com/preview/Public/Arquili%20Fleet%20List%20v2.pdf?role=personal

https://www.dropbox.com/preview/Public/Terran%20Fleet%20List%20v2.pdf?role=personal

https://www.dropbox.com/preview/Public/Alliance%20Kursk%20Fleet%20List%20v2.pdf?role=personal

https://www.dropbox.com/preview/Public/Zarian%20League%20Fleet%20List%20v2.pdf?role=personal

https://www.dropbox.com/preview/Public/Independent%20Fleet%20List%20v2.pdf?role=personal

I appreciate some of the content isn't 100% correct at the moment as I'm still going through MAR updates in the lists, but at least all the basic stuff is up and now its in this format it's super easy for me to update - so please let me know of any corrections, queries etc.