Forem: Seb

4 months of being a firmware programmer

Seb — Fri, 28 Apr 2023 16:05:00 +0000

Back in January, I transitioned from working in a high-level programming job (making apps in Unity) to a slightly more low-level job, which includes engineering ESP microcontroller firmware. Some may call it a leap of faith, because the difference is like night and day, but I felt like I needed a change and had a desire to improve my knowledge in different fields of computer engineering.

First impressions

Coming from C#, I had little to no knowledge of C++. But being fairly proficient in C#, I felt confident about the idea of learning a whole new programming language. So it started, I found my old and dusted ESP32, which was lying around my table, and flashed my very first C++ Arduino firmware onto it. I knew some stuff about microcontrollers, as I had experimented with them a little about 4 years earlier.

I created a few example programs, such as making the onboard LED blink every 2 seconds, or initializing a BLE (Bluetooth Low Energy) advertisement and being able to connect to it from my phone. All this was pretty exciting stuff. I felt a totally different feeling while working on this very tiny computer, contrary to developing software that runs on normal personal computers.

It felt impressive to me to be able to hold something so small and see my code running on that tiny engineering masterclass. After my "being in absolute awe" phase, it was about time to get back into reality and discover even more interesting stuff about these microcontrollers.

Actual work

I had been interested in microcontrollers for some time prior to this work opportunity. Albeit, the job itself was really the reason why I got interested in this field of computer engineering once again.

I cannot disclose much about the job itself, except it being a firmware programming job. When I joined the company, the product had been in development for over 3 years, which meant I had a lot of catching up to do. I would lie if I said that I was not shocked by the sheer amount of code, that had already been produced by my colleagues.

Fast-forward a few weeks, my onboarding has been going on pretty well. I was getting familiar with more code every day and I was ready to get into programming new features and squashing bugs.

Summarized feelings after 4 months

All I can say is that I thoroughly like the job and I enjoy working in this field of IT.

The essential difference (except that it is a completely different programming language) is the environment that it is set in. Back in my old Unity and C# days, I did not really care about the code optimization or speed, as it was always running on a machine that consisted of about 16 gigabytes of RAM, which was more than enough to execute my code.

On the other hand, when working with an ESP, you are given about 1 megabyte of RAM. That is about 16 384 times less. Therefore, you attempt to write the most lightweight code possible, and I enjoy thinking outside of the box to achieve this ultimate goal. I also feel that this harsh environment pushes me to my limits every day, and evolves me as a programmer.

Outlook on the future

I am looking forward to discovering more interesting pieces of information about the microcontroller world. At the same time, I want to push myself out of my comfort zone to gain more valuable experience as a programmer and a hardware engineer.

Now, I shall focus on developing my skills again. This journey has been very fun so far, and I cannot wait to see what the future brings. See you soon!

Creating an escape room game in Unity

Seb — Wed, 07 Dec 2022 20:34:32 +0000

What and why?

I've been thinking for a while, which game prototype I could work on in my free time. Working on various prototypes and things, which differ from my normal job can be a fun way to test myself and expand my knowledge in slightly other and new things. I've come up with few ideas (which were expanded by ChatGPT, who I might cover in future posts), but ultimately I've settled with an escape room game. First person, basic movement and a possibility to interact with virtually anything were some of the key aspects I had in mind when starting this project.

So I've started working on some core components of the game. While working on these, I've figured that it might not be a bad idea to write down my progress (hopefully every or every other week). First point why this might be a good idea is some sort of restrospective. I can open any of these posts at any time and analyze the code, tell what could've been done better and so on. Other one is to keep consistent progress and try to keep the project development going.

With all that being said, I think it's about time to look into what I've done this week and try to explain the written systems as best I can.

The game

Character

Most of the stuff I've done is the simple "starting ground" work. I've written a pretty simple Rigidbody Character controller script, which takes care of first-person camera and all the common operations, such as clamping the player's look rotation, so they don't go upside down and similar things.

I think the Character controller is not very interesting, as it is really basic.

Items

One of the key components is an item system. An easily configurable code, which can be put on as component on any GameObject and should be ready to use. The very important thing when it comes to items is interaction with them.

Say we have a key. Key is lying on the ground and I want to pick it up. In some games, you walk over the key and it picks itself up automatically. As long as it's a pretty good solution, I've wanted to come up with something more robust.

IInteractableController

I've come up with a concept of IInteractableController. The code is pretty simple.

public interface IInteractableController
{
    void OnInteract(IInteractable interactable);
    void RegisterParentDependency(IInteractable registrable);
}

Its sole purpose is to call OnInteract function on its parent IInteractable dependency.

ProximityPrompt.cs, for example, implements IInteractableController. It handles some logic of a player being near the GameObject (the component is on) and in some way (be it click or hold of a button) triggering an OnInteract event. When this event is fired, IInteractableController lets its parent IInteractable know that the Interactable has been interacted with.

Then I have class Item, which wraps some logic above an Item concept, such as Name and if the item is Stackable.

public class Item : MonoBehaviour
{
    public string Name;
    public bool IsStackable;
    public virtual void OnInteraction(Item item)
    {
        Player.Instance.Inventory.AddItem(new InventoryItem(item.Name, 1, item.IsStackable, item.gameObject));
        gameObject.SetActive(false);
    }
}

Yes, I cam using singletons and it is something I might change in the future.

As can be seen, Item (which is a base class for any other inheritied items) contains some metadata as well as a OnInteraction which always adds the item into an inventory. This is something I might want to play with, in case I have "Items" such as Door, Gate, or similar. In that situation, though, it will be a better idea to simply not inherit the Door.cs class from Item, but still make it implement IInteractable, so I get the HandleInteraction() function.

Ultimately, we come to the Key class definition, which currently looks like this:

public class Key : Item, IInteractable
{
    public IInteractableController Controller;

    private void Start()
    {
        Controller = GetComponent<IInteractableController>();
        Controller.RegisterParentDependency(this);
    }

    public void HandleInteraction()
    {
        OnInteraction(this);
    }
}

It has a reference for IInteractableController (which is a component on the GameObject) and in the Start function it registers itself as the parent dependency (later used for the calling the Interact event).

This is pretty much the whole logic of the Items in the game, as of now. Some stuff I will surely want to add in the future is some concept of Use() function in the base Item class, which will handle a scenario when user has an item equipped and presses the Use [E] key. That will be used for unlocking door, chests and closets.

Player

One last small thing is the Player structure. I wanted to keep stuff simple (that's why it's a singleton again).

public class Player : MonoBehaviour
{
    public static Player Instance;

    public Character Character;
    public Inventory Inventory;
    public bool IsControllable = true;

    private void Start()
    {
        Instance = this;
    }

    public void ChangeControl(bool isControllable)
    {
        IsControllable = isControllable;
    }

    private void Update()
    {
        if (IsControllable)
        {
            Character.ControlLogic();
        }
    }
}

This takes care of seperating the logic from the character movement and other events which will be happening. This so far looks like a viable solution, but time will decide if it's good.

Conclusion

I think that's all for now. I can mention work I've done on the UI part of the game, but there is not that much code, because there is not much logic just yet.

That's it for now. I would say it's a pretty good start of the project and the game is slowly becoming a (little playable) thing.

I will see you in a bit, to talk about more code I've written.

The importance of using moderns tools with Unity

Seb — Fri, 18 Nov 2022 21:05:00 +0000

Programmers work with various tools every single day. Starting from the very low-level parts of software, such as operating system and finishing somewhere little higher around modern IDEs and other time-saving programs.

There's no discussion that every software engineer uses text editor of some sort. While some use old school editors such as Vim or Notepad++, others tend to lean towards slightly newer software, which generally offers more modern and handy tooling.

When it comes to using IDEs (or text editors) with Unity, there is definitely a vast amount of software to choose from. The most popular IDE to use with Unity is probably Visual Studio 2019, which comes preinstalled with the first Unity version you download.

Other very popular IDE to use with Unity must be JetBrains Rider. An extremely robust piece of software, which helps you speed up your development process. I've been personally using Rider with Unity close to a year now and it's been such a time-saver.

The wake up call, which I've got from using Rider extensively for almost every day of the last year, was the importance of using moderns tools. To be fair, while working in VS or VSCode, I've only used a little amount of tools provided by the software. This came to haunt me with countless hours of debugging foolish mistakes, which were simply caused by my ignorance of the tools I've been provided with.

I've started using few debugging tools, but primarily smaller features, such as the godlike Refactor This command, which saves so much effort and time. With this command, you can, for instance, rename any class or function (and much more). The great thing about this is, that it renames all dependencies (or specifically usages), so you don't need to go through all of your code line by line and find it yourself.

This is a really tiny portion of features a modern IDE can offer. The important thing is to avoid the crucial mistake I've done, which was not using these to a full extent and thus making things harder for myself. Use every bit of tech you can and make things easier for yourself. It will definitely make the process of development a tad more enjoyable.