When building a console from scratch, the first question that should be asked is if the games will be embedded in the console or if the games should be external.
The difference is very clear.
Embedded games:
The console has a library of shipped games usually in an internal storage or compiled and shipped with the kernel.
This aproach has several advantages:
- The language used can be the same as the kernel and also compiled with direct access to the hardware.
- Extremelly fast and efficient code.
- Simpler logic.
But it also has several disadvanteges:
- The game library can only be updated by recompiling and reflashing the project.
- Heavier kernel by default.
External games:
By having an SD Reader, we can essentialy reduce significantly the size of the main kernel/firmware.
Advantages:
- Plug & Play games.
- An unlimited amount of games to build and play.
- Not having to worry about runing out of space.
- Not having to recompile the entire project every time.
Disadvantages:
- More logic involved.
- Significantly more setup processes during boot.
- Having to write a filesystem.
To me, it was cristal clear. As a solo dev who loves building cool projects, I decided to choose external games.
But then, I was hit with another set of choices to make.
Do I use a compiled or interpreted language?
What language do I use for my games?
What language would be easier to integrate in a c++ environment?
When deciding between compiled and interpreted language, there’s different factors to take into consideration.
If I choose a compiled language, I know I’ll have to modify my ESP32 kernel to dualboot images. The kernel will be an image and every game will be another image.
If I choose an interpreted language, I just need to find an interpreter written in the same language I am using for the kernel and it will be an easy integration. Worst case scenario I might have to create my own interpreter.
Since I want all my games and engines to be open source anyway, I decided to use an interpreted language.
Now I just have to find the language to sell my soul to.
It doesn’t exist a correct or incorrect choice, but there’s certain things to consider when choosing a language for this type of project.
Possibilities I had in mind:
- Micro python
- Lua
- A custom language
Custom language:
Even though it might be a great side project, it would take too much time away from the main project. To me, this is a dealbreaker so I just discarted it almost instantly.
Micro python:
Micro python is a very simple language to program basically anything on. But that’s it, it doesn’t offer any other advantages.
Lua:
Lua has everything I am looking for.
It has an open source interpreter written in pure C, which allows for easier integration in my kernel since it’s basically just a file I have to #include.
It is very efficient and it doesn’t need many resources.
It allows to specify functions in C/C++ that can be directly called from any Lua script and it also allows to add namespaces for this functions to have a clearer code.
That’s why I am choosing Lua for this project.
Lua will provide a better abstraction level. And thanks to the custom defined functions I just mentioned, I can basically integrate any hardware component I’d like without having to worry about changing any Lua scripts. Not only that, but I can also use C/C++ to compute heavier processes instead of using Lua.
With this architecture, I have succesfully separated the project in four different sections:
- Console kernel and Hardware abstractions(C/C++)
- Low level API to work as a bridge between low and high level(C/C++)
- Game engine(Lua)
- Game(Lua)