This blog post is taken from our site at www.dreamharvest.co.uk where we share our thoughts on the industry as well as sharing our development of our first major release, Failure. This week we are discussing one of our systems, the Compiler.
Hi everyone,
This week Leigh is going to be discussing the Script Compiler System he has been designing for the Multiplayer component of Failure.
Over the coming weeks we’re going to be sharing some of the systems that we are designing and most importantly, get your thoughts on whether you think these systems will be fun to play around with.
We are also going to be launching our new Failure Newsletter from the 1st of September. The newsletter will contain some exclusive information about the development process as well as exclusive video devblogs where you can get to know the team behind the game. We’re still going to be sharing some info via these normal blog posts but to get the full low down on Failure’s development sign up to the newsletter by clicking here.
Anyway, I better let Leigh take over now, I seem to be hogging the blog again.
Evening All,
Firstly I should probably introduce what Failure is for those that dont know. Failure is a Narrative driven persistent multiplayer RTS with deck building.
As a player you are able to build decks of abilities, these abilties we call Scripts. We didnt want to just give player's random Scripts, but instead add a layer of depth to the system in which Scripts are obtained. With that in mind the Compiler system was designed.
The basics are as follows.
Scripts will be made up of specific combinations of Code Fragments. The player uses Scripts to influence the game and are categorized by Constructs and Functions. Constructs are our games' building type and each has several different effects such as directly attacking enemy Units or expanding territory. Each Construct also can spawn new unit types. Functions allow the board to be manipulated in different ways such as creating a shield or shaping the play space by raising and lowering the hex cells.
These combinations will be unlocked with Blueprints that are earned through player progression and gameplay rewards.
Code Fragments will be available as gameplay rewards, when disassembling unwanted Scripts and to buy in as randomized Fragment packs within the DarkNet in exchange for credits.
Along with being able to create new Scripts there will be a Modding component to the system which allows for augmenting the stats of the Script at the point of creation depending on the type of Mod that is added.
I have the basics of the system mapped out along with a paper mock-up of how it could look and worked out how the player would use it. I’ve even started to work out what sort of combinations can be gained from certain shapes made up of isosceles triangles that fit within a hexagon (so far I’m up to 42, I fear I will lose the will to live before I even get close to the final combination). There are still some decisions to be made on some aspects of the Modding component which basically comes down to balancing and the limitations that would need to be put in place.
The main question that has cropped up is this, will it be fun and add value or will it waste the player’s time and clog their experience?
It is agreed that this system is required, that’s a given, the question arises in how deep the system should go. I originally had it designed in such a way that the Compiler had four main functions, Creation, Upgrading, Maintenance and Destruction.
Creation and Destruction are definitely in. It has since been decided that upgrading a Script must take place when it is created in the first place so that eliminates the Upgrading function as being on its own.
The one that seems to have divided opinion is Maintenance.
Maintenance of Scripts is required in order for the player to carry on using the Scripts they have earned and modified.
Scripts become degraded through use. By using Code Fragments to repair them, the player is able to keep the Script in their Library.
If a Script is completely degraded, the Script and any upgrade it has is lost.
The more powerful the Mod on the Script, the more often the script will need to be repaired.
Maintenance also costs an amount of Credits, based on the amount of repair required as well as the power of the Script.
The long and short of the argument is that this function could add more of an inconvenience to the player than it would add fun, the other side of the argument is that it adds some extra value to the Code Fragments that are awarded in game for later level players instead of constantly building up an inventory of useless items as well as some extra element of strategy risk/reward to the Scripts in general.
At the moment I’m not sure which way this is going to go. With it likelihood of it being a big piece of work to implement, I think Maintenance is one of those mechanics that won’t just be a “stick it in and see how it plays”. We are going to have to make a decision on it.
Personally I think it could work, though I completely understand the flip side of the argument. With the right level of balancing, I think it could become a mechanic that fits and adds value.
Do you have any thoughts? Any considerations we may not have come up with? Have you worked on something similar? Does this remind you of a system we should have a look at? Please let us know on Twitter, Facebook or in the comments below.
You May Also Like
