Electric Noir

December Sprint Review and 2020 year in review

2020-12-27T13:02:00+00:00

December comes to a close and finally this year is over. December saw the completion of the work started in Novembers sprint. Ivy Automata has been included into the game as the first boss fight, but not without some sacrifices.

Before I get to those though, let’s do sprint recap and cover the good things that are coming in the final build of the game for 2020.

So this sprint I closed out 15 issues, 7 Bugs 🐛 , and 8 Enhancements 💡. A pretty nice split actually.

Ivy Boss Fight and narrative tweaks.

The demo scene is more linked to the storyline of Electric Noir. It’s no longer a one-off encounter, instead it exists within the main storyline of Electric Noir and shows off some of the larger plot of the game.

New lighting effects

I’ve updated my art pipeline so that I can more easily add visual effects to the game. This includes being able to author and include Normal Maps, Rim light masks and Emission Maps within my Aseprite files. These layers get imported via the Unity Asset Import Pipeline and included in the game automatically, so the 2D lights I’ve setup now add a lot of depth to the character sprites.

New physics improvements

In previous releases, when an enemy was knocked into the air their trajectory was pre-determined. The system used pre-computed bezier curves to control an enemies movement through the air. This worked well, however it ran into issues as the curves weren’t very high resolution, they consisted of about 10-15 points, which caused some of the larger movements to appear jerky and hard to follow.

This movement system also made effects like the bullet casings from Ode’s gun hard to code, since the only way to move would be to use these pre-computed curves. Instead, I switched over to using a true physics system, with gravity, acceleration and friction (really really easy to setup) to govern how objects move through the air.

This has improved a lot of the movement and feel of the game and allows for more dynamic combat and effects.

2020 In Review

It doesn’t really need to be said that 2020 was the worst. However, 2020 was a pretty good year for Electric Noir. I doubled down on my narrative beat-em-up idea, tweaking, updating an re-writing the storyline until I had something I was proud of.

I started crafting characters that I wanted to see, taking inspirtation from a lot of my favorite stories, both sci-fi and fantasy, fiction and non-fiction to get a world that I think feels real and has a unique perspective to offer players.

I revamped this very website with a new design that highlights the visual style of the game and makes a unique space online.

I started monthly development sprints and in September, I released the first of 3 builds this year.

On top of all of these things I learned a ton about making a game in Unity. There are a lot of challenges, and I’m proud of the fact that I’ve stuck with this project and kept pushing forward, rather than making a step forward and two steps back.

With that review complete, let’s talk about some things that aren’t so great.

State machine bugs

This month revealed a lot of bugs with my state machine code. The bugs were really hard to debug and fix, so I’m currently trying to figure out a way forward, as such there are no enemies other than Ivy in the December release. It pained me to disable them but they weren’t working and I’d rather have a portion of the game that is playable, than a whole game that isn’t.

I’m actually thinking of replacing the enemy statemachines with something like FlowCanvas with NodeCanvas rather than building something on my own.

Update on future releases

My wife and I are in the middle of packing up our house in Texas, preparing to sell it so we can move back to our families in Massachusetts. The move is scheduled to happen mid February so the next two months are going to be incredibly hectic and chaotic which means there will likely be very little time for me to invest heavily in Electric Noir in the next few months.

Looking forward through the move and back through the past few months, I’ve enjoyed the cadence of the monthly sprints, so I will definitely be keeping those up, but the monthly releases haven’t had the impact that I’ve expected/wanted so I’m going to be switching to releasing builds of the game when it’s gotten enough updates and polish to warrant them.

This means fewer releases of the game, but it also means better quality of those releases. It also means I won’t be stressing out mid-month about testing all the work I’ve been doing, instead I can test as I go along and polish releases just before they are shipped.

November Sprint Update

2020-12-04T07:24:00+00:00

If you follow me on twitter then you already know that this month is the first month where there won’t be a major update to electric noir.

this'll be the first month since I started doing monthly releases of @electricnoir that I'll miss my intended goals 😢. They were really ambitious but it still feels kinda bad. Anyway, December should have some cool new stuff. I'll post an update to the EN blog in a few days.
— Jared Barboza (@codeimpossible) November 25, 2020

This is tough for me to write because I really wanted to get this release out, not only because i had a lot of exciting additions planned but also because I committed to having a new update to electric noir each month.

The changes I’ve worked on so far will get rolled into December’s release, so there should be an extra special update to the game by the end of the year.

So what have I been working on this November?

First Boss Fight

Ivy Automata will be the games first implemented boss fight. She has two really devastating attacks that the player will have to avoid while dealing damage to her.

Ivy stares you down. She is a ruthless assassin, one who takes jobs for the challenge, no the credits. Exclusively going after augmented targets to prove her un-augmented superiority by defeating them in hand-to-hand combat, completely naked. She gained a lot of fame fighting in the NonAug circuit, but when that no longer gave her the rush she wanted she started taking assassination contracts. Her tattoos are her badge of pride, she gets a new one with each target she eliminates.

Dash Punch

Ivy dashes towards the player and unleashes a devastating heavy punch that can send the player flying back.

Slam Attack

Ivy jumps high into the air and slams down onto a random spot with incredible force which will knock the player back and deal a ton of damage.

Player AI

I’ve been worried a lot about not being able to catch bugs in the combat loop of the game. There are so many possible combinations of actions that the Enemies and the Player can perform that I really can’t hope to reproduce them all with just manual testing. So I spent a lot of time during November building out a script that can drive the player character with the hope that it would tighten up the testing loop for combat.

I was really pleased with the results. The player AI isn’t incredibly advanced, it’s just a script that scans the enemies and reacts to what they are doing, with some randomization thrown in, but it’s already made testing so much easier. I was able to find and fix a ton of bugs in a short period of time, something that would have taken me ages before. I’ve also started using this AI to test out the Ivy boss fight and it’s helped me find and fix bugs there as well.

I’ll write a more in-depth post on how I set up the player AI because it’s something that took very little time but added a ton of value, in the meantime, enjoy a gif of the AI in action!

On to December

I’ve got a lot of stuff planned for December, but the main goal will be to finish up the Ivy boss fight and release that along with the combat bug fixes. It’s been a rough month but I feel really really good about the state of things right now, which is better than releasing something half done.

Until next month!

October Sprint Review

2020-10-27T08:12:00+00:00

My second month-long development sprint wraps up today, and I am incredibly happy with the results! I’ll recap some highlights from the release notes but before I do that I’ll do a quick review on the sprint itself.

If you don’t want to read all the things I wrote, you can download the v2020.10 release of Electric Noir here.

How did the sprint go?

Octobers sprint was focused on itteration. Since the last sprint was the first playable demo release, I was able to get a lot of feedback from playtesters and friends. This gave me a lot of great bug fixes and improvements to target for this sprint.

So this sprint I closed out 18 issues this sprint, 11 Bugs 🐛 , 4 Enhancements 💡, 1 Cleanup task 🗑, and 2 Art tasks 🎨. Definitely not as many issues as the previous sprint, but fairly close. I’ve been expecting my velocity to go down a bit as we enter into the holidays here in America and this sprint had a lot of defects in it, which are hard to estimate sometimes.

One thing that I didn’t expect was that by widway through the month I had completed most of the tasks! This left me a lot of room to experiment with some ideas and test out changes and features I’ve been thinking about but not had the time to dive into. Unfortunately this meant that that I finished a bit less work than I would have liked, but I am still incredibly proud of where Electric Noir is at the end of this sprint.

Workflow changes

I changed up how I worked a bit this sprint as well. Normally I would commit changes to my main branch directly as I worked. This was beneficial because main then always had the “latest and greatest” code. However, this was a pain in the ass also because a lot of times the “latest and greatest” code wasn’t you know, playable.

This can be a big problem if you’re like me and you move between a few differnet issues during your work day. Also, since the move to monthly demo releases I’ve been treating breaking main as a more serious offense in my day-to-day workflow. Basically, I wanted to treat main as an “always shippable” version of the game, something I can take and test myself or hand off to a playtester for feedback any time.

So this basically pushed me to using branches and pull requests more frequently, which I use literally every day in my day job life as a programmer, I just hadn’t been as…strict? Disciplined? Whatever, with myself on Electric Noir. I decided to use branches and PRs for any normal or larger task but would still commit to main if a change was minor enough: tweaking AI configs, text/spelling changes, that sort of stuff.

Using branches and PRs had a few nice side-benefits though:

Since I use GitHub issues and milestones for all my task tracking, I could auto-close a bunch of issues with a single PR. And all my PRs show in my milestones, right next to the issues they closed.

Squashing and merging is amazing, having a commit history that just shows features and fixes being merged in is great

v2020.10 Release notes

Combat Changes

Hit screenshake amounts and pause-on-hit frames have been tweaked to make hits have more impact
Player can only dodge on the X axis now
Player can no longer dodge outside the level collision (Whoops!)
Enemies react to hits more consistently
Enemies spawn more blood when hit
Player has a new attack: their gun! Press Left-Trigger to draw your gun and then use Right-Trigger to fire! Be careful, there’s limited ammo but you can recharge your gun by attacking enemies.
Player can now heal 💕🩺! Pressing the left-button will inject you with a massive dose of healing nanites and a wonderful cocktail of euphoria inducing drugs. Isn’t the future grand!?

Dialogue System Changes

Player can now “hurry up” dialogues without skipping to the next spoken line
Demo dialogue has been updated with some fresh text animations, thanks to Text Animator by Febucci
Choosing the “we’re just passing through” dialogue option no longer crashes the game (Whoops!)
Portraits fade in and out when talking/idle, making it more apparent who is speaking
There is more visual separation between the character portraits and the game world
Speaker names are now separate from the spoken text, spoken text is now wrapped in quotes making descriptive text more obvious.
I’ve added a custom pre-processor for Yarn files to make it easier to re-use nodes, which will help me write dialogues faster
I’ve added a custom version of Ropework to handle most of the character portrait interaction code

Other Changes

I’ve switch to using the Pixel Perfect Camera from Unity
Sprite sorting has been overhauled and streamlined to support other objects as well
Particle Effects can be sorted using the same system as Sprites, which means I can use Unitys built-in particle systems to handle a lot of visual effects
I’ve added a developer console so that I can more easily debug demo versions of the game
I did a lot of cleanup on the repository, reference images and game screenshots have been moved to my notion.so project, automation projects have been moved to their own repositories in GitHub

Latest release download links

You can download the v2020.10 release of Electric Noir here.

September Sprint Review

2020-09-30T08:00:00+00:00

In an effort to make more progress - and relieve a lot of pressure on myself during the pandemic - I’ve switched to doing month-long sprints. September is the second monthly sprint I’ve completed and it’s been a really great sprint for a few reasons.

Review, How did it go?

But before I get into those reasons I wanted to do a quick recap of the sprint.

The sprint isn’t 100% over yet but I’m close enough to feel confident in posting the results. I closed out 22 issues this sprint, 6 Bugs 🐛 , 12 Enhancements 💡, 2 Core Refactors 🏠 1 Documentation ticket 📄 and 1 Art task 🎨.

Overall the September sprint went really, really well. I was able to focus really well on the sprint goal of testing, fixing and tweaking combat which had been a big problem in the weekly sprints.

Also, it allowed me to think more clearly about goals for the sprint. This helped me pivot midway through and get some minor changes done to product the first monthly demo of Electric Noir.

That’s right this sprint will be the start of Monthly Releases of Electric Noir!

Yep, I’m going to try to push out a new “demo” each month with changes and tweaks. This will give folks (hopefully a few of you fine people) the ability to play small sections of the game and give feedback to help shape the game and help me refine the systems and gameplay up till I get to “beta”.

What’s the difference between these releases and a “Beta”?

A beta is much closer to a release. My first beta will contain a larger vertical slice of the game featuring 90% of the games systems in a playable, and more importantly shipable state.

These monthly releases are more like an early early access. Small segments of the game with a lot of things left unpolished, unfinished, untested to express an idea or feature with hopes of getting feedback before a ton of time is invested in it.

That all being said I really want to avoid regressions during these releases so I expect my testing process to get some love and attention at some point in the future.

Full v2020.09 Release Notes

Combat Changes

Screenshake values have been increased for every player attack.
Player dashing has been re-enabled
Enemies now wander while they wait for an opening to attack
Enemies attack and block more frequently

Bugs

Enemies no longer get “stuck” and play their walking animation while stationary
The published game will now start correctly

Foundational Changes

Moved from a custom build of SInput to the newer Unity Input System. This was a big deal actually, it increased the performance of the game significantly and allowed me to start building out more complex attacks and combos.
Effects are now powered by the Reanimator animation system, instead of our custom animators.

Other

The release contains a playable demo level showcasing the dialogue and combat systems.

Where can I get the demo?

Ok, here it is, the v2020.09 of Electric Noir. This is a very simple demo to get feedback on the following:

Art
Writing
Combat/Gameplay
Bugs

I encourage you to play this months demo and send me your feedback, either on Twitter - @electricnoir or you can email me about at electricnoirgame.com.

Unity Upgrades and Effects

2020-08-04T08:51:00+00:00

Unity Upgrade!

I’ve been hesitant to upgrade Unity from my trusty 2018.3.x version, mostly because in the past it meant fixing a ton of bugs and possibly even ditching plugins until there was a release for the new version. But Unity kept adding newer and more compelling features with every release.

2D Lights and LWRP
Shader Graph
New Editor UI and UI Elements
TypeCache would help speed up a few internal tools I’ve built
Focused Inspector

No, I really shouldn’t upgrade. I mean, everything is working right now. What if everything breaks?

Uhm, isn’t that why we have source control? If everything breaks you fix it if its small or throw your branch away and forget about it.

Yeah, but when we tried this a few months ago with 2019 it blew up.

So we’ll try it again with 2020. Again, if it looks like it’s a ton of work then we’ll throw it away.

Hmmm. It would be really nice to get onto a newer version of Unity and be able to use some of those newer features in the game, if possible. Yeah alright, fine. Fine!

And so, I did an upgrade of the project in another branch that weekend. Amazingly the project converted without too many issues. I had to upgrade some packages - which wasn’t surprising - and fixup some editor code in one of my own plugins. I think it may have taken me all of 15 minutes to do. I’m pretty happy with the changes in 2020, especially being able to use the new editor UI and eventually play around with shader graph and the LWRP.

Building Pixel Effects using Unitys built-in particle emitters

I’ve been meaning to augment how effects are done in Electric Noir for a while, so this weekend while I was upgrading the project, I spent some time in a new project playing with particle emitters. I haven’t really worked with them before, other than following a few tutorials online. The goal this time was to really build something on my own and figure out the ins and outs of what my workflow might be to create some interesting effects.

My first test was making fire. Something that is pretty easy to do, even in sprite based art, but the good thing about using a particle emitter is that the fire will always be unique, so not every fire looks the same in your game. I also figured I could probably tweak whatever I ended up with into some kind of explosion effect later on, so much like the rest of humanity, fire is where I started my tech journey.

I played around with using a single particle emitter but I wasn’t getting the results I wanted. So I eventually switched to using three of them, stacked on top of each other, each one rendering on different sorting level. I used one for the darker orange of the fire, one for the lighter yellow of the fire, and the last one would handle the bright white to yellow center. Each emitter used the same material and texture, a 4x4px sprite with the four corners removed so it looks somewhat rounded.

I adjusted the size, color over time, noise and velocity over time until I was happy with how the particles were moving and then I worked on getting the effect to look more like pixel art. To do this I created a new layer in the game “Effects (No Display)” and moved my particle effects onto that layer. Next I created a camera that would only be able to see this new layer and set it to render to a Render Texture which I made incredibly low res (64x64). Once I had the effect rendering to this texture there wasn’t much work left, just add the texture to a quad in the scene and I had the following effect in my project:

the final effect, shown in the scene and game views.

I’m switching between the scene view and the game view in the gif to show how the particle effect actually looks vs the final in-game composite in the render texture.

Im pretty happy with this, especially since it is 100% modifiable in unity without needing any art asset changes. One thing I’m not sure about is how multiple effects would look on the screen, since I think that would require juggling multiple render textures… and AFAIK the only way to isolate RTs is by render layer… which are limited in Unity (I think there are 32…).

Dev Log 1.5

2020-02-22T06:00:00+00:00

In case you haven’t seen it already, the first video dev log for Electric Noir is up on my YouTube channel. It covers how Electric Noir got started, all the prototypes I worked through and the currents state of the game. Give it a watch and let me know what you think in the comments.

I plan on creating video dev logs regularly, though I haven’t decided on how often that will be. Written blog posts like this one will be used to show off more achievements that are more code oriented, or more deeply cover game mechanics.

Grappling and Throwing

Since the dev log video I’ve added grappling and throws to Electric Noir. The player can grab an enemy by pressing RB and once they are grapppled, the player can press B to throw them.

The throws follow a set of bezier curves that are stored at edit time and evaluated during play time. The throws can be configured, including changing the throw distance, the duration, and the number of bounces right in the unity editor.

Combo Chaining

The next big addition to the game is combo chaining. The player and enemies can now execute attack combos - like a three punch combo or a heavy attack followed by a ground smash. Combos are basically a very simple sort of tree that gets evaluated at play-time.

The next move the player or AI executes depends on what their current attack is and which various ComboCondition objects are met. A ComboCondition is a ScriptableObject that is created within unity and can be a check for almost anything - have you unlocked a specific move, what input are you pressing, what level are you, are you near a dead enemy, etc.

I’m happy with this sytem and I think it will allow me to create a lot of different combos with the minimum of effort.

Deferred Logging

One bug that I had to overcome was in the initialization part of the game - the stuff that spins up so that the rest of the game can work: Config, Logging etc. This is all in the GameContext object and the problem was that I made some changes along the way that made most objects throw an exception when retrieving a configuration setting or creating a logging instance. This basically meant that nothing worked when the game loaded :(

This forced me to rethink how logging objects are initialized within the game objects themselves. Before there was a tight coupling between the gameobjects and the GameContext, which is why the exceptions were happening if the GameContext couldn’t load (or wasn’t ready in time).

So I crafted a DeferredNoirLogger class that acts as a pass-through for logging calls. Each game object now instantiates this deferred logger and makes logging calls as before. Under the hood, the deferred logger launches a coroutine if it detects that the GameContext is not ready. While it is waiting for a valid context it captures all the logging calls made to it and stores them in a queue. Once the GameContext is loaded and ready, a internal logger instance is created and the queue is flushed to it. From that point on logging calls flow through to the internal logger instance.

I’ve included an example of the code below.

public class DeferredNoirLogger<T> : INoirLogger {
    private readonly NoirBehaviour<T> _context;

    private INoirLogger _internalLogger;

    private readonly List<Action<INoirLogger>> _internalLogCallQueue = new List<Action<INoirLogger>>();

    public DeferredNoirLogger(NoirBehaviour<T> context) {
        _context = context;
    }

    public bool Enabled { get; set; }

    public LogLevel Level { get; set; }

    public IEnumerator CoWaitForGameInitialization() {
        var context = GameObject.FindObjectOfType<NoirGameContext>();
        var wait = 1f;
        while(context == null) {
            yield return new WaitForSeconds(wait);
            wait += 0.1f;
            context = GameObject.FindObjectOfType<NoirGameContext>();
        }
        _internalLogger = context.CreateLogger(typeof(T));

        foreach(var call in _internalLogCallQueue) {
            call(_internalLogger);
            yield return null;
        }
        _internalLogCallQueue.Clear();
    }

    public void Debug(string message) {
        if (!_context.LoggingEnabled) return;
        if ((int)_context.LoggingLevel < (int)LogLevel.Debug) return;
        if (_internalLogger == null) {
            _internalLogCallQueue.Add((l) => l.Debug(message));
            return;
        }
        _internalLogger.Debug(message);
    }

    // ... more calls like Debug() for all interface methods
}

This immediately fixed my issues with exceptions on game startup. Getting game configuration within gameobject Awake() methods is still an issue however. As a workaround I’ve moved all the code that depends on configuration into Start() for the gameobjects that need it. This should be good enough for a while and I really hope I won’t have to craft some kind of deferred configuration system.

So that’s a quick-ish update on all the things that I’ve been working on. I’m working on another dev log video, which will cover the first alpha that I created, including the feedback recieved and changes I made coming out of it. If you haven’t already follow the game twitter account, subscribe to the youtube channel and check back here for more updates on Electric Noir!

Enemy States & Logging

2019-09-29T06:00:00+00:00

I’ve been spending my time the past few weeks cleaning up various parts of the enemy code in Electric Noir. The feedback from the alpha made it clear that the enemies – though basically functional – needed a lot of improvement.

One of the biggest inconveniences of the codebase was the lack of a standardized way to handle enemy state. Enemies were just a collection of methods that would get called depending on which one the enemy code set into a pointer.

This worked, and probably would have worked well in a game that didn’t need a ton of shared enemy logic, but with so many enemies sharing similar logic it was obvious afterwards that this approach was going to cause me a lot of pain later on.

So I put together a pretty basic state machine where states are classes that can be created or inherited – to help share state code between enemies. It’s nothing spectacular, just enough to do what I need at the moment.

Each state implements the following interface.

public interface IState {   
    INoirLogger Log { get; set; }
    void BeginEnter(MonoBehaviour owner);
    void EndEnter();
    IEnumerator Execute();
    event EventHandler<StateBeginExitEventArgs> OnBeginExit;
    void EndExit();
    void OnDrawGizmos();
}

Each state has BeginEnter called when the state is being transitioned to, with EndEnter being called once the state is fully in control. After that Execute is called in a loop until it no longer yields or BeginExit is called with a new state. EndExit is called once the state is transitioned away from.

Having this simple standardized process around states lets me share more code across enemies – and other objects that can use the same states, like bosses, or companions. This will make creating new and interesting enemy archetypes much easier than before.

I’ll cover the OnDrawGizmos method in another post, but yep, each state can draw their own gizmos. The INoirLogger, as you’ve probably guessed is my custom logger, which I’ll talk about next.

I needed to start collecting logs so I could request them from folks that encountered issues. A lot of players reported issues where the dialogue system was broken for them, or a cutscene didn’t play right (I’ll cover more on those in another post).

Having some logs to look at would help a lot in tracking down those issues. Right now all I have to go on is whatever the player typed up in their feedback, which isn’t a lot.

Logging was a bit harder to get into the game, mostly because I wanted logging to be able to be added easily to any object that wanted it, and to have it be performant enough that it could handle being called in an update loop during development without crushing the game performance.

After a while I ended up with a logging system I’m pretty happy with, it supports logging levels, which can be overridden by component, and it’s initialized automatically at the start of the game and added to my base MonoBehaviour, so it can be used anywhere I need it.

I’ve included a small sample below showing the debug logs for an enemy switching from their EnemyIdle state to EnemyAttack. Another bonus of the logger is that it automatically includes the frame number in debug mode.

2019-09-29 00:14:55 DEBUG [EnemyIdle] frame=1868 ChangeStateImmediate newState=EN.Enemies.States.EnemyAttack transition=NoopTransition
2019-09-29 00:14:55 DEBUG [StateMachine] frame=1868 HandleStateBeginExit nextState=EnemyAttack transition=NoopTransition
2019-09-29 00:14:55 DEBUG [StateMachine] frame=1869 Execute done. Waiting for transition state=EnemyIdle
2019-09-29 00:14:55 DEBUG [StateMachine] frame=1869 Execute running transition Exit() state=EnemyIdle
2019-09-29 00:14:55 DEBUG [StateMachine] frame=1870 Execute switching to new state state=EnemyAttack prevState=EnemyIdle
2019-09-29 00:14:55 DEBUG [EnemyAttack] frame=1870 choosing next attack
2019-09-29 00:14:55 DEBUG [EnemyAttack] frame=1870 attackType=Quick
2019-09-29 00:14:55 DEBUG [EnemyAttack] frame=1870 move=Quick Jab hDmg=120 wDmg=80
2019-09-29 00:14:55 DEBUG [StateMachine] frame=1870 Execute running transition Enter() state=EnemyAttack
2019-09-29 00:14:55 DEBUG [EnemyAttack] frame=1871 SetupAnimation creating AnimatorOverrideController
2019-09-29 00:14:55 DEBUG [EnemyAttack] frame=1871 SetupAnimation overrides=3
2019-09-29 00:14:55 DEBUG [EnemyAttack] frame=1871 SetupAnimation Attack=TestEnemyQuickJab
2019-09-29 00:14:55 DEBUG [StateMachine] frame=1871 Execute running state state=EnemyAttack
2019-09-29 00:14:55 DEBUG [EnemyAttack] frame=1871 Execute playing animationState=Attack

The format of the log is {timestamp} {loglevel} [{component}] {debuginfo} {logmessage}. One of the more important parts of logging is that you want to keep like information lined up as much as possible. It makes scanning the log file a lot easier.

I’m definitely happy with these two new improvements to the game, I’m going to be sharing a few more code and internal system updates in the coming weeks as I work through the feedback from the alpha.

Art Log: The Main Menu

2019-09-06T06:00:00+00:00

The first look at the new main menu for Electric Noir! It shows off the city, some of the weather as well as the “Rise” (slang for high rise) that the player lives in – and where the game gets its name from :).

It’s laid out in Unity using a timeline + cinemachine for the camera movement and custom scripts for the menu and parallax effect.

Alpha Playtest Results & Alpha 2 Plans

2019-08-29T06:00:00+00:00

Hey everyone, It’s been a few weeks since the first alpha release and I’ve been wanting to post an update on how the release went, the feedback I’ve gotten so far as well as plans for Alpha 2.

Before any of that I want to give a shout to everyone who played the alpha. Thank you so much for playing and giving your input on how to improve the game. It’s amazing to see how many of you love the game so far and care about making it the best game possible!

The Results

So far the feedback has been really really good. I’ll post some screenshots of comments I’ve received and the rest I’ll break down by topic/issue ’cause a lot of folks noticed the same few issues (as you’d expect).

The Goals

The goals of the alpha were two fold:

Build/Test the combat and player movement mechanics, basically all of the combat game loop
Get feedback on the narrative game loop design – this was still in early development, but the narrative is going to be a big part of EN so I wanted to get it out there ASAP.

The Good

Everyone liked the look of the characters, and the environment. I didn’t get any negative feedback on the art style, which is a big relief because other than the actual mechanics, it’s the part of the game I stress over the most.

Also, folks called out the dialogue/lore as something they enjoyed and wanted to know more about. This was unexpected, the section of the game that I released is extremely far into the narrative, but it checked the two goals for the alpha best so I ran with it. Glad it paid off here.

The Not So Good

Ok, time to talk about the things that need to be worked on:

Cutscenes – Pretty much everyone ran into bugs with the cutscenes. Characters didn’t play the right animations, or you could even trigger animations during them, music did or didn’t play, the wrong music played, wouldn’t stop playing, kept playing on the menu, dear god make the music stop playing…

Stamina, Cool-downs, Health, “Mechanic Feedback” – There is a stamina system in EN, there is also a internal cool-down setting for each attack – to prevent spamming. Seems I left this value set too high for pretty much every attack as almost everyone ran into issues where they couldn’t attack even though they had stamina.

Also the UI feedback for healing – when you can heal, how much has healed, when you take damage, isn’t very helpful to the player.

And the gun. Yeah, the gun has problems too. Namely it’s not clear how the ammunition works with the gun. This is because honestly, I’m not even sure how the ammunition system should work with the gun. I should have pulled the gun from the alpha since it wasn’t 100% but I yolo’d it and am now sorry I did.

Actual mechanical issues – Thankfully there aren’t a ton of these. Players mentioned that Ode feels too fast when moving, but their attacks freeze them in place when they feel like they should move them forward.

Also none of they players said they enjoyed having to stop while firing the gun. Having the player stop to aim was a conscious design choice on my part, I wanted shooting to be a risk during combat, something the player would have to use tactically, rather than as a crutch during fights.

I already plan to spend more time on the guns ammo, so revisiting the rooted while shooting mechanic is also on the list of stuff for Alpha 2.

Alpha 2

This conveniently segues me into the next part which is all about whats on the agenda for Alpha 2.

I already mentioned the gun, but… yeah the gun. All the gun mechanics are on the exam table for the next update.
Fixing those cutscene bugs
Fixing stamina related combat issues. I want the player to be able to attack whenever they press the button (within reason). A dev friend of mine suggested always allowing the player to attack, but reducing damage when out of stamina. I think this is what I’ll try in the next update.
More narrative focus. Time to double down and really put some effort into the narrative aspects. This includes:
Fixing dialogue system bugs
Adding in quests and crime investigation mechanics
Expose a bit more of the lore and setting of Electric Noir
New enemy! I want to add a new enemy to the game to try and change up the combat a bit. The combat in the last alpha was more ranged than I think I want for the game. Yes, it’s the future and folks canonically will have guns, but I didn’t like the ranged combat in that level as much. Possibly because of all the gun issues I need to work through, but focusing the combat on melee should help find more of the fun in EN.

As for a timeline on the next alpha, I don’t have a release date explicitly set yet, but it’ll drop sometime in September. I’ve already been working on a few of the issues and I’ll be sharing more progress on the Electric Noir twitter account, so if you liked the alpha or what you’ve read here, be sure to give it a follow for more updates!

Also, as promised I’ve included some highlights from the feedback that I got from the last alpha below. I’ve got a lot of exciting work to show off in the next alpha, I can’t wait to release it!

Electric Noir Alpha is out!

2019-08-09T06:00:00+00:00

Hey Everyone,

I’ve been working on this game, Electric Noir, part-time for about 6 months now and it’s finally in a spot where I can get some constructive feedback on a few of the core systems. This version here contains a single area of the game built to show off some of the games narrative and combat systems.

I’ve made a few small games before, but nothing quite like this before and would love some feedback or suggestions on how to improve on it.

You can download the game over on itch.io: https://literally-a-cat.itch.io/electric-noir

And you can submit feedback about the alpha here: https://forms.gle/GgDTy2wvSqMPLqXTA

Can I Stream the alpha?

Yes! I’d recommend starting up the alpha before you stream, just to be sure it launches ok and looks good. Also, if you know you’re going to stream it ahead of time hit me up on twitter @codeimpossible , @electricnoir or on twitch @literally_a_cat as I’d love to see you play and be there to answer any questions.

Thank you so much for playing and I hope you enjoy this first alpha of Electric Noir.