next »

[mz-one]

– Wake up and smell the energy drink, it's cyberpunk hacking time –



Hey guys! I wanted to start talking to you about the game that we've been making. It's called Netspectre and it's a cyberpunk hacking roguelike. The vision is to make you feel like a hacker in an evocative, thought-provoking, futuristic world. You'll hack into networks, build the best computer rig to punch through their security, and have to make all the other decisions coming with the daily life in the megacity. You will feel smart, excited, and amazed. It's going to be great.

[[ running ]]

The principal mechanic of the game is hacking into procedurally generated networks. The hacking is metaphorical: a mix of basic math, understanding the interlocking mechanics, and making decisions with incomplete information. Running happens in real-time; usually you have as much time as you need to read the situation, but sometimes the security applies more time pressure and you have to pick up the pace.



[[ deck ]]

Inbetween the runs, the game returns to its narrative layer, where you can use the rewards from the successful contracts to improve your deck for the next run. That means primarily scouting the market for components synergising the best with the build that you're going for, whether that's kernels, memcards, various chips, or the actual programs that you'll then have at your disposal during the runs.



[[ narrative ]]

We're putting a lot of effort into our worldbuilding, which we want to show through the random events. The events offer you that special narrative spice such as rare contracts with unique rewards, suspicious trade deals, opportunities to optimise your equipment, and so on. Over time, we want you to be able to put enough of the narration fragments together to start imagining the larger universe that the game takes place in.



[[ vfx/sfx ]]

We want to visualise the elements in the network run through an abstract, geometric, procedurally-generated extravaganza. For the narrative layer of the game, we want to illustrate the events through atmospheric illustrations. We're also focusing a lot on dynamically adapting the music during the run to the current situation.



[[ who is this, again? ]]

We're a squad of about five or six people in Czech Republic that formed a team just to bring this particular project that we love to life.

[[ tech ]]

Netspectre is developed with LÖVE <3.

[[ status ]]

Everything you see above is just from our preproduction prototype. We focused mainly on nailing down the mechanics, so the visuals are obviously super crude. We're now about a year deep into actual production, and I estimate that we'll need at least another two years to release. Then again, that's what I thought a year ago, too ,)

[[ devlog ]]

I want to start this devlog in order to start gathering useful critic, so definitely please do come forward with any thoughts, opinions, or questions. I'll post from time to time either to expand on various aspects of the game, or to provide updates on our progress.

[Lares Yamoir]

Screenshots look interesting. Keep it up!

[bram_dingelstad]

Seems like an interesting concept, would love to see how you guys will nail the gameplay and how the deck loaded/building will work.

Best of luck!

[mz-one]

Thank you very much for your encouragements!

To kick things off, I want to show a short gameplay video from the preproduction prototype and introduce some of the basic mechanics:





Now to break it down and explain a few of the things in that video:

Start – For each new playthrough, we want the player to be able to set up their background. The design in the video is simple: you can pick and choose from any number of fragments such as 'Rainy day fund: Start with +X credits' or 'Damaged heuristics: +X% trap stealth mechanics', each of which either spends or provides karma points, depending on whether it makes the playthrough easier or harder. If you choose to pick more penalties than bonuses, you're considered playing on a harder difficulty, and vice versa: basically a build-your-own difficulty system. Each backstory, except for the first few bonuses, has to be unlocked first: bonuses unlock through using their relevant mechanics, e.g. the Ghost backstory unlocks through evading enough traces, across playthroughs, and penalties unlock for winning the game for the first time:



(We're just redesigning this to a new system, which seems like a good topic for one of the future posts.)

Workbench – At about 0:20 in the video, you can see the workbench screen. This is where you construct your deck inbetween the contracts. The basic idea here is that the slots in the top half of the screen represent hardware components: a kernel, a memcard, and several ACEX chips, which usually provide various passive bonuses, while the lineup below them represents modules: the programs which you can then actively use during the actual run. I'll also come back to this later.



Run – In the rest of the video, you can see one entire successful run on a rank 1 vector, i.e. the easiest one. Your goal in each run is to progress through a sequence of stacks (stack = a lineup of the colourful hexes), each one consisting of several nodes (the said colourful hexes), to reach the end. In order to be able to advance from each stack to the next one, you need to breach all of the barrier nodes by reducing their strength to zero. You can do that with the help of your breaker modules. Ezpz, like this:



When done with the run, we're taken back to the world screen, credits in our account, looking at the market for stuff to boost our deck with. For the moment, this is where I'll pause. I'm all ears for any thoughts or questions; in the meantime, thanks for reading! And until next time –

[mz-one]

For most of the elements within the network run, such as barriers, sentries, protocols etc., we want to generate the visuals procedurally, i.e. starting just from elementary shapes or small sprites, laying them out in layers and geometric patterns and animating them in time. I threw together an editor for these kinds of effects, which are just Lua scripts that can use whatever LÖVE allows us to do, e.g. particles, shaders and so on. The editor then allows us to tweak the input values such as colors or dimensions and render the changes live:



We can export each effect straight into the game, or just instantiate it within a larger efect. For example, this is an effect that uses the simple grid effect shown in the previous video, instantiating it three times, just overlaying the instances over each other and controlling their color and other values through a few simple wave functions:

[mz-one]

These are the first attempts to create two actual barriers for the network runs:



Right now this is mostly a proof-of-concept, helping us figuring out where we want to go with the visual side of things and also easing our minds through some rough initial profiling, since I've never done a game in LÖVE with so much visual theatrics as we plan for this one. Everything looks good for now, so we're off to prototyping another important domain: narratives, but more about that next time –

[mz-one]

We're sketching the narrative side of things, both mechanically and in terms of content –

Our narrative goal is to help you build a progressively better idea of the fictional world that the game takes place in as you play. The idea is that we'll build a rich universe lore, but mostly keep it behind the scenes and use it to make sure that our stories are coherent. Each random event in the game will then reveal a fragment of that world, leaving a lot of space for you to connect the dots, hopefully immersing you in the process of imagining our fictional world with us, and partially making it your own.

A quick video of our prototype, playing around with how an event could read like and look on a screen –



We're thinking about a few specifics coming with our game being a roguelike, namely:

1/ Randomness: The random events will inevitably spawn in a different order for each player. Someone else might be worried about the consequences of this resignation on narrative control. Wouldn't it mean that there will be people, places, and concepts in the text that we haven't properly introduced? Our approach to this is to double down and put even more specifics in the text, pretty much without ever properly introducing them anywhere, whether sooner or later. Hopefully, this will make it obvious that you're not supposed to know who 'Revenants' or 'Shakima' are the first time that you see them in the writing; the sheer amount of unintroduced specifics should make it clear that you didn't just miss a single piece of exposition, but that there just isn't any in the game. The concept is that you'll then start to pay attention to the small cues, so that you can begin to imagine the world yourself, out of the basic human need to understand your environment.

2/ Repeatability: Netspectre is meant to be replayed a lot: a single playthrough should take about an hour, with the larger gameplay being in playing repeatedly, discovering more of the game every time you start. For the random events, this means that they will sooner or later inevitably spawn for the second or third time. This makes it tricky to work for example with surprising revelations, which obviously wouldn't be quite as surprising the second time around. Our answer to this is building some variation into the scenarios themselves, so that for example your investigation doesn't always necessarily turn out the same way, even though the original contract may have seemed the same.

We want to provide more clues that will incite the imagination than just the writing, so we want to accompany each event with a static illustration. The events will be shown as overlays over the world screen, with the illustration serving as a background to render their text onto. For the special scenarios, we want to have a specific illustration describing the particular event taking place, while for the more common events we'll use one of the more generic ambient images. Anyway, that's the idea, since we'll still have to see what we can afford with our shoestring budget, this being our first commercial project.

(Also, we just want to get some cool new cyberpunk art done, because we want to see more of it in the world, and that's reason enough.)

[mz-one]

We started to work on the procedural generation of the networks that you'll be able to run onto. We've had two or three algorithms in place previously, more or less simple placeholders to build the rest of the game around, but since it's such a critical thing to get right, we decided that it's time to start working on it, like, properly.

Here's a quick flyby over the current state of things:



We decided to create our networks basically through a generative grammar. We teach it rules such as:

- a run is 1-3 lanes,
- a lane is 5-9 stacks,
- a stack contains several nodes,
- a node can be a barrier, a sentry, a weakness, a database, a trap, or a terminal,
- a barrier has to have a certain strength, based on where it is in the network etc.

Then we ask the system to generate a run, provide it with a seed to use for all of the random decisions that it will make in the process, and the grammar deterministically expands this root symbol following all the rules and returns a token tree describing the network in all its details. Each rule is a script file of its own, encapsulating all the particular logic specific to that one step of the process.

So what do we look for in the resulting network? From the earlier placeholder algorithms, we know that there's actually quite a lot that the run should satisfy in order to support the gameplay that we want, particularly in terms of:

A/ Mechanical relevance: A lot of our network nodes, protocols etc. come with specific mechanics that only make sense in a particular context. For example, if a barrier comes with the 'double strength whenever weakness exploited' mechanic, it only makes sense on a stack where there's also weaknesses.

B/ Complexity curve: We want to make sure that the more complex mechanics are only introduced further down the difficulty curve. You don't have the equipment in the earlier turns to deal with the more sophisticated security elements such as protocols or sentries.

C/ Balance: We need to control the basic difficulty parameters of the run based on the rank of the contract that it represents, e.g. even though both a rank-1 and a rank-4 contract contain barriers, there should be more of them in the latter and they should have higher strength.

(We need to maintain a degree of control over this in order to keep the difficulty somewhat fair, but eventually decided not to care too much. It's a cyberpunk game set in a ruthless world. Sometimes the going gets tough and the network just is a bit harder than what its security reading suggested. If you're such an ace, deal with it!)

D/ Meaning: We want to infuse the generation process with quite a lot of narrative meaning, e.g. if you're hacking into a Troika network, i.e. into the netsec corporation, they're going to use a lot of their own technology in their perimeter; if you're diving into a datacenter, there's going to be a lot of databases, etc.

We also spent a couple of days to make the generative engine produce an interactive log that can be used to inspect the timeline of the entire generation step-by-step. That can be seen in the second part of the video. I think it's great how easy it is to produce quite a smooth UX just with basic jQuery nowadays. Good job, y'all out there –

Right now, we've got the generative framework going and integrated into the game, so it creates simple networks that the game can load, such as the one in the video. The next step now is to work on the particular rules so that they produce the networks as close to the criteria described above as possible. Fun stuff!

(Btw, you might notice that the game looks differently from what we've posted previously. This is because the earlier posts showcased our preproduction prototype, while now we've moved onto actually creating the real thing, from the ground up again. The caveat being that the real thing now looks very crude.)

[logophil]

I love the concept of this! I like how even the animations are procedurally generated in your prototype, and that really fits the theme of the game. Will be following this with interest.

[mz-one]

Thank you very much!

For today's devlog, it's mainly just a quick update that we also started a twitter: https://twitter.com/NetspectreGame.

We'll post a little bit more frequently in there just because of the character of the respective platforms: I'd like to keep the posts here more substantial, and consequentially a bit more apart, and to post the more random pieces of progress on twitter so as to not spam here too much ,)

Just to provide a general update on things in the meantime, I'd say that we're well on our way. I put together an internal release today so that the team can playtest the last several months of changes hands-on. It contains the first versions of music and also first proper scenarios, so that's something. I plan to focus on some of the smaller secondary mechanics in the coming weeks, e.g. the component optimisation mechanic, the character skills and talents, bonus objectives, etc.

In the meantime, thanks again for the supporting messages! It's great to see that there are people interested in what we're trying to do –

[mz-one]

What is up, soon-to-be netspectres! Just wanted to let you all know that we're moving forward, slowly, perhaps, but steadily, for sure –

For today's devlog, I wanted to show a bit of how we're approaching our worldbuilding. It's certainly not exactly groundbreaking science, but since I'm quite happy with how it's turning out, I wanted to share at least quickly with you all, just so that you can be too ^.^

First of all, let's go to today's video already:




Our modus operandi is that everybody on the team is more than welcome to pitch ideas for the worldbuilding, as is the case with all the other creative aspects, too. To that end, we have a collaborative document called atlas, where everyone on the team is invited to contribute snippets about whatever aspect of our universe they currently happened to be thinking about. Thought of a cool concept for a music club? Leave a note in the atlas, along with what you think that it looks like. Imagining how far we've progressed with the Mars colonisation? Let's just start brainstorming ideas and see what happens. Got a great name for an energy drink? You know what to do.

Everything is fair play as far as pitching ideas into this collaborative brainstorm document goes. We then comb through the ideas occasionally and decide to canonise some of them; we elaborate on those properly and enter them to our internal wiki, Atlas with a capital A, which elevates them to the status of a definitely confirmed real truth about our world. At this point, we make sure that the information makes reasonable sense in context of all the other facts that we have already commited ourselves to. Any information in Atlas is then legit to use when we're writing our narrative scenarios, which I talked about briefly in one of the earlier entries.

And that's it! It would be fair to ask: is it really that important to think about what are the different strands of techno music called in our world, if it's a hacking game and you'll be mostly just running on networks, stealing everybody's data to sell? Yes. Yes, it is.

[mz-one]

Hi everyone! We're moving forward, lately mostly on our narration, both in terms of the framework and of first content –



To highlight the most significant progress –

Scenario titles / contract description: For a while, we'd been torn between the idea that the contract descriptions should be, well, descriptive, e.g. 'Run onto the dockside logistics center and make a shipping container disappear', and our affection for shorter/cheesy mission titles, e.g. Lost In The Stacks. Finally we leaned back into the wisdom of the internet, so now each scenario has its own, compact title, which we use on all the contracts and narratives that it spawns, helping to tie them together, and each contract also contains a longer synopsis, which you can use to recall more clearly what it was about before you choose it as your run for the turn.

Characters: We decided to make the characters a more prominent part of the design, so now a/ a character's portrait is shown next to the last shown phrase in the active narrative, b/ each contract remembers its contractor and shows their portait on its detailed display, c/ we gave each character a proper name and started to show it next to their portrait on the contract detail overlay, and d/ we're designing scenarios with consequences based on how you treated their characters earlier in the playline.

Scenario spawning: With first few scenarios implemented, it was a good time to script the behind-the-scene narrator that spawns the scenarios automatically each turn. It tries to constantly keep the number of your available contracts around 2-4, depending on how far in the playline you are, so that you always have a choice to make, but aren't overwhelmed by too many options. There's a certain flexibility in difficulty of each scenario now, which the narrator leverages to try to always offer you one option that's slightly more challenging for your current level, and one that's a safer choice. (With that, we also implemented the option to mingle, i.e. to spend hustle points to go out there into the world and look for more contracts, if you're not content with your selection. But let's talk about hustle points some other time –)

Random tokens: For some of the specific names used in the text, we now randomly pick from several alternatives just to give the narration a bit more variety. For instance, when we say 'Release money from a frozen Hemsworth & Brooks account', the specific bank will sometime get switched up for 'Crestspire Fintex' or 'Freehaven Investment', just to make it seem a bit different when it spawns each time.

Long story short, our narrative tech is again a bit more sketched out, and we can focus on filling it with more content. We have several other exciting developments in the works, so hopefully I'll be back soon with more news. In the meantime, we hope you're all doing great –

[mz-one]

Hi everybody!



We did a quick pass over our visuals: they're still very much placeholders, but functionally they're now closer to what we want to eventually have. We started to determine each node's visuals from its mechanics, so that you can read the situation just from their looks, without having to hover over everything. There's a lot of work to be done in this direction to make this look as well as we want it to look, and also to clearly indicate all the necessary information, but it's a start –

Also added a few more placeholder illustrations for the events: these are all just public domain city photos at the moment, run through a basic color filter, just meant as a placeholder for the idea that each event should have its own image, which is something that we're working on, also. Hopefully I'll have more to share about that soon!

Hope everyone's doing well –

[mz-one]

Hey fellow spectres –

We were asked in the LÖVE discord to post a video that would better explain the mechanics within the run, so here it is >>



It's a run on a randomly generated network, commented all the way through so that it's easier to understand what's up. The network has the security rank of just 1, meaning its the easiest one possible, so there's just the basic mechanics: you only have two modules and there are only the very basic nodes present in the network.

Until next time!

[mz-one]

Hey runners!

First of all, this is devlog #10! YAY! That's, like, an anniversary, or something? We're really doing this, is what I'm saying –

Today I realised that while I've written quite a bit about the running on networks and our narrative events already, I still haven't said much about the third Netspectre pillar: constructing your deck, i.e. the powerful hacking miracle-of-a-machine that is your main weapon in your life of a soon-to-be cyberpunk hacking legend. So there we go >>

Components
--------------

Kernel – In our world, a kernel is a hardware component that serves the roles of today's CPU, GPU, and OS all at the same time. It provides the deck with its primary computing power and physically executes the lowest-level system routines required for the deck as a whole to operate. For highly specialised devices, such as indeed netrunning decks, the most critical operations can even be wired into their own custom physical circuits, optimising for maximum performance. Kernel is essentially the heart of your deck.

Mechanically speaking, your deck's kernel determines your baseline alert threshold, i.e. how much noise you can cause during the run before provoking the network security into launching a trace to disconnect you. It also determines your token capacity, i.e. the maximum number of tokens that your deck can hold. Better kernels also come with strong special abilities, which often lay down a specific direction to your overall deck synergy.

Memcard – Memcard is something between today's RAM and a motherboard. It serves as the deck's runtime operational memory, but it also contains physical slots into which you can insert module components with the actual programs, see below.

Mechanically, memcard's primary attribute is its driver capacity, determining how many modules you can fit into your deck.

ACEX – Auxiliary Chip/Component Extensions are basically the USB's of the future: standard ports that can be used to connect all sorts of various extensions/peripherals, from additional storage, to external computing power boosters, or dedicated chips with specific benefits. It's a little wonder that they're so well-recognised as a standard, since they're not really upheld by any sort of formal organisation: it's just the netspectre market forces needing all the rigs to be able to fit all these extensions.

Mechanically, ACEX chips represent passive bonuses. You can fit up to six into your deck.

Modules
---------

Even with the best kernel, memcard, and ACEX's, your deck still needs modules to actually be able to affect the network. Each module can target specific nodes, will have one or several effects on them, has its costs and/or requirements, takes up a specific number of slots within the memcard driver, and has its execution speed.

Mechanically, modules are your active abilities. They're what you'll be able to use during the run to affect the network nodes, protocols, traces, and overall security.



Le voilà, a video of the deck screen at the moment. The top big square component is your kernel, the noodle one below it is the memcard, the boxes below that are the ACEX chips / slots, and the colourful rectangles are the modules loaded onto the memcard. The blue stripe at the bottom of the screen is your workbench, i.e. components that you have out of the deck at the moment, idly lying on the table, waiting for their chance –

Starting deck
----------------

You start each playline with a basic deck: a cheap kernel, small memcard, two common modules, and no ACEX chips. There are several module presets that you can start with, so that each playline starts a little bit differently, hopefully inspiring you to go for at least a slightly different build each time. The starting kernel and memcard are always the similar basic models, with only tiny variations.

Upgrading
-----------

Each turn, inbetween runs, you're free to spend your hard-earned credits for either of the components or modules available on the market that turn. You can spend your hustle points to explore the market more widely, rerolling the selection. You can also spend the same hustle points trying to optimise your current components, but more about that some other time.

--

Hope you all are doing great! On our end, we're gearing up towards our team getaway next weekend, where we'll meet up from all of our corners of the land for the entire two days and nights, playing our current build, scheming our future, watching Blade Runner, playing Netrunner, and overall chilling out and hopefully coming up with many new great ideas for your upcoming cyberpunk hacking extravaganza experience.

I'll post when we come back! In the meantime, if you want to help us on our way, follow us on twitter> https://twitter.com/NetspectreGame

<3

[mz-one]

Hi, it's us again! As I was insinuating in the earlier posts, we rented a house in the country last weekend and went for a team retreat for the entire two days. The idea was mainly to play the current version of our game a lot and synchronise our ideas of where we're going. It was great. This is us, obviously working super-hard –



What we all are so intensely looking at is the TV where we played the game basically all the time (this is me, btw):



The build that we were playing was a milestone for us, since it was the first version where you could win the game using just proper content that is really meant to be in the final game. It was exciting how actually going for a real victory instead of just messing around with the wip builds really helped to energise the discussions. Is two tokens too much for this module? Is the vulnerability build viable? What's the best kernel? What's your style?



Speaking of style, the dope cottage swag was indeed strong with us <3



I think that almost everybody managed to win their own playthrough during the weekend, eventually. We'll need to make the game a bit harder. Then again, we were only playing the first two ambitions out of the eventual four total (Run For Your Life and Turning Tables), which should be the easier ones, allowing you to pick up the game and train for the later and harder playlines (Golden Ticket and Genesis).



This is Oli, our amazing music composer / sound engineer, playing with a gadget that he soldered to record the sounds for our game. It's two electromagnetic sensors wired into a chip that translates their input into an audio signal that you can then record / hear. We all felt like that's a really cool way of going about recording sounds for our game in particular: the metaphorical idea of sort of materialising the invisible world of cybernetic networks, or magnetic forces, respectively, into something more tangible –



Overall the creative energy was intense, especially all Saturday, as we shared our impressions with each other, brainstorming, analysing, even rethinking quite important parts of our design, for the entire day straight. All in all, I feel like we eventually realised that we're in really good sync now about the whole thing, tuned into a shared vision of what we want to do. Tapping into the collective exctitement about the idea was really invigorating in and of itself, at least for me, personally –

(Btw especially the second book on the picture above is really cool – wholeheartedly recommended.)



Later into Saturday night, we called it a weekend and just went on to chill out and watch the new Blade Runner, winding down after an intense day. We watched Portal speedruns, which WTF, and then the entire Star War: The Third Gather – Backstroke of the West, after which we went to sleep, coming to terms with the realisation that none of us will ever make something remotely as great as that. But we can try.

[mz-one]

What's up netriders! A lot has been happening lately, so I wanted to stop by with another update. Music is the name of the game recently: we composed about a dozen preproduction tracks, two of which we then overlaid with snapshots from our game to make sort-of a trailer, so that we have something to link when introducing people to our game, even though it's all still just very crude at the moment –



We decided to compose two kinds of tracks:

Ambient tracks – For the world/deck screens, where the mechanics are turn-based and the overall mood is more lyrical, we're going to use precomposed static tracks. These will be the calmer, melancholical tracks, their goal being to help transport you more fully into the universe and immerse you in the current narratives, eerily stimulating your imagination in the background of the text and visuals.

Running tracks – When you're diving into a network, mechanically everything is much more intense, and so the music needs to follow suit. The gameplay is real-time, there's the danger of the network tracing you down, and sometimes you're even under a time limit to reach your target, so in terms of its mood, the music should make you feel rather tense/hyped and feel more energised/strict than the ambient tracks.

We'll mixdown the ambient tracks in production already and always play them exactly as they are, but for the running tracks we want to adapt the music at runtime to the current situation in order to better support the emotion that you should be feeling at the exact moment. Right now, we're experimenting with the best way to do that. Here's our prototype>>



Technically, it's pretty straightforward: we're just independently fading-in/out several layers of the track. Now the two real questions are 1/ what mechanical metrics we want to drive the mixing algorithm and 2/ how to split the tracks into layers in such a way that they will work together in all of the combinations that we will possibly decide to mix them in. I'm working on integrating our prototype track to the current game build literally right now, i.e. it's what I have open one alt|tab away, so that we can actually playtest it as soon as possible. I'll share the results once we have something to show/hear.

We have a handful of tracks and many fragmented snippets coming from the preproduction so far, and I have to say I really love where Oliver and David, our composers, are going with this. We'll have to set up some sort of platform to share these, so that you can listen to them also, and let us know what you think. In the meantime, keep it cool! We'll tune in again soon –

[mz-one]

Hi everyone! I want to show what I promised in the last post: we integrated the adaptive music prototype into the game, so now the music underlying the network run adjusts to what's happening. We looked at the results with the team just this week and were pretty excited, so we called the prototype a success and decided to move forward to produce the actual tracks. Here's a video showing the prototype:





To break it down a bit –

Run metrics – We constantly evaluate several mechanical metrics during the run in order to distill the situation down just to a few easily understandable numbers. For example, depth determines how deep down the run you are; complexity is a score added up from how many elements (nodes, protocols, traces, tricks etc.) there are present and how many mechanics they have; timePressure represents how many of those mechanics force you act quickly etc.

Layers – Each run track has several layers, the weights of which towards the final mix we modify dynamically during the run. Each track can have as much layers as it makes sense for how it's composed. For example, the prototype track has five layers called bass, pad, perc, strel, and wack, but other tracks can have different layers entirely.

Mix script – Because the layers for each track can be different, each track comes with its own Lua script describing how to translate the run metrics values into the weights of its layers in the live mix. For example, for the prototype track, we do something like:

   local i = min((depth_absolute - 1) * 0.21, 1)
   --
   pad = lerp(0.6, 1, i)
   bass = lerp(0, 0.6, i)
   perc = lerp(0, 0.25, i)
   --
   pad = pad + rank * 0.065
   bass = bass + rank * 0.0575
   perc = bass + rank * 0.035
   --
   perc = perc + timePressure * 0.45
   --
   local i = max((complexity - 3), 0) * 0.185 + noise * 1.375
   --
   strel = strel + i
   wack = wack + i * 0.85   
   ...

In other words, the pad layer is the baseline which even intensifies as you progress deeper into the run. The secondary bass and perc layers also appear and ramp up as you advance. In higher rank networks, all the weights are a bit stronger to start with, i.e. in harder networks, the track incorporates more of its secondary layers right away. When under pressure, e.g. a trace is actively trying to lock you out etc., we mix in the percussions. We mix in strel and wack layers with the more glitchy aspects of the track based on how complex the situation is etc.

Then we continuously evaluate the run metrics, project them through the script into the layer weights, and smoothen the transition from current weights to the new ones over several seconds. That's the whole idea! It's all quite simple, but it allows us to tailor the music much more appropriately to what's happening in your run than a static track would, which should help it achieve what it needs to to, i.e. help you feel like you're in the network and important stuff is happening.

While I'm here, I also want to post one of the drafts that we made while exploring the direction for our soundtrack. These are meant to play under the world narrative events, i.e. during the calmer, more lyrical periods of gameplay. What do you think?





A lot of good stuff happened in the last month all around, also: we implemented a simple skill/talent system, wrote several new scenarios, actually made the game save/load, progressed on the Mac port and so on. There's a few topics to talk about in future posts in there, too, for sure. In the meantime, you all take care, though, and here's to all of us having a great new year

[mz-one]

Hi everybody! The latest update is that we're working on the tutorials, so that first playtesters can hopefully start to be able to pick up the game even without us being present and personally walking them through everything. We're aiming to strike the right balance between telling you enough that you understand how to start playing, and letting you discover the rest for yourself, sort of face-first. This is what we have right now, although obviously it's very much a work-in-progress still:



The way we're thinking about things right now, there's going to be basically three avenues of learning –

Hints when you see a screen for the first time – You can see these in the video above. Whenever you enter one of the screens, i.e. the launch screen, world screen, or deck screen, for the first time, we show you a series of hints explaining the relevant mechanics, while highlighting the appropriate UX controls. You can always revisit these by clicking an icon in the screen bottom-right corner. The particular hint sequence is actually always adapted to the current situation, e.g. if you have no hustle points at the moment, we'll skip the steps with how they in particular can be used etc.

Interactive training runs – These are the more hands-on tutorials for the hacking mechanics. We're creating three learning runs which will guide you step-by-step through all of the most important mechanics of actually running on the network, and it will be up to you to follow the advice and complete the runs. You can see in the video how the world screen hints will invite you to run these (although the runs in the videos are just placeholders right now).

Keyword explanations – We'd like to show brief reminders of the most important mechanics whenever you hover over things during your run, such as if you're looking at a vulnerable barrier, we'll explain what a barrier is and what does it mean that it's vulnerable. These can be thought of as essentially tooltips, except that they'll probably be shown in the bottom-right corner, so that you can take a look at them if you need to, but they don't clutter the central UX area.

On other fronts, we're working on setting up a discord server, working on first sounds and more ambient music, and experimenting with art direction for our first very own original narrative event illustrations. I'll come back soon with more news. In the meantime, take care! And check out / follow us on our twitter, if you'd like to stay in the loop –

[mz-one]

Hi again! This time, I want to show one of the narrative scenarios that can happen to you randomly inbetween the network runs. Earlier in devlog #3 I talked about how we want these events to have some randomness built into them, so that they can surprise you even after encountering them several times, which is bound to happen eventually, provided that Netspectre is a roguelike that is meant to be played over and over, so let's look at an example of that –

Our latest scenario is called Deels on Wheels and features Gary, the local street peddler, pushing his notorious Mountain-Of-Stuff-For-Sale around the block. Imagine someone between Bubbles from The Wire with his shopping cart mobile shop, and you know, (these) (guys). So what happens when you meet Gary can usually be this:



In other words, a hacking component somehow made its way into Gary's Rolling-Hoard-Of-Things-You-Can-Buy and Gary will offer you to purchase it. To underline the improbability of this actually happening even more, the component is always one of the rarest ones, and Gary offers it to you for a 40-70% price of what it would usually cost on the market. In gameplay terms, this is basically a lucky opportunity for you to buy something really good quite cheaply, if it suits the build that you're going for.

However, if you're really lucky, you can get the sort-of-secret variant, where Gary offers you to buy a cute spider for you to keep you company in the crowded-but-ultimately-lonely futuristic world that you live in:



Besides being super-cute, which will obviously start to work only when we'll have the appropriate illustrations in place, the spider also provides a pretty solid gameplay buff. What does that do exactly depends on which color you get: the spider can be either pink, blue, black, or yellow (it's not a quite normal spider, obviously), with their respective gameplay bonuses being:

(-- continued in the next post --)