Life In The Frontier 2024 (The road to the final release)

[BeeTLe BeTHLeHeM]

Hello, everyone!

After nearly 10 years I'm ready to start working on my OXP again, and this time should be the last - in the sense that I want to release, in the next future, a finalized version.

I had (and I have) many ideas, and the good people who worked on the OXP during my absence had other ideas (phkb, MassiveLocked, Norby and Cholmondely with so much enthusiam), so there's a great amount of stuff to reassess, integrate and eventually improve. I don't want to put away their work, on the contrary I will re-read the codebase to see if I can learn something new (I'm sure of it).

The main goal is still the same: provide the player something to fill his stops to the various space stations of the Oolite universe, and to build a way to insert more content and flavour into the game.

In the old versions we had a choose-your-own-adventure style interface, to visit directly the main point of interests aboard a station. Then I implemented a BBS inspired to Elite:Frontier. I'm going to reread and rewrite the code to add something more, in small steps.

This time the main inspiration are text adventures (interactive fiction), roguelikes and dungeon crawlers. The Oolite interface is limited but I can put in the menu some movement actions, to allow the player to move inside a map. On the map will be present the point of interests (POI), and the player would interact with them when it is in front of them.

For now, I've written a basic prototype. One single map, representing one floor, Ship Maintenance, where the player hangar is located. The map is this:

basic-floor-map.png (2.06 KiB) Viewed 875 times

As you can see, the number sign character is a wall, the dot is a free space (corridor), and the letters are labels for the POIs: h for hangar, e for elevator, s for storage, d for docks, m for maintenance corridors.

You start in front of the hangar (this is set in the properties of the floor, more on this later) and you can move along the "dots". The screen tells you where you can go and if there's something in the immediate vicinity (in front, at left, at right).
The only interactive POI, for now, is the hangar, that quits the navigation phase. The other POIs are disabled.

Maps can be of any size, it doesn't matter. The only thing that matter is the path you can walk along, the POIs, and the start position and facing.

You can try it if you want. It's very barebones.
https://drive.google.com/file/d/1Z_rGM0 ... sp=sharing

Where do we go from here?

- enabling the elevator to allow changing floors. Therefore, multiple floors with maps and other POIs, to recreate the initial layout.

- enabling interactions with POIs. Once you "enter" a POI, it should display the original interface used in the OXP. I will integrate that part so you'll have bookshops, museums, churches et cetera as they were. Exiting the POI the player will be put on the map again, ready to go.

- adding a map screen that show the current map level layout and a list of the POIs for reference.

- different layouts for different stations types or systems variables (like TL, economy, government). More or less floors, more or less facilities, different POIs.

- expanding the system to other OXP. There are so many good OXP that adds new stations, and I would like to put a way to search for external custom layouts, with their own POIs. I want to put a system to hook an interaction to a function in the same OXP, to find a way to hook to OXP function to get their features seamlessly connected to the map navigation.

This is the main roadmap - and it will take time to implement everything. Unfortunately during the week I spend nearly all day commuting and working, so I mostly focus on the OXP during the weekends (with a little bit of monday and friday).

And there's more.

Once I have a working system and a complete station layout, I'll bring back the BBS as a POIs in the station, like a series of Terminals on the various floors.
Furthermore, I can pickup again the random encounters feature, since they can be integrated into the map navigation, starting with simple things and thinking about more complex events.
And then... station quests with temporary procedural maps.
The last thing it's the RPG aspect, but that's a thing that I would reather leave at the last step since it would be the more complicated thing to manage. Let's see how development will go.

I thank you for reading all of this, and to bearing with my long disappearances from the forum. I thank everyone who tried the OXP and especially those who tinkered with it. I'm honored.

Next time I'll talk about the data structure I'm working for storing maps and POIs.

[hiran]

Adding interactive fiction via mission OXPs sounds very powerful. I like that idea.

When I mulled over rhe same I concluded it would be easier to get good content if the engine were not built from scratch but use something already known in the interactive fiction community.

While there are some open source choices the best prospect was IMHO Ink.
https://www.inklestudios.com/ink/

Yet I could not make out how to package it into OXP.

[Captain Beatnik]

I like the idea and I'm looking forward to the release of the finalized version of the OXP.

[BeeTLe BeTHLeHeM]

Regarding interactive fiction, there are good engines out there, but I prefer to adopt an easier approach as a compromise with the game limitations.

The basic concept is building a dialogue, or an event, as a series of blocks that define various parameters:
- the title
- the description
- the choices

Title and description act as the context of what is happening, while the choices allow for different outcomes. Every choice is associated with one or more requirements (to make it appear in the list) and actions (the consequences of the action or a reference to another block).

The same thing happens with the exploration: you can choose between going forward, turning left or right. Every choice executs a function that re-position the player, and start again the exploration block changing the description (according to what the player sees now). If there is an interaction, the action will run the block belonging to that point of interest. And so on.

I've written a parser that manages the data for events/interactions/exploration, and I'm adding the various action while I add stuff to the prototype.

The data structure I'm using now for the station it's the following:

Code: Select all

{
    startingFloor: number, // on which floor the player appear when disembarking
    startingLocation: string, // label of the poi adjacent to the player when disembarking.
    floors: array, // the list of the station floors
}

The floor array:

Code: Select all

{
    floor: number, // floor reference id (0 - lowest)
    name: string, // the name or title of the floor
    corridorDesc: string, // generic description to use when the player walk along the map
    map: array, // the map of the floor (as I shown in the last post)
    poiCatalog: object, // a list of the point of interests on this floor
}

The corridorDesc property could be an array, so it would choose a random text from it.

The point of interests in the poiCatalog are referenced by their label, a single letter used in the map, i.e. "h" for hangar (but it's arbitrary after all).
The poiCatalog object:

Code: Select all

label: {
    name: string, // the name of the poi
    desc: string, // the description of the poi from outside
    enter: boolean, // player can interact (enter) with this poi?
    enterTrue: string, // if enter == true, this is the relative choice text
    exitFacing: number, // what direction the player is facing when it exits the poi (1 - up, 2 right, 3 - down, 4 - left)
    exitPos: { x: number, y: number }, // coords of the player when it exits the poi
    call: string, // the js method to eval and execute when selecting the "enterTrue" choice
}

The startingLocation property at the beginning is a reference to the corresponding item in the poiCatalog, so I can retrieve the player facing and position and put it on the map.

This structure will be eventually modified to suit the next features, both for a single floor, for every floor or for the station as a whole.

Next I'm going to implement the elevator, where the player can see a list of the floors (that I'll read from the array). Every floor will execute a function that will put the player on that floor outside the elevator tile (using exitFacing and exitPos for the "e" point of interest). In this way the elevator will work automatically for every station layout.

This week I will expand the prototype with a three-floors array as an example. And after this I'll start with the interactions with the point of interests.

[Cholmondely]

There is a detailed description of a Feudal States oxp “Royal Hunting Lodge” if it is of any help (see our wiki page on the lodge). And another of the Commies oxp “SLAPU”.

I’ll need to check our Oolite Fiction, but I suspect that they are the only detailed descriptions of oxp station interiors.

Phkb’s “Hermitage” oxp might well have consequences for a Rock Hermit interior (and he also has a recent alternative outer model for RH’s).

[BeeTLe BeTHLeHeM]

There is a detailed description of a Feudal States oxp “Royal Hunting Lodge” if it is of any help (see our wiki page on the lodge). And another of the Commies oxp “SLAPU”.

I’ll need to check our Oolite Fiction, but I suspect that they are the only detailed descriptions of oxp station interiors.

Phkb’s “Hermitage” oxp might well have consequences for a Rock Hermit interior (and he also has a recent alternative outer model for RH’s).

Yes, if there are other OXPs that add details about station interiors, or some type of interactions, I can check them and see if there LITF can be compatible. If there are conflict I can create a list of non-compatible OXP and disable my interaction option if they are present - obviously the better solution would be the integration.

As I was saying last week, I implemented a lift/elevator in the prototype, it uses a specific function to show the other floors name (not the player current one) as option. The player can choose the destination and exit the lift to be placed in the new floor. That was enough easy.
The other floors have simple maps, with different shape and size. The exitPos and exitFacing properties for the elevator object in the poiCatalog provide me the proper player placement. The rest is the same code as before (if it works for one floor, it works for every floor).

This is the link to download the prototype, ver2:
https://drive.google.com/file/d/18jNx7R ... sp=sharing

Now I'll have to think about interactions - and this shouldn't be difficult. But aside this, I have to read some old documents I wrote and to see the other LITF versions, to pickup every station structure and sketch a "vanilla station" that could be a reference for the other variants (with floors and locations added/edited/removed). I want to define a list of the floors (as generic containers for a certain theme, like industrial, entertainment, religious, management, government etc.), edit and organize it and then, based on that, write a list of the locations they contains and the eventual feature they are associated with. My idea is that locations could offer missions sponsored by a business or an entity, while the BBS could offer mission from private citizens.

[cbr]

Would it be possible to add some kind of image map...



Bitmap or font driven...

While roaming the station any escape key was disabled

[Cholmondely]

While roaming the station any escape key was disabled

Isn’t that more realistic? While roaming my house, I have the same issue!

[BeeTLe BeTHLeHeM]

While roaming the station any escape key was disabled

You mean the ESC key? Or other keys?
It could be the default behaviour since I am using a custom screen, but if you tell me what key doesn't work I will try to determine if it's something I can act upon or not. Thanks for the report, anyway.

Would it be possible to add some kind of image map...
Bitmap or font driven...

This has been the main thought of the last weeks. Since I was thinking about an only-text interface, my solution was to create an ASCII-based map, similar to a roguelike game. But I felt it wasn't the best option, since doesn't really fit aesthetically, and it needs a monospace font, so I should force the player to download an OXP like OCR-A Extended or TTY, or I have to include one of those fonts in the OXP.
I didn't like it, I wanted images, for a tile-map, and I passed some time trying to find a way.

Luckily, I went to see how the station floors map was done in the v0.0.7, and I analyzed the hud.plist. And I found out that I can not only set selectors for text, but for pictures too!

So I created a 10x10 selector grid (I did the work with a little Java help), and I created some simple pictures to display a wall, an empty space, the elevator, a POI and the player with all the orientation. And the rest was all coding.

In a nutshell, I stopped everything and worked on this. Here's the actual result:

And I like it. There are several things to fix (when I close the screen, the graphics remains even if I clean all the selectors; there are some strange errors in the logs about a file not found... things like these), the map should be a little more centered, I should create a legend for the POI (and there should be specific tiles to reference each POI on the map). And I could create a better tilemap. At least it can be done.

Since the selectors are fixed, maps will have a max size settings. I could implement scrolling (I have the code from my old incomplete-roguelike Java games), but like I've already said, I want to keep things simple for now - feature creep is always lurking on the back of my head.

This work made me think that if it's possible to create a graphical floor map, then it's possible to create a graphical station map. I should create another hud.plist and switch it according to the requested screen.

Another idea I had was to create simple backgrounds to visualize the player first-person view while moving in the map, something like the ancient 3D Maze game. This could be done too, maybe with a shorter view distance because I should create every image by hand (or I have to find a way to combine different images...).

But let's go in order. So, for now, I will work on the floor map.

[cbr]

That looks nice and clean...



I presume irregular station interior routes can/could be created this way?

(i did rerun the test.oxz, 'esc' I did not, thankfully I was windowed this time and could escape by clicking [x] )

Perhaps a quick 'back to the ship' option could be handy...

[Cholmondely]

Much prefer this to rogue-like gubbins!

Buon Natale!