![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
I know that my project supervisor in the last year of university told me never to say this and everything, but things are really going quite well now. After where I was heading was very vague for a while and feeling my way while writing most of the game, my increasingly bulky notes.xls file now contains a solid tree of enterable levels and obtainable abilities that eventually lead the player to getting to eight bosses that will together allow you to finish the game. I'm filling out the actual content in the form of the levels now, and once a skeletal path is walkable with those, then it's finally, finally a matter of polishing up the existing content of the game, then adding as much extra content in as I can stand before releasing it at some point before I retire.
Right back at the start of the project the decision was made to make interaction with external files a large part of how it worked, rather than just having a monolithic and difficult-to-change MMF game file - this was something that I'd experimented with all the way back when I made Treasure Tower, but not on anywhere near this scale. As the hub-based platform game I was making began to mutate and accidentally turn into more of an RPG by the week, it got to the point where even my external rules files were too unwieldy and incoherent to keep track of, and an effort to try to lay the whole thing out in a spreadsheet led to the whole thing becoming a large collaborative effort between Java and MMF - the Java portions of the project are there to process and keep track of the information in the game rules spreadsheet, telling me about the game's balance as well as actually writing the rules files for the game to use. The process isn't entirely outsourced to Java because the game's physical layout still has to match up to what the spreadsheets says should be there - an extra synthesis recipe, for example, has to exist in the level for the taking and be obtainable by the abilities that the spreadsheet says it is for the whole thing to work, because it doesn't have a concept of the layout of levels. That connection has become my main role in making the game now, with the statistics and data being handled by three Java programs.
The Rules Writer
Oddly this wasn't the first bit of Java that I put together for the game, because it certainly makes the most sense. For a while the spreadsheet existed just as a convenience of layout for me, and the game didn't reference it at all - but what began as a convenience of layout quickly became an inconvenience of keeping anything up to date or resembling anything to do with the game at all. That changed when I realized the stupidity of having to copy every change I made in the game to the spreadsheet that described the plans that I'd made, which led to the idea of instead making the game rely on the spreadsheet itself. Of course, making the game rely on data direct from an Excel spreadsheet would make it too easily editable (and parsing through it every time would be prohibitively slow), so this Java portion takes the spreadsheet and interprets it into a set of separate "rules files" for the game to reference - which can then be encrypted for the final release.
The Rules Writer is actually composed of several different parts, each of which loop through pages of the spreadsheet and gather data from them, referencing other objects as they're needed - one class writes out the matching of synth ID numbers to shortened item names to full item names, and later on another one would use some of this data when writing out the possible items that can be dropped by monsters or picked up on certain levels. In this way the spreadsheet is acting as more of a database, with the references between the tables only picked up on by this program when it tries to interpret them. My error checking routine could be better - in fact when it encounters something that's missing it'll just give out a couple of co-ordinates of the cell that went wrong and leave me to work out why myself, but it's adequate for what it does.
The Player
What the Java section of the project was originally written for was simulating a player going through the game, to explore what was possible and what wasn't at each point - when you have even just a few levels open and multiple different things to do in them, each of which rewards you with a different item, it's difficult to keep track of the routes that a player might take to progress, or make sure that there aren't too many or too few avenues to explore at any time. I realized this a while ago and created the Player, which reads in all the available data from the spreadsheet and uses it to construct a State, a representation of the state of the game when the player is in the hub level that keeps track of the player's inventory as well as how many objectives have been completed on each level. By using the same criteria as the game itself for whether a player can enter a level or not, it's possible for it to run through the game automatically and point out if something that's meant to happen is impossible or whether there's a way of getting somewhere that I hadn't expected too early.
This was all automatic until recently - the computer would build up a list of possible moves it could make and then pick one at random. But recently, I reworked it to present its list of possible moves and ask which one to do, turning into something oddly like a text adventure version of the game. It's a way for me to check the available paths through the game much more quickly than playing through the whole thing, particularly if I change one detail and have to go through it again to check that it hasn't wildly upset the balance. (I might release this version as a pointless extra!)
It still isn't a substitute for playing the game itself to check the actual difficulty of the missions that you're sent on, because the Java player can just call them done if they're logically possible - balancing actual difficulty, particularly on a game that you've been familiar with for the last two years, is a different challenge entirely.
The Statistician
This is the newest addition to the family, and also the simplest, as it uses a lot of the functionality of the two parts that were written before it. The statistician is another aid in balancing out the game - it simply takes the initial state of the game, as used by the Player, and looks at every objective and level available, counting up the occurrences of each item and the use of each ability to report on how often each appears, to make sure I'm not overusing or underusing anything. If I get really ambitious with this I might also give it the task of looking at the various synth recipes and calculating how likely you are to find the necessary items for them given the possible value of the Luck statistic at the time (which is increased as you get further into the game), but that's become something of a secondary consideration for the moment because it really needs the rest of the game finished before I even have a hope of deciding on the possible recipes.
Basically the development of this game is all a vicious circle with each part relying on everything else, and that's something that I can't really escape. But with everything outsourced to a data spreadsheet and giving myself as much help as possible, I can at least make it fluid enough to easily play around with as it takes shape. For now, more levels are the objective - I'm faintly optimistic. Not of finishing the game at any time soon, that is - just that it might theoretically be complete at some point in my natural lifetime.
Right back at the start of the project the decision was made to make interaction with external files a large part of how it worked, rather than just having a monolithic and difficult-to-change MMF game file - this was something that I'd experimented with all the way back when I made Treasure Tower, but not on anywhere near this scale. As the hub-based platform game I was making began to mutate and accidentally turn into more of an RPG by the week, it got to the point where even my external rules files were too unwieldy and incoherent to keep track of, and an effort to try to lay the whole thing out in a spreadsheet led to the whole thing becoming a large collaborative effort between Java and MMF - the Java portions of the project are there to process and keep track of the information in the game rules spreadsheet, telling me about the game's balance as well as actually writing the rules files for the game to use. The process isn't entirely outsourced to Java because the game's physical layout still has to match up to what the spreadsheets says should be there - an extra synthesis recipe, for example, has to exist in the level for the taking and be obtainable by the abilities that the spreadsheet says it is for the whole thing to work, because it doesn't have a concept of the layout of levels. That connection has become my main role in making the game now, with the statistics and data being handled by three Java programs.
The Rules Writer
Oddly this wasn't the first bit of Java that I put together for the game, because it certainly makes the most sense. For a while the spreadsheet existed just as a convenience of layout for me, and the game didn't reference it at all - but what began as a convenience of layout quickly became an inconvenience of keeping anything up to date or resembling anything to do with the game at all. That changed when I realized the stupidity of having to copy every change I made in the game to the spreadsheet that described the plans that I'd made, which led to the idea of instead making the game rely on the spreadsheet itself. Of course, making the game rely on data direct from an Excel spreadsheet would make it too easily editable (and parsing through it every time would be prohibitively slow), so this Java portion takes the spreadsheet and interprets it into a set of separate "rules files" for the game to reference - which can then be encrypted for the final release.
The Rules Writer is actually composed of several different parts, each of which loop through pages of the spreadsheet and gather data from them, referencing other objects as they're needed - one class writes out the matching of synth ID numbers to shortened item names to full item names, and later on another one would use some of this data when writing out the possible items that can be dropped by monsters or picked up on certain levels. In this way the spreadsheet is acting as more of a database, with the references between the tables only picked up on by this program when it tries to interpret them. My error checking routine could be better - in fact when it encounters something that's missing it'll just give out a couple of co-ordinates of the cell that went wrong and leave me to work out why myself, but it's adequate for what it does.
The Player
What the Java section of the project was originally written for was simulating a player going through the game, to explore what was possible and what wasn't at each point - when you have even just a few levels open and multiple different things to do in them, each of which rewards you with a different item, it's difficult to keep track of the routes that a player might take to progress, or make sure that there aren't too many or too few avenues to explore at any time. I realized this a while ago and created the Player, which reads in all the available data from the spreadsheet and uses it to construct a State, a representation of the state of the game when the player is in the hub level that keeps track of the player's inventory as well as how many objectives have been completed on each level. By using the same criteria as the game itself for whether a player can enter a level or not, it's possible for it to run through the game automatically and point out if something that's meant to happen is impossible or whether there's a way of getting somewhere that I hadn't expected too early.
This was all automatic until recently - the computer would build up a list of possible moves it could make and then pick one at random. But recently, I reworked it to present its list of possible moves and ask which one to do, turning into something oddly like a text adventure version of the game. It's a way for me to check the available paths through the game much more quickly than playing through the whole thing, particularly if I change one detail and have to go through it again to check that it hasn't wildly upset the balance. (I might release this version as a pointless extra!)
It still isn't a substitute for playing the game itself to check the actual difficulty of the missions that you're sent on, because the Java player can just call them done if they're logically possible - balancing actual difficulty, particularly on a game that you've been familiar with for the last two years, is a different challenge entirely.
The Statistician
This is the newest addition to the family, and also the simplest, as it uses a lot of the functionality of the two parts that were written before it. The statistician is another aid in balancing out the game - it simply takes the initial state of the game, as used by the Player, and looks at every objective and level available, counting up the occurrences of each item and the use of each ability to report on how often each appears, to make sure I'm not overusing or underusing anything. If I get really ambitious with this I might also give it the task of looking at the various synth recipes and calculating how likely you are to find the necessary items for them given the possible value of the Luck statistic at the time (which is increased as you get further into the game), but that's become something of a secondary consideration for the moment because it really needs the rest of the game finished before I even have a hope of deciding on the possible recipes.
Basically the development of this game is all a vicious circle with each part relying on everything else, and that's something that I can't really escape. But with everything outsourced to a data spreadsheet and giving myself as much help as possible, I can at least make it fluid enough to easily play around with as it takes shape. For now, more levels are the objective - I'm faintly optimistic. Not of finishing the game at any time soon, that is - just that it might theoretically be complete at some point in my natural lifetime.
