Note
Hi! I'm Zoty and these are the docs about Unnamed Engine. I would like to ask you a bit of patience since the docs are not exactly usable, and the information here about features may represent the engine in a future state, which means that not everything listed here works as described, or at all.
Introduction
Unnamed Engine is a game engine created to power two custom games! But that doesn't mean you can't use it to make your own games too. The engine is open source and licensed under the MIT license :D
The current capabilities of the engine are centered around voxels and complex simulations, UNEN is also the environment where I will implement my college thesis about simulations (more about that later)
The focus of the engine is to provide tools for creating games based around complex simulated worlds. Note that this makes some tasks easier, such as creating ticking entities, and other harder tasks (prepare for a lot of work if you want to create a 2d game). Another thing to take in consideration is that everything is implemented taking voxels as the world format, you will have a hard time not using them. But remember that the engine will grow past these limitations someday.
Motivation
At the moment the features are aimed at a single issue: at the past I've created minecraft mods and modpacks and found the whole experience way harder than it should be! The minecraft modding community have great people that work hard to create the best pieces of art that are possible within the game's limit, and I've seen masterpieces over the years (thaumcraft, create, gregtech, botania, too name a few) but sadly, due to many problems related to the game not being made for mods since the beggining, these mods often encounter many roadblocks, and sometimes are not updated for recent versions (I'm not even going to touch the multiple modloaders drama), thus forcing the player into deciding tradeoffs that should not exist in the first place. Aside from that, the lack for tooling and standards for mods make the development harder for the devs.
Mods
Wouldn't it be awesome if you could just launch the game and download the mods from a good, trusted and official distributor? Without needing to install loads of software just to download that neat little mod that adds a small feature? You don't need to tell me, of course it would be awesome! That's one of the goals, making mods as simple as possible for the user to use, without needing to relaunch the game, without needing to install anything other than the game itself!
Modpacks
Have you ever encountered a game with mods and modpacks? If you are here, reading this, I would risk to say that you already had, and speaking from my own experience, the whole process of installing and playing a modpack never goes smooth, almost always you will encounter problems during the installation, having to download mods from different sources, having to download the modpack on a different platform, and all other sorts of issues that are not pleasant at all. And here comes another big objective of the engine, creating a smooth experience for modpacks! Since mods are going to be officially supported, so does modpacks! Expect the same experience from mods, no frustrations, no bumps during installation, a complete new modded experience just a mouse click away (maybe two or three), and all of that without even relaunching the game!
Development
Hello my dear voxel developers, no need for examples, you know the frustrations of creating mods for games, specially those that where not created taking mods in consideration. I offer you a complete development environment without any additional costs, not paid tools, not paid editors, everything that will be used for creating the official game will be available for you! Take a look at what you should expect:
Scripting vs Compiling
So, we know the big difference that scripting can make in a game, when you compile something you need to, well, compile it, but with scripting that's a totally different beast! Leave the boilerplate to the engine, you don't need to optimze anything that already exists or implement the most basic of features! Just write down your scripts and let the engine handle that for you, focus on content, not the details surrounding the code. Remember that I've talked about installing mods without reloading? Well that's because of scripting and hot-reloading! And guess what, you can also benefit from that too! The engine/game ships with all the editor tools, and these include the same capabilities, but tailored for development! Edit your mod/modpack on the fly and don't worry about the little details.
Tooling
A powerful and complete set of tools made to let you materialize your imagination! From performance profilers to special editors to handle complex tasks, expect it all. And at the end of the day, everything is stored using plain text, so if you don't like the editors or find it easier to just write code/config, go for that.
Standards
Nothing new here, everyone knows that the things that work on this world have standards defined, Unnamed Engine is no different, and that extends to mods, yes, standards take some degree of control out of your hands but that's absolutelly necessary. Standards allow the developer to expect a smoother development without too much surprises and a better default compatibility with other contents, it also lets the player use almost everything together without unknown effects.
Performance
Last but biggest topic of the list, the elephant in the room, performance... What is possible inside a voxel game, what can be simulated? What can't? What are the limits? These types of worries are common when playing almost all simulation games, that evil bastard called TPS that always limit our ambitious plans to make complex interactions. But fear no more, UE takes a very different and exotic approach to that, allowing for a imense boost in performance never seen before. (more on that later since that is the topic of my college thesis, so it is actually being researched and developed)
Modding
This is a easy task considering that the engine was made with modding in mind, so almost all features were planned and implemented considering mods in the equation. You can modify almost every aspect of the game, and game developers will find out that adding mod support for a game made in Unnamed Engine tends to be easier because of how the engine works.
Structure
Unnamed Engine tries to take the same approach as Bevy, which means the engine is provided as "modules" that you can or cannot use. At moment there is not a standard for the working of these modules, as well as any sort of implementation, but UE will implement this as a future update. The reason behind it is making it easier to don't include parts of the software irrelevant to you in the final build of your game.
Global Configuration
Problem
Imagine the following example, almost all the games that you play use the E key to access the inventory, cool, next to WASD and easy to access while you play. Then you open a game and suddenly the key is no more E, it's now TAB.
Okay, things change, maybe this is a space game and the Q and E keys are used to rotation, but now you open another game and you find now that the inventory is opened by pressing I. That slowly becomes yet another little inconvenience in the player's life. I should start by saying that I don't like it, but there's nothing evil about it, its just different design decisions.
Solution
But what if we made a solution to unify all the keys? Well, seems ambitious, and it surely is! But hear me out. If we use a global configuration scheme, and share the keybinds between games, it could be more comfortable for the player, don't you think? Let me make it clear that this is a opt-in feature that developers can just ignore while using UE, but it's there for the ones that want to test and see it.
Now if you set the inventory key to TAB, it will be saved as a global configuration, and all other games made in UE that read from the global configuration will use TAB for the inventory key, how awesome isn't it?
But theres more, this is not a strict rule, the player is also capable of choosing which keybinds will be local or global, that way the players that don't like it can opt-out of this feature.
But Why?
The problem described earlier is just a minor annoyance, but imagine you have some sort of disability and uses a very special set of hardware to control the game, now things become harder and annoying, imagine yourself in this situation where you need to rebind all the keys everytime you enter a new game. No one should be forced out of the fun more than once!
I should say that sometimes your hardware lacks some keys and rebinding them is always a pain, for instance I have a 60% keyboard and made the huge mistake of not checking if there were arrow keys before buying it, now I'm stuck with this keyboard that make some 2d games a huge pain to play.
Reality Simulation
I should start by saying that this is perhaps the most complex thing I've done in my entire life, turns out creating a solid and realistic simulation of the entire universe takes more than a few days...
UnnamedEngine takes a unique approach to how a universe works by simulating it completely! And yes, you can absolutely run it without a super computer, one could argue that you can even run the simulation on a smartphone since there are plans to port the engine to Android and IOS.
Summary
Why
There is a small niche part of the community (me included) that would die for this on a game, a entire universe, right before your eyes, completely explorable.
If you can see it, you can get there
That's the north of the design behind UE, faking but actually not faking. If you look up all the starts should be there, existing on their own, just waiting for you to explore them.
Disclaimer
As stated before, not everything inside the documentation works perfectly or is implemented, and currently this is the most W.I.P part of the book. Everything here is subject to change in the future, but hopefully we will find a solid design that doesn't need to change.
Introduction
In this part of the book we will discuss the many design decisions that went into creating a Reality inside of UnnamedEngine. Starting from a Reality, we will talk about what goes into the creation of everything in the simulation.
The explanation will have this flow: Bigger -> Lower
Reality
Well, I can't tell you what reality itself is, if it's real or not, or other types of affirmations that are outside of the scope of your development, we are game developers and will be ignoring all the details related to what is what. The terminology used inside UE takes inspiration in real life, but is adapted to fit our design and goals.
Reality is the uppermost container, everything that exist is inside of a Reality, note that things that don't exist are not contained in a reality!
But what does not exist?
A Graphical User Interface GUI does not exist. Well, you can see it, but the world does not, only the player is capable of seeing it, it also does not interact with anything besides the player's input or other GUI elements, and thus it doesn't exist! Sure, it exist on our reality, but not inside the Reality.
Structure
A Reality contains two things.
These two things are responsible for defining our game "world". Note that since UE was born to create a complex and exotic game, why not provide the tools to make these types of games easier to be reused?
Generally speaking, almost all structures related to space and time, contain just space and time-related values, but Reality is the exception. Reality Rules are Rules that define how the world works, I will not get into details here, but these exist so we have a way to create and use complex simulations without hardcoding anything.
Dimensions
A dimensions represents slices of a Reality, these slices being connected or not. Note that all dimensions share the same Reality Rules. You can imagine the dimensions as being represented by the slices of a bread, side by side, sometimes connected, sometimes disconnected.
Structure
Similar to Realities, dimensions contain two major things:
Dimension Rules
Define the fundamental rules of this dimensions, all being optional and by default ignored if not provided:
Size
Floating value that is 1.0 by default. This value represents the relative size of a dimension, the concept can be a bit abstract since a Reality does not have any type of size, so how it works?
This rule is used to scale all values inside of the formulas that are related to sizes. This way code that uses 100m to measure something, will use 50m if the size is 0.5.
There is actually a second use for this rule, by default all dimensions are equivalent in position, since they are slices of the same reality, but dimensions with different sizes will have their positions translated to equivalent positions.
Think this way: we have two dimensions, A with size 1.0 and B with size 2.0, and there is a entity existing in A at the position (10.0, 10.0, 10.0), when A goes to B (dimensional teleportation) its new positions is going to be (5.0, 5.0, 5.0), because we do (Size_A / Size_B) * position to get the relative position. This is not another rule feature per se, but rather another example use, since all the values for all formulas that relate to scale and are used inside the dimension, will use the size rule.
Time Scale
A floating value very similar to Size, defaults to 1.0 and is recommended to stay the default value unless you know exactly what you are doing. This value is reflected in the Simulation Speed of the dimension. Making things go faster will require more calculations, making things go slower will require less.
There is a plan to make this rule be more useful in the future, but don't expect magical changes, we are doing a complex research on how to best implement time travelling, and if we find a good enough solution this value will be more useful later.
Gravity
Another floating value that defaults to 1.0, it is way easier to understand and use, it will affect the scale of gravity. Higher values will increase gravity strength for the entire dimension.