Blog

• Building an Adventure Game engine

  When I was a child, most of the time I spent on the computer was for playing games. I can't remember how many DOS games I played but my favourite ones were those you had to point and click, talk to other characters, save as many items as you can and resolve puzzles to progress in the story. Later I learned this kind of games were called adventure games.

  My top five is easy to list: Monkey Island, Monkey Island 2, Loom, Day of the Tentacle and Sam & Max Hit the Road. I used to complete them multiple times.

  Sierra games were a little bit difficult for me at the time due to dead ends, deaths and text parsers. These were the perfect ingredients to a really frustrating experience. Those games had to wait until I got older and was able to complete the whole Larry saga and felt in love with Gabriel Knight. That was also the time I played other LucasArts games like The Dig, Indiana Jones and the Fate of Atlantis, Full Throttle or Grim Fandango, which looked too challenging when I was just a kid.

  Of course, there's life beyond LucasArts and Sierra: Simon the Sorcerer, Broken Sword, Hollywood Monsters, The Lost Files of Sherlock Holmes...

  I still have plenty of adventure games pending to be either played for the first time or completed: Sierra's Quest games, Toonstruck, The Last Express, Discworld...

  The thing is: since I was a child and played LucasArts games I always wished to make an adventure game myself. Unfortunately, I had no clue about how to do it.

  Time has passed and, against any odds, I still have the same feeling: I wish to make an adventure game. I still think I can do it. I've (officialy) been a software developer for 10 years now and I'm convinced that, even though a lot of things will be new for me, I will be able to read, test and figure out any solution to continue. Right...?

  However, there's a different concern now: how much time will I spend on this project?

  When you're kid, it looks like you have all the time in the world. Once you're an adult, it's like your perception of time changes, in addition to a whole pile of new responsibilities. Everybody's running and there's no time enough for doing everything you want or need to do.

  It wasn't until recently, when I read a blog entry from Ron Gilbert: Death by Scrolling, where he talks about the process of developing and releasing his next game. I also remember his toots about RPGTBD, where he showed the progress of the game as it was being developed. Knowing about the process behind Death by Scrolling made me wonder: could I just try to make an adventure game just for the fun of it? Maybe I can start prototyping and see what happens? I keep telling to myself: Don't pay attention to the time it will take but enjoy the process of learning and advancing step by step.

  Creating a game from scratch, or even worse, a game from scratch AND a game engine, is not a walk in the park. I know. I'm aware of it. But I feel like I want to try. To be honest, it's not the first time I want to try. 10 years ago I created a project in GitHub called diogenes. It was supposed to be my adventure game engine. I say "supposed" because I was not able to do much. My little experience as a software developer got me cold feet as soon as I had to face some decissions that looked so important at the moment: Should I use factory functions or classes? Should I use JavaScript prototypes to save memory when creating component instances? Should I maintain a master and develop branch? How will I manage the semantic versioning? Should I include the build in the Git project?

  I felt stuck. It looked like any decission I'd take would be bad and would explode in my face during the following months. And the project looked so big that I couldn't anticipate all the possible bad scenarios. So I abandoned the project.

  10 years later, with some perspective, I understand why I felt so overwhelmed. I focused on some subjects that I wouldn't pay so much attention to nowadays.

  I still think it would be so cool to start by a game engine and I would feel really satisfied if I'm able to create a really short game with it eventually.

  I might be wrong but, for this new attempt, these are the things I plan to do different:

  • There's no deadline
  • A lot of prototyping
  • Go at my own pace
  • Document advances in this blog from time to time
  • Enjoy the ride

  JavaScript is still the way to go. I restored the old GitHub project instead of creating a new one, as an homage to my 10 years ago self. Let's hope myself from 10 years in the future doesn't have to do this again.

  Published on 2025/05/18 under #diogenes #adventure games

• Migrating to Eleventy

  Sometimes I feel that, as a front-end developer, I spend so much time working in my day-to-day work with some specific toolchain, that rarely have time to try different technologies, libraries or patterns.

  It's very easy to forget about plain HTML, CSS and JavaScript once you get used to all the boilerplate that tools like React, JSX or CSS-in-JS solutions bring to the project. Sometimes it feels heavy and overwhelming.

  Because I wanted to try something out of my comfort zone, two years ago I decided to implement this personal website. The only requirements I had in mind were that it had to be easy to develop and easy to scale, relying mostly on plain HTML and CSS, including JavaScript only when necessary. I thought about implementing everything by myself, but I found writing the projects and blog content directly in HTML a little bit tedious. At that time, I read a lot about SSG solutions and how (mostly) everything was done at build time, serving pure HTML.

  Between all the available options I checked, I chose Nuxt.js. I had experience with Vue and I was used to structure a project in components. I was interested on how it could work as a SSG solution.

  To be honest, since I had implemented projects with Vue before, it was rather simple to implement this website. The Nuxt.js documentation is really good so I was able to prepare a working prototype really quickly and deploying a final version to production some days later.

  However, I recently felt again like I wanted to try something new and I think this website is the perfect playground to do that. I've heard a lot about Eleventy and how easy is to start a project. And it is true! No mandatory file structure, no module dependencies... Just an index.md file and running eleventy was more than enough.

  In a couple of hours, I was able to have the main front page and the rest of sections with same CSS and navigation than the website I had deployed in production. Also thanks to Nuxt.js components having scoped CSS styles I was able to identify the required CSS for every page and move it to each Eleventy template.

  After two more days, spending four or five hours each on quick testing and reading documentation, I've been able to have the whole website migrated to Eleventy.

  From my point of view, I noted different things:

  Pros

  • Really easy to start. Just prepare a HTML or Markdown file, use the eleventy command and you're ready to go.
  • Not forced to use a specific or a single template engine. I'm currently using Nunjucks, Liquid, Markdown and WebC. All of them together!
  • Not forced to use a specific folder structure.
  • Almost no npm dependencies to start.

  Cons

  • Sometimes I find the documentation difficult to follow and I miss more examples.
  • Some minor issues that might be related to ignorance from my side. For example, when I moved the blog posts from single blog/post.md files to blog/post/index.md, I had to update the .eleventy.js file to watch blog/ folder if I wanted Hot Reloading to work. Posts are still under the blog/ folder even though I created subfolders so I don't understand why it's not working automatically. Most probably I'm doing something wrong but I couldn't find anything in the docs.

  I think I'll spend the following weeks tweaking and improving some small details that are still missing.

  I wonder if it would be easy to include something like babel during the build time in case I want to transpile the small amount of JavaScript I added. There is also a double call to connectedCallback of a WebComponent I implemented that I still don't fully understand. But, in general, the experience has been very rewarding.

  Published on 2023/01/04 under #meta

• The target of Webpack

  First of all, I wanted to say I consider webpack an amazing tool to generate the bundles for your projects. However, I get frustrated every single time I try to configure it from scratch. Usually I'm prototyping and I want to configure everything as quick as I can so I can start working on the actual code. Which is something that almost never happen.

  Yesterday, for example, I decided to start working again in a very old project I have never been able to complete. To be honest, the furthest I ever get is to configure the build process and write two or three functions. After that point, I realize about the complexity of the project, I start feeling overwhelmed and then I quit.

  This comeback to the project has happened twice and, there is always a big gap of time between each attempt. This usually leads to the scenario where, the only part I felt more satisfied of, this is the build process, was outdated. Welcome to JavaScript land.

  This time wasn't different, my last build flow (from 4 years ago) was including browserify and uglify. Don't get me wrong, I really loved browserify at the time (and I still do!) due to the simplicity to generate the builds. However, I think that if I get to the point where this project of mine grows as much as I would like to, I will need more configuration for the build process and I think I will appreciate more file structures like the webpack configuration files. So the sooner I integrate webpack the better. I don't want to think about migrating everything to webpack in the future.

  So I started, as many other times, to search for documentation about how to integrate webpack and all the babel related packages... They are so many that I always forget. Every single time.

  Fortunately, Tania Rascia wrote a very good article in her blog about how to configure webpack so I started to follow her instructions. I recommend it to you if you need a clear guide to start from scratch.

  After all the packages installation I prepared a webpack.config.js file that looks more or less like this one:

  const path = require('path')
  
  module.exports = {
    entry: {
      ['bundle']: path.resolve(__dirname, './index.js'),
    },
    output: {
      path: path.resolve(__dirname, './dist'),
      filename: '[name].js',
      libraryTarget: 'umd'
    },
    module: {
      rules: [
        {
          test: /\.js$/,
          exclude: /node_modules/,
          use: ['babel-loader']
        }
      ]
    }
  };
  

  Looks nice, huh? Not so many lines... At this point I don't even remember why I was complaining about the complexity of webpack before.

  Now, let's say my project only has a empty function so far, just like this:

  function a() {}
  
  export default a;

  import a from './a';
  
  export default { a };

  Then I configure the npm script to generate the build:

  "scripts": {
    "build": "webpack"
  }

  Yeah! Now I run npm run build and that's it! Let's take a look to the generated bundle:

  !function(e,o){if("object"==typeof exports&&"object"==typeof module)module.exports=o();else if("function"==typeof define&&define.amd)define([],o);else{var t=o();for(var r in t)("object"==typeof exports?exports:e)[r]=t[r]}}(self,(function(){return(()=>{"use strict";var e={d:(o,t)=>{for(var r in t)e.o(t,r)&&!e.o(o,r)&&Object.defineProperty(o,r,{enumerable:!0,get:t[r]})},o:(e,o)=>Object.prototype.hasOwnProperty.call(e,o),r:e=>{"undefined"!=typeof Symbol&&Symbol.toStringTag&&Object.defineProperty(e,Symbol.toStringTag,{value:"Module"}),Object.defineProperty(e,"__esModule",{value:!0})}},o={};e.r(o),e.d(o,{default:()=>t});const t={a:function(){}};return o})()}));

  Beautiful, isn't it? But... wait! What is that? const and () =>?

  

  Didn't I configure well the .babelrc file? Let's take a look:

  {
    "presets": ["@babel/preset-env"]
  }

  It's ok, right? Then why is babel including const and arrow functions to handle the modules? Because, it is babel, right?

  After A LOT of search, I found this StackOverflow question.

  It looks like it wasn't babel at all. Webpack has something called target that let you specify which environment you would like to compile for. It also looks that, if you don't specify any target, it will include any ES6 feature.

  Anyway, let's configure webpack to target ES5.

  const path = require('path')
  
  module.exports = {
    target: 'es5', // DON'T EVER FORGET THIS
    entry: {
      ['bundle']: path.resolve(__dirname, './index.js'),
    },
    output: {
      path: path.resolve(__dirname, './dist'),
      filename: '[name].js',
      libraryTarget: 'umd'
    },
    module: {
      rules: [
        {
          test: /\.js$/,
          exclude: /node_modules/,
          use: ['babel-loader']
        }
      ]
    }
  };

  Now the build looks like I expected from the very beginning, without any trace of const or arrow functions:

  !function(e,t){if("object"==typeof exports&&"object"==typeof module)module.exports=t();else if("function"==typeof define&&define.amd)define([],t);else{var o=t();for(var n in o)("object"==typeof exports?exports:e)[n]=o[n]}}(self,(function(){return function(){"use strict";var e={d:function(t,o){for(var n in o)e.o(o,n)&&!e.o(t,n)&&Object.defineProperty(t,n,{enumerable:!0,get:o[n]})},o:function(e,t){return Object.prototype.hasOwnProperty.call(e,t)},r:function(e){"undefined"!=typeof Symbol&&Symbol.toStringTag&&Object.defineProperty(e,Symbol.toStringTag,{value:"Module"}),Object.defineProperty(e,"__esModule",{value:!0})}},t={};e.r(t),e.d(t,{default:function(){return o}});var o={a:function(){}};return t}()}));

  I understand webpack has to provide as many configuration options as it can, which is part of its flexibility. However, I wasn't understanding why I would want to configure webpack to use a babel configuration in order to have ES5 syntax and webpack wouldn't 't use that configuration to assemble all the different parts in a homogeneous way.

  As I said, since babel-loader is an optional module for webpack, I think it makes sense to have a separate configuration to specify the target of the build from wepback. But this kind of things don't make it easier when you start from scratch.

  Published on 2021/06/19 under #development

• Hello World

  This is a test for the blog!

  Published on 2021/01/17 under #meta