« back
59

Forensic Friday 59: Experiments Galore

Intro #

📣David

Hey readers! Welcome to the most delayed Forensic Friday to date! 2 whole days! Probably going to release on Monday, so make that 3 o(￣┰￣*)ゞ. Well, clearly something went wrong in the development HQ to have this occur, but I would argue quite the opposite! A lot of work has happened in the past week as I aim to finish up the main gameplay loop. So further ado… let’s dive into this casefile!

Site Events (In Regions) #

📣David

I’m starting to get tired of these little special headings repeating with every subtitle. Especially since it’s only me speaking in this blog! Perhaps I should only display it whenever the reader changes, but oh well! Distracting things aside… Site events in regions are a thing now. We call them Region Attended Events, which are quite simply events which are attended by NPCs in regions. This comes as a generalisation of the experiment system, which initially was a hardcoded system similar to these Region Attended Events, but with a serious amount of spaghetti and unexpandibility! Reimplementing this system, and a general one at that was a pleasure with this new AI system. All I had to do was advertise the event to the NPCs and viola! A lot of old spaghetti code got unravelled in the process too. So overall this reenforces the presidence of much cleaner and quicker code output.

Now everything is generalised concerning Region Attended Events (say that 10 times over) it can be used for any event on a site. One example is for lunchtimes and such. Though it wouldn’t exactly suit that application, RAE (yes, it’s now abbreviated) are more for events that require everyone to be present before it starts. So something like a board meeting for example. Or some formalised gathering of NPCs. Which is exactly what experiments are!

Anyways, moving on from this with a video of NPCs attending an event in a region!

One thing to note, experiments can also fail! When an experiment fails crazy stuff is intended to happen! I’ll discuss that in the next section.

Small Modification in Generation #

📣David

Not that this deserves a whole section, but I have made lakes smaller! THIS IS THE MOST IMPORTANT FEATURE! But seriously. A huge lake covering 90% of the map is, for lack of a better word, stupid! No one needs that much water, and it just gets in the way. So away with you foul hydro-aquatic demon!

Experiment Execution #

📣David

So the majority of this week has been spent implementing the execution of experiments. This mostly involved implementing the RAE to gather all the NPCs, and the rest was trivial from there. One thing I wanted to discuss… well three things: Experiment successes, failures, and analysing experiments.

NPCs attending experiment

Experiment Successes #

When an experiment succeeds you get a lovely notification about your amazing job (though you didn’t really do anything anyway). One thing we have implemented now is NPCs levelling up their career paths i.e. gaining experience. That’s one area of the game that hasn’t been discussed much even though a significant amount of development and game design has gone into and around it. However, that’s a topic for another blog post! But other than that, the next thing on the long (god so long) backlog of implementation is introducing memory to NPCs and having them remember bad experiences, especially bad experiments! This will likely interface nicely with the mental system, where NPCs randomly remember events and get a mental infliction from that! Ultimately, this is aiming towards the loop of acquiring Volunteers, and cycling them (wiping their memories and reusing them). Not too hard to implement, and a refreshing break from the more tedious (getting NPCs to go where you want them to) part of AI coding! On that note, the NPC AI system is starting to mature and grow some legs.

Experiment Failures #

When an experiment fails, you get a frightening notification. Not good news! But what happens when an experiment fails? Well, currently nothing, as it’s dependent on the anomaly that was undergoing the experiment. But in the future, we will implement certain failure events for the anomaly that gets randomly chosen (influenced by the storyteller). So very much a feature to wait!

Analysing Experiments #

The tail end of the experiment system and its end goal. Analysing experiments! Currently, the way it works is that labs act as factories for research points. I like to think of them like Factorio labs but with people instead of science items! So the researchers directly control lab output. For example, if all the scientists are in the same field, they speed up the production of research points associated with said fields, whereas if they are diversified, they are broader, producing more varied research points, but slower.

Labs have three attributes:

These three attributes, amongst a few more, are calculated as follows:

Research Speed (How fast the analysis is completed)

Research Modality (What type of research point does it )

Research Volume per Lab (How many experiments this lab can analyse at once)

Research Volume Total (How many experiments you can have available for labs to analyse)

Research Production (The amount of max research points a lab can tap into)

This might not be completely accurate, and it’s all subject to change, but this should give you a rough idea of how the calculation for things works! You can see an image below of how the UI looks:

I also spent some time implementing a graph system to display production metrics! This can be generalised to any graph we want to show in the game but currently is kept to just experiments under analysis. Furthermore, experiments can be put into the archive, which is a fancy way of saying that labs should stop trying to squeeze research points out of them. There is a sort of optimisation game of constantly changing lab arrangements, archiving and unarchiving experiments etc to maximise research output. We hope to make this part of the game easy to interface with, but hard to master! Optimisation is always rather fun and doesn’t necessarily undermine the story generation aspects of the game.

Example of a graph display!

An Aside #

📣David

A friend of mine highlighted the lack of technicality in this blog. Which is something I am fully aware of! This blog was never intended to be super technical, however, it appears that we should probably introduce technical elements back into the blog. Back in the older days of blogging, when we didn’t even properly spell-check blogs, we did cover the more technical aspects of the code. We even included code snippets occasionally. However that slowly fell to the wayside, and the blog slowly became more surface-level. I think in future blogs we will reserve at least a single segment for writing about technical things, however, it takes significantly more time to write such segments! This is likely part of the reason we started to relax the technicality.

Notepad #

📣David

The last feature, and a rather small one, is that I implemented a small to-do notepad. This notepad currently just displays any tasks given by grants or proposals and is just a quick and neat way to remind players what to do. Eventually, I can imagine this being used by a tutorial system too. This is also the first time we have used diegetic UI again since the UI overhaul. If you aren’t aware of what diegetic UI is, it’s the methodology of creating UI with a basis in real-world items, objects, etc. In this case: the paper texture. Neat! We hope to use more of this in the UI, but that might be something left up for polish.

Case Closed #

📣David

Ah finally, after what seems like a long series of my face appearing above every heading, it’s time to close this case file. I don’t have many other words to say that haven’t been said already, so I’m just going to wrap this one up quickly. One thing I wanted to leave with you is this silly graph, which still holds true today and when we made it all the way back in Forensic Friday 20

Anyways thanks to all those who have read, and hope you keep reading more! Ciao!

Case Closed.
The Team
Plasmarc Studios