Game Design
Assimilation/Hacking minigame
At base, a puzzle game representing hacking a person’s brain to gain control over their actions.
You’ll be presented a GUI from ASS’ perspective, that shows a “stream of consciousness”, representing desires of the target you’re hacking. The target may be hungry, or desire companionship, and you can excite the corresponding neural paths to satisfy those desires, allowing you to drive the host as required. Once desires are mapped, you have complete control over the host. While in the middle of this game, you may perceive some of the target’s internal monologue, allowing us to present narrative details.
10-30 second minigame. The world continues running outside of the minigame. It’s possible that upgrades can speed up your perception of the minigame, “slowing down” the outside world, reducing the window in which you could get caught.
You have limited access to “understand” some desires at the beginning of the game, so we can ramp up the difficulty with the number you must contend with over time. It may be necessary to modify the environment at the beginning of the game to influence the target’s desires enough externally, that you can then take them over. By doing this a few times, you may come to understand that desire. This could be presented as a rhythm game perhaps, which introduces a twitch game element. Not all players will like this, so we want to try and provide different types of targets; some require twitch, some give you plenty of time and play like a puzzle.
Firmware upgrades of the BCI on
Desires - I think these should be a little more abstract. Desire for Novelty (Dad), Safety (mom?), Fun, Companionship, Food/Bathroom? This allows us to narratively represent those scenarios. I also really like the idea of the AI using your needs against you.
The interface I think has two things, these desire symbols that appear over time, and a random node network where only part of it is visible at first, and part of it is hidden by a fog of war. Parts of a visible “mapped” neural network light up. This is a random network that we generate for each person. Different nodes of the network light up for each desire that comes across the screen. Your goal is to play simon says with it, and add nodes of the network to a given group that you can excite as a set. You can’t see all the nodes and their reactions at first, only ones near nodes you’ve already tried to excite once. If you excite the wrong nodes too many times, you’ll give the person a headache and they kick you out. Part of the game is failing a couple times to get a chance to see which nodes excite others around them. Once you found all nodes for a given desire and to trigger it each time you see a desire symbol, you improve a “sync” percentage.
There may also be non-intuitive relationships between nodes, and times where a given node is part of multiple sets of desires that could excite it. The game is mapping the network.
[Talia: I think we’re going to need more than one minigame, or that game is going to get very old very quick, given the number of layers we have for 4X above it. In terms of story, I can propose two rationale for this. One is different manufacturer of BCI. The other is increased security/complexity/target-anxiety over time. The “lockpicking” style game I described before could, for instance, be used as a metaphor for correctly unlocking the remote wireless access of a target. You might begin with targets who are themselves simple enough that past the wireless stage their assimilation is automatic and assumed. ;-)] ^ Agreed. Yah, we’ll need multiple mechanics. My immediate thoughts are what sort of simplistic system can we impose arbitrary rules upon to increase complexity. A node network is both interesting as a representative of actual neural networks and computer networks, so I think it’s an interesting problem to try and expand upon. I’ve also been doing some research recently on stuff like A* and Dijkstra's algorithm (try spelling that haha), I’m sure there’s a bunch of other interesting things here to play with. [Absolutely… More soon, I just wanted to come in and add comments for a bit before I got back to studying Unity. Onto the second tutorial, which is a roguelike game, which is just what I need after the first one. After that, I think I have most every conceptual part of the API I’ll need to go ahead with making some prototype material -- whether I finish it by tomorrow is a guess, but I’m optimistic! PS-- Thank you for writing all of that up! Agree enthusiastically and wanted to embellish.]
