I now finished the platformer movement (with momentum, coyote time and all fancy things like that), switches and platforms (and I guess speed pads that I made accidently). I'm gonna now work on the main mechanic of overheating.

Don't ask

https://www.youtube.com/watch?v=FuhYxeMvJJA

Who cares about the game, the UI looks cool (and lags behind the camera when you move it).

Admire the UI here

I've made a surprising amount of tools for this jam, which really sped up the game making process.

Ruler

I've made this ruler which could store different length presets. It allowed me to accurately measure the distance between every platform without having to guess and test over and over again.

Test point

In day 3 I've started working on the hardest section which took a lot of time to test. As it was at the end of the level I had to frequently fly there, which got annoying pretty fast. This is why I've made the test point - a point which I can place anywhere in the scene and quickly teleport to (+ enable some debug settings for testing).

Console

My game was using qASIC (my own asset) and it's built in developer console. I've made a lot of commands during the jam, which proved to be really useful. Here's a few: - noclip - For flying - speed - I think it explains itself fairly well - testpoint - Teleports to the test point and disables heat - stopheat - Stops the heat clock

Debug displayer

Once again, the debug displayer is a part of qAISC which allowed me to easily display information on screen. At first I didn't have any UI and the displayer proved to be quite a handy tool.

Interested?

You can play my game here and see if the tools were worth it.

Me and my friends want to ditch the theme this time and make a 2d platformer. Problem: these are normally played on a controller. And currently my Input System which I plan on using doesn't have gamepad support yet. So I've decided to at least attempt adding it before LD starts.

Gamepad support required me to completely rewrite core systems inside Cablebox (aka. the input system). And the result of that is better, more flexible code + 689 different bugs in the editor.

Here's a list of what's broken and has to be fixed before the jam:

• every method inside of the Input Manager
• Input Map Editor window
• Input Map inspector
• reading keys

And here's a list of what's broken and would be cool if it was fixed before the jam:

• rebinding
• referencing
• saving
• commands

My progress

Today I wanted to start out with the Input Map Editor, as it's almost like a brain of Cablebox. It holds every information about input in the project and is required by almost everything. The main problem currently is that the inspector is completely busted. In the old version, everything UI related was handled inside of one script under a big switch which was a hassle to work in. This is why the new version uses different classes, reflections and other garbage to make it less painful to add new features for me.

However I might have screwed up a little bit, as I wrote the drawers before I added support for them. I used a lot of serialized objects & properties and turns out, you can't just create them from a simple class. I am a little bit stuck, because I want to use them, but I think I will have to ditch them for the time being and use the old Unity GUILayout calls instead.

Closing thoughts

Today I didn't have much time, but I still have high hopes. Worst case scenario I will scramble some janky xinput implementation during the jam alongside an old version of the input system. Wish me luck

Introduction

I have finally fixed / commented all of the bugs. Now it's time to finally start re-adding features.

As I said previously: editor is my main priority and luckily I've managed to re-add most of the essential features. I can add and remove items, edit some very basic values and save. I had to jump into the mess that is the content tree and trim out almost all of the code. And finally, here we are.

Deleting items

Everything was easy to reimplement, except for deleting. Currently there are 2 ways of deleting items: by pressing the minus in the content tree (easy) or clicking the delete button in the inspector (hard). Because the inspector doesn't know what and where the item is located I had to make a separate virtual method to handle that for every item separately. So in the end I have this lovely peace of linq code.

Inspector

I unfortunately don't have enough time to add the fancy inspector concept from my previous post, so here's the ugly version...

Normally the keys should be separated into individual lists and there should be a popups instead of the ugly text fields. As you can hear, this isn't that simple or fast to add. So unfortunately I will have to write the paths manually for this jam :/

The same is with axes: normally there should be a button to select a binding, but for now you will have to copy and pase the guids manually.

Broken things

Sadly, not everything is working. This includes: - window preferences - editing groups in the inspector - duplicating items - error icons next to items

They however aren't ascrutial as the other features, so I'm not gonna add them now. Worst case scenario I can just enter debug mode and edit the map in Unity's inspector or edit the file manually in notepad.

Next features

Next I'm gonna work on reading input and hopefully adding gamepad support using xinput. From what I read, xinput is fairly simple to get started with, so I have high hopes it's gonna go smoothly

Welcome back to this weird series where I refuse to just use Unity's Input System and crunch before jam for no reason. Luckily, I have made good progress this day, so I hope the pain will go away soon :)

Reading input

Finally, I am able to read device input. It was surprisingly easy, as I had all of the device code already written. I just had to modify a couple lines of code to make it work with the recent changes and here we are.

For reading gamepads I'm using Unity's Input Manager, which isn't great. The main issue with it is that it changes it's mappings between operating systems. It's working ok on my windows computer, but I have no idea what will happen if someone plays my game on a macbook. This is why I need XInput, because I do not have the resources nor time to worry about this (also, you can't use vibration for some reason).

Gamepad deadzones are also working. Even my drunk xbox360 controllers stay on 0,0 when I'm not touching them. This was also quite easy to setup, as I just copied code from Unity's own Input System.

Saving & loading

I have managed to add a very temporary save system. In the old version of Cablebox, you can select how the preferences get saved. In this version I want to allow people to even make custom providers. However: I don't have time for this, so I settled on a basic json serializer.

Cablebox also has multiplayer support, which means that there can be multiple players with different inputs and bindings. I temporary forced Cablebox to add every device to the first player, because of saving. It's not like I'm gonna be making a multiplayer game any time soon (and especially on LD).

Remaining systems

I am really close to finishing and I have 2 main features remaining: - input remapping - xinput gamepads

Input remapping should be easy (famous last words) and I will have to look into how xinput works. For now, that's all I have. See you tomorrow

Today I've managed to finally finish the Input System :). Of course nothing's perfect and I will have to add and rewrite a lot of things after the jam, but for now it's good enough to make a game with.

XInput

As I said before, I was using Unity's legacy Input Manager (UIM) for handling gamepad input. If you don't know: UIM sucks, especially if you're working with gamepads. So I've decided to ditch it and instead use xinput.

Turns out: xinput is kinda cool. It's fairly simple and easy to use. It may not have the best support for non xbox controllers out of the box, but for making simple game's it's more than plenty. ~~besides, steam input handles everything these days anyways.~~

Referencing input

If you want to get the state of an input, you can call it out by its name via the Input Manager. However, this isn't the best, as you have to know how something is called. That's where input references come in: they are just a fancy string that stores a reference to an item and allows you to select it in a window.

In the old version, they used to store the group name and item name, which worked, but could easily break when renaming items. And since this new version uses guids, the references store those instead.

Togglers

Another great feature of qASIC (a collection of tools which this input system is a part of) are the togglers: they are just these really simple scripts that toggle objects when you press a button. They are great for pause menus, hiding UI and even toggling things such as a cheat console. Because they are so simple, they required me to literally modify a single line of code to get them working again.

Remapping

This was another interesting one. I don't want people to remap gamepad keys in the keyboard menu, so I had to think. In Cablebox keys are stored as paths (e.g. key_keyboard/W, key_gamepad/RightStickUp). This makes my job fairly simple as I just need to check the root path to identify the controller type.

Also, the keyboard device was listening to my mouse. You can imagine how fun it was to click and automatically assign my mouse on every binding. So I had to implement a small keycode exclude list and there we go.

Finished?

At this point I've compleated every required feature for Cablebox to function. Now I'm gonna do other pre-jam activities and get ready for this thing. It's been fun, but everything has to come to an end at some point.

Also no, I won't release this thing, it's probably unstable and I will probably have to crack it open during the jam anyways. For now there's the old version that doesn't have gamepad support, but it's really bad compared to the development version.

Every jam I use the newest LTS version of Unity and every jam I need to face 300 different stupid engine errors. This jam is no different.

On LD50 Unity liked to not compile scripts randomly. Let me repeat: the engine doesn't use the code I write. This LD I had the pleasure of using the new "very stable" 2021 LTS and it's even worse.

Random exceptions are here as per usual, but this time we have a new exciting feature: ctrl+z crashing. If you duplicate an object and then undo, the editor crashes.

And even if that wasn't enough

The crash reporter itself crashed on me while I was sending out a bug report

This jam, along with my friends, I've made a game for the extras category. It was purely for curiosity sake and because the "EU friendly time" was quite unfriendly for me, as an European.

The bad

In total we've spent 3 weeks, but they weren't as intense as the first 3 days. Having a lot of time makes you approach games differently, which is both good and bad, as I think I would have perished if I crunched for 3 weeks straight. And that large amount of time has also made us feel really tired.

The good

I can't say that it gone all for nothing. This game was using a custom input system which I've been working on for the past 2 years. It had some issues I had to fix during the jam, but I've even managed to code custom dynamic prompts that change depending if you use a controller or a keyboard. Sadly, saving keybinds doesn't work yet so I didn't include rebinding.

Conclusion

I think there is a reason that most jams take place during the weekend. You can dedicate a lot of your time and focus for a few days without many repercussions. Opening up an editor for a couple of hours daily won't get you too far. But at least I have the cool prompts :)

Dear gentlemen. I've submitted my game yesterday and I don't have much time to get the necessary karma. I would be really thankful if you could help me get to those 20 reviews

Play it here

So I've decided to ditch Unity and try out the Stride engine. So far: it's horrible and I love it. I had to do so many different hacks to get the most basic features working which is really cool. Next jam I'll probably write libraries that will do the work for me, but for now I have to figure out things like the fullscreen toggle.

I've also decided to use my own "remote inspector" for viewing logs. It crashes often (especially when closing the game), but I hope it will be useful for me and others in the future. Right now it's a console app, but I'm planning to make a proper one in godot.

I use 2 textures for walls and ground. I'm incapable of making my own, so I'll have to give up on compo

https://youtu.be/9TskaAdFWys

I frogof the pen for my drawing tablet, so I can't make art until Monday :(

I wanted to use bevy + rust this jam, with no bevy or rust experience. It was going great until I couldn't get even the examples of a physics engine working and it seemed like an issue that would take me way too long to fix

So I switched to my ""trusty"" Stride, but it had problems with compiling shaders, which would also take too long to debug

Now I'm installing godot. I swear, if this engine won't work, I'm gonna lose it