DEV Community: Laimonas K

Why You Should Make a Game Engine: 5 Years as a Developer

Laimonas K — Tue, 15 Aug 2023 18:05:29 +0000

They say time flies when you are having fun. I can definitely vouch for that, especially since I made the switch from being an architect to becoming a software developer five years ago.

With my background in art and design, I found a whole new world of enjoyment by messing around with the HTML canvas and exploring the visual side of coding. So, it was pretty natural for me to get curious about making games. At first, it was just a little experiment driven by curiosity, but over time, it grew into something more. It turned into my personal playground where I would keep coming back to add new cool stuff that I learned throughout the year.

The journey had its highs and lows, with moments of victory and some major letdowns. But there was always one thing that kept me going: the game itself.

Here's my story.

Year #0 - Improvise, Adapt, and Overcome

It all started like most stories do – a feeling that my current path, even though successful, was missing something important: joy. It was draining me both physically and emotionally. I knew something had to change.

By then, I had a bit of experience with coding. I had made my own portfolio website (a standard thing for architects), worked on simple websites for other businesses, and dabbled with coding in general. But never did I think of coding as a career option. How could I? I had invested so much time into architecture already.

Around that time, coding schools were popping up all over, promising amazing opportunities. I talked to some folks from a coding school just next door to where I lived. They had these full day 3-month courses that guaranteed job placement with a sort of "trust me, bro" assurance. I was skeptical but a course, which was like a full-time job seemed like a good way to stay focused. So, I set a simple plan: one year, go all in, no ragrets.

The courses covered the usual suspects - HTML, CSS, JavaScript, PHP, Laravel - basically, the whole shebang to make you a junior full-stack developer, even though that title makes little sense. But out of it all, one thing stood out - JavaScript tutor.

"I won't just teach you JavaScript. I'll teach you how to think like programmers."

Those were the first words from him. It sounded cheesy then, but looking back, I can see how lucky I was. His constant questions - how does this work? Why do you need this? Was a daily ritual. This approach of digging deeper really resonated with me and helped me realize, that I need to focus. A "junior full-stack developer" made even less sense, than before. A "junior JavaScript developer" sounds much more reasonable.

Inspired to do more, I wanted something to work on at home. I mean, there are only so many to-do lists you can make, right? That is when I stumbled upon the HTML canvas. It was amazing to see code come to life visually, especially in a form close to my heart - games. Writing something as simple as Pong felt amazing and I was hooked. I tried making Tetris and that worked!

So, what is the natural next step after you have tried to create your own version of Pong or Tetris? For me, it was an obvious choice - make a Mario clone! This was a completely different challenge - creating tiles, making a player object interact with them, jump and everything else what looks as simple as it can. Did it pay off? Yes, it did! Spoiler - it even helped me land my first job, after many rejections, of course.

As the coding school course neared its end and the job hunt loomed, I did not want all my efforts to go to waste. So, I transformed that simple Mario project into my personal website, showcasing my journey. Maybe just to show off, or maybe so I could continue working on it in the future.

Year #1 - Small Steps, Big Changes

After the initial excitement of "I'm actually a developer now" settled down, I knew I had to keep the ball rolling. What next? I had already done Pong, Tetris, a Mario clone... Well of course it is Wolfenstein 3D. What else could it be?

Since I already had a system based on tiles for my platformer, the only thing left was to change how it was rendered - essentially, create a ray-casting engine. There were tons of tutorials and videos about this, including some from John Carmack himself. All I needed to do - translate that into JavaScript.

Surprisingly, it was not as tough as I thought. In fact, it was quite motivating. Sure, it was not perfect, but I saw it as a fun experiment. Little did I know that tinkering with 3D graphics would become a major driver in improving my skills as a developer.

Here is my ScriptenStein. It only has keyboard (arrow buttons) controls, so do not expect much.

Year #2 - Are You Really a Developer If You Don't Have an NPM Package?

Feeling comfortable in my developer shoes and having ventured beyond just front-end work, I realized it was time to optimize my game - make updates and deployment easier, expand it further.

Main focus this year, was to extract some logic into a separate package, as I have already started having some ideas about using it else were. Spoiler - a mobile app. This is how LaikaJS was born.

Isolating game logic from design elements turned out to be a game-changer. It allowed me to concentrate on each aspect more effectively. With new features in place (multi-layered backgrounds, music, so NPCs), I felt motivated to revisit and revamp the visual side. After all, why should code be the only thing that looks good?

You can see the latest version here

Year #3 - It's All Fun and Games Until It's an App

By my fourth year, I had worked on several projects and gained enough experience to dive into React Native. With the core JavaScript foundation of my game already in place, I decided to turn it into an app. How hard could that be? Oh boy, how wrong I was...

First and probably the main this was, that there is no native canvas! Technically you can get some implementations of it, but the performance is far from acceptable. So what can you do? WebGL to the rescue. But there is a catch - it has steepest learning curve that I have faced up to that moment. I had to learn the WebGL API, understand GPUs, and implement general logic. It's important to note that I wanted to learn WebGL itself, so using libraries wasn't the route I wanted to take.

After quite some time I have managed to get grips of WebGL basics and implemented all the game logic, that I have had on the web!

Was it easy? No. Was it worth it? Ohh yes! You can get it from PlayStore and give it a go yourself.

Year #4 - Psst… I Heard You Like WebGL

In my fifth year, I started my journey to understand WebGL better, as it felt like the natural step to turn my 2D world into a 3D one.

To do this, I needed to get really comfortable with WebGL and computer graphics in general, not just poke around in the dark. The thing that helped me the most, where amazing tutorials from Andrew Adamson

That is not all. Another thing that also really stuck to me from this year was, that I finally needed to and was able to read dedicated math and computer graphics books. It is not much, but felt like a great milestone to me.

Sometimes it felt like a detour from my day-to-day work, but growing up playing video games, working with 3D software in university, and being an architect with an interest in software got me hooked. Understanding computer graphics better made me appreciate of graphics engineers even more.

But anyway, even though it is a work in progress, I'm thrilled that I can replicate this progress myself. From Pong to Tetris, to 2D platformer, to a simple 3D rendering, and now a full 3D world.

Take a look here

Year #n+1

Switching careers was a tough call, but I'm so glad I took the leap. It's been an amazing journey so far and the architect inside me is really happy, as software development has much more in common with architecture, than most people expect.

I'm excited to see where the next 5 years take me. Maybe I will have to learn something else, when AI will make all developers obsolete ¯\_(ツ)_/¯

TLDR; I like to code.

Animations as React components #2 - stacking elements

Laimonas K — Mon, 02 Mar 2020 08:33:28 +0000

In my previous post, I suggested having animations as a separate component. Now I would like to share a bit more complex use case, which I encountered, when our design team wanted to "spice things up" - have a sidebar stack its elements one after another.

Setup

So the goal is clear - render each element one after another and apply animation when "adding" the elements. To make this as simple and as reusable as possible I wanted to have a separate component which handles all of the involved logic. Nothing ground breaking here. This component should handle:

Rendering the component one by one;
Apply animation to the lastest "added" elements;
Have a callback after all the elements have finished to handle some application state changes.

<Composer
  shouldRender={state}
  transition={FadeIn}
  transitionDuration={300}
  onFinishCallback={enableButton}
>
  <Element>Element 1</Element>
  <Element>Element 2</Element>
  <Element>Element 3</Element>
  <Element>Element 4</Element>
  <Element>Element 5</Element>
</Composer>

Composer

All of the requirements listed above can be easily achieved using only a few useState and useEffect hooks:

To have a stacking effect, we will need to map children and compose childrenToRender using an iterator tick;
While composing childrenToRender we will check if the child has to be animated child index === tick, or returned as it is child index < tick or not returned at all;
After updating childrenToRender we will increment tick and repeat everything again until we gone throuh all the children;
Last, but not least, after incrementing tick we check for tick === children length to see if all the elements here handled and call onFinishCallback if it is available.

const Composer = ({
  children,
  shouldRender,
  transition: Transition,
  transitionDuration,
  onFinishCallback
}) => {
  /** Track which element should be animated */
  const [tick, setTick] = React.useState(-1);
  /** Stores children with animation to be rendered */
  const [childrenToRender, setChildrenToRender] = React.useState([]);

  /** Checks the passed props and starts iterating */
  React.useEffect(() => {
    if (shouldRender) {
      setTick(tick + 1);
    } else {
      setTick(-1);
      setChildrenToRender([]);
    }
  }, [shouldRender]);

  /** Iterates over children and adds animation if required */
  React.useEffect(() => {
    const updatedChildren = children.map((child, index) => {
      return index === tick ? (
        <Transition
          key={`animated-child-${index}`}
          duration={transitionDuration}
        >
          {child}
        </Transition>
      ) : index < tick ? (
        child
      ) : null;
    });

    /** Filters null children, to make prevent unnecessary iterations */
    setChildrenToRender(updatedChildren.filter(child => !!child));
  }, [tick]);

  /** Handles calling onFinishCallback */
  React.useEffect(() => {
    if (shouldRender && tick === children.length) {
      onFinishCallback && onFinishCallback();
    }
  }, [tick]);

  /** Checks if it is required to continue iterating over children  */
  React.useEffect(() => {
    if (shouldRender && tick < children.length) {
      setTimeout(() => {
        setTick(tick + 1);
      }, transitionDuration);
    }
  }, [childrenToRender]);

  return childrenToRender;
};

Animation component

With the Composer set up, all that remains is the animation component.
Here I suggested using .attrs to set transition and transform styles based on passed state. This setup is quite good, when you need to easily handle transitions in both directions and also be able to have intermediate transitions (e.g. when reverse animation is trigered before the finishing the initial).
In this case, it was not required so I have decided to go with keyframes as this removes the need to handle state changes for each element in the Composer and is a bit more straight forward.

import styled, { keyframes } from "styled-components";

const getTransform = () => keyframes`
  from {
    transform: translateY(200px);
  }
  to {
    transform: translateY(0);
  }
`;

const getOpacity = () => keyframes`
  from {
    opacity: 0;
  }
  to {
    opacity: 1;
  }
`;

export default styled("div")`
  animation: ${getTransform()}, ${getOpacity()};
  animation-duration: ${({ duration }) => `${duration}ms`};
`;

Results

Here are a few examples of the setup in action with a few different transitions.

Animations as React components

Laimonas K — Mon, 17 Feb 2020 07:14:49 +0000

Story begins as usual - project is just starting, the design is "almost" done and the requirements are all over the place. Not wanting to deal with with major refactorings later down the road, team decides to follow atomic design pattern as much as possible.
Life is good. All changes are isolated in small chunks, but suddenly, a wild animation for an already developed component appears! styled-components to the rescue!

Animation component

As an example, let's create a simple animation for rotating an item. It is just a simple wrapper, which uses chainable .attrs to pass dynamic props and set animation properties. Note: it should only use css and values, that can be used in transitions. So no px to % transitions.
For passing props, you could also use tagged template literal, but it would create a new classname for each different variant of the transition.

import styled from "styled-components";

const Rotate = styled("div").attrs(
  ({ state, duration = "300ms", start = 0, end = 180 }) => ({
    style: {
      transition: duration,
      transform: `rotate(${state ? start : end}deg)`
    }
  })
)``;

export default Rotate;

Usage

To use it, just import the animation, wrap the component you want to animate and provide some sort of a state handler. In this case it is just a simple component to change the state, when clicking a button. In practice, it could be almost anything from a button click, to a form validation status.

<StateSwitcher>
  {({ state }) => (
    <Rotate state={state} duration="1s" end={360}>
      <Element>Rotate</Element>
    </Rotate>
  )}
</StateSwitcher>

Combining multiple animations

Rinse and repeat. The setup is almost identical.

import styled from "styled-components";

const Opacity = styled("div").attrs(
  ({ state, duration = "300ms", start = 0, end = 1 }) => ({
    style: {
      transition: duration,
      opacity: state ? end : start
    }
  })
)``;

export default Opacity;

Now use it to wrap and voila.

<StateSwitcher>
  {({ state }) => (
    <Opacity state={state}>
      <Rotate state={state}>
        <Element>Rotate + Opacity</Element>
      </Rotate>
    </Opacity>
  )}
</StateSwitcher>

Testing

Testing this setup is dead simple with @testing-library/react. Just change the state and check what the resulting style changes.

import React from "react";
import { render } from "@testing-library/react";

import Rotate from "./Rotate";

describe("Rotate", () => {
  it("renders Rotate and changes state ", async () => {
    const component = state => (
      <Rotate state={state} start={0} end={123} data-testid="rotate-transition">
        <div>COMPONENT</div>
      </Rotate>
    );

    const { rerender, getByTestId } = render(component(true));
    const RenderedComponent = getByTestId("rotate-transition");
    let style = window.getComputedStyle(RenderedComponent);

    expect(style.transform).toBe("rotate(0deg)");
    rerender(component(false));

    style = window.getComputedStyle(RenderedComponent);

    expect(style.transform).toBe("rotate(123deg)");
  });
});

Results

You could have many different variants (move, rotate, color ...) and extend these much more - handle animation finish callbacks, setTimeouts and etc.

This setup might not be the suitable in all cases, but in my case, it ticks all the right marks:

Easy to use and share;
Easy to extend;
Easy to test;