Joonaxii

Don't forget to Wishlist CODE Bunny on Steam to be ready once the 1.4.0 Update drops! There will be a discounted price for its release too! 🐰🙏

Wishlist Below ✅

#CODEBunny #WishlistWednesday #IndieGame #GameDev #IndieDev

Boss Rush Mode, extra Save Files, and More...

Version 1.4.0 of CODE Bunny is releasing This Month!
Free Update, of course ;)

#CODEBunny #ScreenshotSaturday #indiegame #indiedev #gamedev #indiegamedev #gaming #Update #jogobr #indiebr

I was planning on making it a 16 bit ref to contain a bit of extra data for some sort of categorization like you mentioned, but that wasn't really relevant right now so I at least for now, to simplify implementing the system, I left it as just a byte. So it should be possible to implement later.

I would've liked to decouple the actual input definition (so keybinds etc) stuff too, but Unity does need to serialize that stuff.

The "Core" of the system is a C# library I wrote, which takes in an IInputProvider interface which is used to pass the current state of gamepads & keyboard etc.

Thank you! I'm real happy how this new Input System turned out, especially considering the old one I wrote years ago was such a nightmare to deal with in editor & in code.

I was going to use platform specific APIs to fetch inputs, but figured using Unity as said "API" was better in this case.

That's I think all of the important & interesting parts of the new Input System.

Also, I will be releasing this Input System on my Github at some point, also including the Localization System since it uses the same libraries I wrote too. I'll have to first create an example project for it though.

Screenshot of the Old Input System's JSON file. It's a big mess of unused fields & input codes being specified as strings AND integers making deserialization a nightmare. The JSON's file size is also around 10KB larger than the new Input System's.

Screenshot of the new Input System's input map's JSON file. It's much more compact & only uses integers for input codes making deserialization easier by sacrificing a *tiny* bit of readability. Unfortunately the input map JSON being this different from the old one also means that I can't really migrate the old input map JSON to the new one. Or technically I could, but it would take quite a bit of time & code to do so for now I've opted to not upgrade the old input map's JSON to the new system meaning player's will unfortunately lose their old keybinds after updating.

Another very good change is the way I serialize the mapped inputs to a file. Before I was only using Unity's built in JsonUtility which made the old Input System's JSON be a BIG mess. For the new one I manually write only what needed. Below are screenshots of both with extra info in alt text.

Screenshot of the Old Input System's Icon config. It's literally a list of foldouts for EVERY SINGLE input value in Unity's KeyCode + some extras for gamepads. It's really bad & really difficult to assign icons to. It's also really bad with different controller icons, which is why before we only supported Xbox & PS icons.

Screenshot of the new Input System's Input Icon Config. This is much better than the old system's icon config. It's a grid of inputs for all +200 inputs separated into pages. The assigned icon is also shown in the grid for each input code. There are also tabs for each supported input display type. The generic one is the base which contains Keyboard & generic gamepad inputs. The other tabs for Xbox, PS, Switch, Switch Pro, Steam Deck & the Steam Controller only need to assign the inputs icons specific to them, the ones that are left unassigned will use the Generic input icon instead.

The Input Icon config in the old Input System was a really big mess too which I made miles better in the new system, below are screenshots of both with more info in the alt texts.

A screenshot of the code for the InputRef struct used to reference inputs in code. The low 5 bits are used for the input index within a group & the high 3 bits are used for the group index. This way we can use the actual byte value as the index meaning accessing inputs is a really fast O(1) operation. I also wrote a custom editor for the struct which displays the group & input as a drop down making it easier to select inputs in the editor.

A screenshot of J-Input System Module in the Unity inspector. Which displays what the InputRef looks like in the editor.

Another thing I got from my Localization System is the way we reference inputs in code & by in the editor. Instead of strings like I used before, the new system is assumed to have a max of 256 total inputs which means the ref can just be a single byte. This makes accessing inputs easy & super fast.

Screenshot of the code for passing Unity's Input System's Gamepad state to my own Input System. Not the "prettiest" code, but I also don't really know how Unity's Input System works so this was the best I could come up with, at least for now. At least it works.

One thing I should note too is that the new Input System does use Unity's new Input System, but not in the way it's "supposed" to be used, instead I just pass keyboard & gamepad states to my Input System from Unity, making it so the system is cross platform while not changing how it should be used.

Screenshot of my new Input System's Input Configuration editor window. It's a essentially a grid of inputs & has a few tabs for different input groups & other input system related configuration stuff like the tab for Input Icon Config.

Just before writing the new Input System, I also had written my own Localization system which taught me a bit more how I should approach the configuration editor window in the new input system too. It might not still be the "best" but it's way better than the old input system's custom inspector.

Screenshot of my old Input System's messy Input Configuration in Unity's inspector tab. It being only a custom inspector meant that all the input groups & inputs under said groups are foldouts & hence really "ugly" because of the massive amount of indentation etc.

The main reason I made the old input system was that Unity's own new Input System was still new & Unity's Input Manager is much not the greatest. At the time my Input System felt like a cool thing, but looking back, it's a real mess. Below is part of the input configuration of the old input system.

Time to be more active here.

I've been programming for #CODEBunny since like 2020, mostly "invisible" systems. One of the first things I did was make an input system. It was a buggy mess so not too long ago, I started re-writing it from scratch. This thread will go over the the old & the new one.

From version 1.4.0 onwards, CODE Bunny will support multiple save files! We hope to enable players to enjoy the game's story multiple times without sacrificing their unlocked skills, as well as speedrunners who prefer Classic Mode.

Something cool happens if you clear levels in different save files!

CODE Bunny - Available Now on Steam / Coming Soon to All Consoles (Switch, PS4, PS5, Xbox ONE, Xbox Series X and S)

Surprise! CODE Bunny now has a Publisher!

We're now part of Nuntius Games ( @nuntiusgames.bsky.social ) , a Braziliam Indie Game Publisher!

CODE Bunny will Release in All Major Consoles sometime in the upcoming months!

#CODEBunny #indiegame #indiedev #gamedev #indiegame

CODE Bunny on Steam Axel and Hazel are members of the VY Space Program. When the new enemy dubbed Mad Bunny threatens the project, they must fight, as they uncover a hidden conspiracy... CODE Bunny is a 2D-Action Platfor...

CODE Bunny is a 2D-Action Platformer where combat mechanics and high-speed movement merge together!

✨Wishlist it on STEAM!✨
store.steampowered.com/app/3303780/...

#CODEBunny #Steam #Indiedev #Gamedev #Indiegame #wishlistwednesday

Hi, Bluesky.
Meet our game!

Hey Rami! I'm kind of late to this, but you don't follow me & I like to at least think I make cool stuff. I am a game programmer (technically an engine programmer too). Haven't posted much here yet but meaning to when I have something worth posting.

An assortment of asset icons I've drawn for my engine shown in Aseprite. Icons are as follow. Row #1, 2 regular rectangles, 2 folder icons (empty/with items). Row #2, an Unknown Asset, Binary/Raw Data Asset, Text Data Asset, JSON Data Asset. Row #3, Scene Asset, Beatmap/Music Section Asset, Audio Clip Asset, 2D Texture. Row #4, Render Texture, Font Asset & last but not least, Atlas/Sprite Asset

Better post something here too, I've been drawing some editor icons for my game engine's different asset types. Not much but at least I have some way of differentiating them from one another now. More will be added when I add more features etc. :D