Blue Fire Dawn

I’m implementing skill checks in BFD right now and got to wondering about dice probabilities. One of the things I wanted to try and avoid is using pure probability values in the belief that by using a dice based system people will have an easier time visualising what’s going on behind the scenes and can discuss it better. I also want to attract fans of tabletop gaming.

I have experience mostly with DnD and Games Workshops games and to be honest I always felt that both of them are lacking in opposite areas.

DnD (4e specifically) is as you hopefully know a D20 based game where your normal skill check is to roll a D20, add your modifiers to it and see if you beat the target skill. This results in some very large numbers being thrown around which can get a little confusing and having double the skill not always meaning you’re twice as likely to succeed.

GW games on the other hand prefer stats that only tend to range between 0 and 10 with 3’s being considered “average”. Most skill checks with their systems depend on looking up the two stats involved and finding a target value for a D6 roll. Normally if the two stats are equal then this would be a 4+ (50%) if your is 1 more than your opponents it’s a 3+ (66%) and if it’s more than double it’s a 2+ (83%).

I like the small stats of GW games but not the probability distribution. If I have double the weapon skill of my opponent I should be twice as likely to hit them (75%) and if I have triple their skill I should be twice as likely again (88%).

These values only come up when dealing with re-rolls though. A 4+ on one D6 with a Re-roll is a 75% chance of success (and with 2 re-rolls it’s 88%). So I could say that having double the skill of the target lets you reroll a failure and triple lets you reroll two failures. This sounds great but it makes having a slight 1 or 2 point advantage useless.

So I ask the tabletop playing public who have no doubt done the maths on this already: Is there a dice system that would give me the distribution I crave with the granularity needed?

As the topic says. Multiplayer is hard. If you are a games developer who has only ever made single player games before then you have absolutely no idea the headaches that are involved when you try to make a multiplayer one. They are many and painful.

I am of course talking about my new project “Blue Fire Dawn” and you would be forgiven for thinking that making a Turn Based game multiplayer would be easier than a real time one. It isn’t. With a real time game you can be quite sloppy - it doesn’t matter if you drop a couple of packets because there are so many small updates being sent every second that another one will be along any moment now. Turn based games on the other hand are all about synchronization. When a player tells the server that they want to do something they are usually sending a big long list of commands all at once which have the potential to arrive out of order at the server which has to put them into the right order. Then the server has to make sure what the client sent it is even legal before executing it, rolling dice and sending the results back to all the clients. There is a lot of waiting and validating going on that real time games don’t need to care about.

During an interview with Rock Paper Shotgun the Firaxis guy said that making XCOM was a huge scary project. This is a sentiment recently shared by the makers of Xenonauts. Now consider this: With what I’m working on now I could potentially make either of those games and I’m trying to make it work in Multiplayer. I’m clearly insane.

Here is the thing: It is working in multiplayer. About 3 weeks ago I had a rubbish prototype that worked in single player. Since then I have a rubbish prototype that works in multiplayer (with the exception of the revamped abilities system which I’ll get to). I’ve had to do lots of very boring things like login procedures, replication, lobbies and handling reconnecting clients (If you drop from a game and reconnect within 5 minutes then it’s as if nothing happened. Take longer than 5 minutes and your characters will disappear and everybody can continue playing) but the important thing is that it works. Levels are procedurally generated and match up between clients and everything updates correctly as things move around the world. It’s awesome.

I clearly haven’t hit the actual hard part of this game yet then. In fact I think I’ve just now run face first into it.

Firaxis and I have managed to independently come up with the same ability system for our games. Alternatively we have both managed to independently “borrow” ideas from 4th edition DnD (it’s this one - shhh). Your characters get a number of Action Points to spend each turn on abilities. Moving normally is an ability and costs 1AP. Shooting at a target is an ability and costs 1AP. Going on Overwatch is an ability and costs 1AP etc. You can do these in any order you want and so long as the ability doesn’t have a cooldown or use limit you can do them multiple times in the same turn.

It’s a bit like time units in UFO but instead of an ability being something tiny like turning 45 degrees or moving a grenade from your belt to your hand they encompass a goal or idea rather than the minutiae of how to achieve it. You’d think this would be easier to implement than Time Units but in reality it really isn’t. Time Units are probably the easiest method to make a Turn Based game entirely because they are so discrete.

Take my current head scratcher: The Charge ability.

Charging is conceptually simple - You can make a move for your full movement speed but it must end adjacent to an enemy who you will then attack in melee combat. In comparison to a regular Move or Melee Attack ability this is a tough one because it combines both of them into one. Add to this the fact that I don’t want to have to code every single ability in the game and have a lofty ideal of being able to assemble them as data and things become so very complicated.

I am also trying to decide whether to let players execute abilities one move at a time or if they have to send the entire plan in one go to the server. I know some people will really want to be able to agonise over each square moved just in case the next move reveals an enemy but there is a lot to be said for having to commit to a plan up front (with seeing an enemy allowing you to abort mid-move or continue - either way your action point is gone) and whatever I decide here can have a significant impact on how I design the abilities system and how it works in multiplayer.

In conclusion: Multiplayer is hard but not as hard as having to design an infinitely flexible system that has to account for an infinite number of unknown variables.