|Headline:||Coding Away, Thur. May 30 2019|
|Date:||Thursday, May 30, 2019|
|Posted By:||Plaid Hatter Games|
For starters, a lot of those locations are places the player will never go. I mean, yes, if they decide to walk onto a random deck just to see if they have planted wheat or corn this season, the game should support that. But for low-traffic (at least game wise) areas of the ship if I bog the system down with descriptions for everything planted field, water tank, and locked closet the game will grind to a crawl.
At the same time I am anticipating a day when:
In a system where I only support locations that were burned into the game from the start, I essentially tie my own hands until EVERY location has been fleshed out. And pushing new game modules (i.e. DLCs) gets to be a pain. I am expecting people to put a lot of time into their worlds, and having to throw it out to load a new set of stories would be bad.
Instead I am going to take the approach used in Minecraft. There is a massive world out there. I have formulas and snippets of text to generate what you would see at any point out there. But until the player actually goes out and observes a part of the ship, or unless the story demands we have an actor off-scene do something in it, we don't have to cement any of those details.
The other trick I am going to use, which may well be unique for game engines like this, is to implement a plugin architecture for "world" models. The Iliad is a "world". It is broken into regions. Those regions have levels. Those levels have structures. Every one of the above can be expressed succinctly as a row in a database. When the plot mentions a new object that isn't already part of the game, it can search for a matching object in one of the worlds that is connected, and developed rules based on:
Reacting to where the object was found lets me form one kind of object if the record was found in the "level" table, and a different one if it was found in the "structure" table. These types of objects can have different rules about navigation, for instance.
The information stored in the database allows me to, for instance, find an otherwise unallocated commerce structure and designate it as the local pub. So that the next time the system tries to find the local pub, that record pops up instead of having to be recreated. And as an added bonus, the structure can now appear on the map as a pub instead of a generic commerce space. The nice thing is that I don't have to alter my structural model of the ship. All of this record keeping is done in the game save file. (Or at least most if it.)
I am anticipating that some story lines will take the player off the ship. Let us suppose that the Iliad meets up with the devious Krasnovians, and we need our character and her crack team of cyborg/clone/superpeople to repel a boarding party, and then take over the other ship.
Well... the Krasnovian ship is going to have its own layout. Now the player can only "be" on one ship at a time. So for this case we would un-attach the Iliad model as our ship and load the Krasnovian deep space cruiser in its place. The game can remember things about the Iliad for when we (hopefully) return. But when it goes to fish for an unknown location now we want locations on the Krasnovian ship.
Space stations and planets have some slightly different rules, but same concept applies.
Where life gets really interesting is the cyberpunk/holodeck/VR scenario. In that scenario our player is still, technically, on the ship. And in the cyperpunk case, we still need to refer to the existing ship model. We just end up navigating it completely differently. Instead of hallways, the player moves across network circuits. Instead of doors, they are stopped by firewalls. Processes on the ship take on a personality, but they have a footprint into that other world. Changes in either world cause changes in the other. Shut down a rogue program, and it could cause trash collection to cease. Or the reactor 5 to stop overloading. Destroy a server in the "real" world and a chunk of the the cyber world will De-Rez.
In that case I would need two (possibly more) worlds loaded at the same time. With the ability to add or remove worlds as the plot sees fit. In actuality my other cases (changing ships, landing, away missions) are just special cases of this more general case. And thus, this plug-in architecture seems to be worth the added complexity.
I'm early enough into the development effort that adding the hooks to support world plug-ins took less time than it took for me to explain why I needed it.
Also... don't be shocked if I just go ahead an throw that cyberpunk story arc in at the beginning.
As of today I can spin up a new game, load the Iliad model next to an empty save file, and start the player off in the land of "Nowhere". Throughout the next few days I will work on the rules that allow locations in the Iliad to interact as location objects in the clay engine, as well as a system of having a quest in Stage ad-lib locations based on searches on the Iliad model.
The story will start off with the player waking up in his or her room. He or she thinks this is their room at the Academy. The walls are decorated the same as they had in their old room. The sheets are the same. There are marks on the desk where the player had gotten bored years ago and etched something in. The computer terminal is logged in as them. They vaguely remember graduating. There was a diploma. But he or she can't remember how they got back to the room.
All of the details are just a blur and getting blurrier.
The first thing that is off are the windows. They ... they don't lead outside. They are just flat panel displays showing scenes of the outside. Opening the door doesn't go into the dormitory hallway. It leads to an apartment. Your apartment on the ship. Throughout the room are hand written notes, formal training manuals, and even a welcome video on the television set.
And I think that's as good a beginning as any. ;-)