After creating the system yesterday, I took the liberty to improve and modify it a bit. I managed to improve the speed, while increasing precision. Alongside that, I've included a debug object that displays all kind of useful information. The engine is running 60 fps all the time, except when moving the nodes of the NavMesh. That is because at this time, the pathfinding grid is being calculated (and displayed) whenever the mesh is changed, which is quite resource costly in GM. In the game this won't happen as the grid will be pre-calculated.
Here is the first video preview of the engine, displaying the NavMesh and the pathfinding.
Turn on the captions!
After a few days of work, I've managed to get the movement system working good. What the system does is that it takes the NavMesh, and checks the mesh against a grid. The grid cell's outside the mesh are solid, while the ones inside are not, and you can move freely inside the mesh. After that the program uses a basic A* pathfinding engine to produce the near-shortest path towards the destination. Precision of the grid, that is the edges can be changed easily, but I am keeping the cell size 16px for now, as it is somewhere between performance and quality (precision). Smaller cell size results in a more precise checking, but takes 16x more CPU power.
Here is a preview, with the grid and cells (red cells are solid, green are the walk area or the NavMesh). The white rectangle is the "player" object, and the line is the path it will take to reach the destination.
I will see to improve both the precision and the quality, while improving performance. A better A* pathfinding engine is also planned.
As the program is quite complex, and has quite a number of features, I've made a "Mind Map" to keep things organized, as well so that I can add or remove, or write something down for that, so that I have a plan what to work on.
In this post I will only explain the basics on how the program should work, and give you the preview of the mind map.
The program is divided into four sections, three of which are pre-programmed and created, while the fourth one needs to be created by the user. These are:
1. Engine The core part of the tool, as this is what enables the game to function and work. The engine features NavMeshes, Dialogues, AI and engine functions, that are actually program settings.
2. User Interface This sections covers the interface and the user-computer communications. Featuring a HUD with the actions and the inventory, save/load functions and interaction on the scene.
3. Tool This is planned for a future version, since without this you cannot create anything in this engine without the source. This is also the most complex thing, as it will feature a composite nodes system, which was covered in a previous topic, integrated GML scripting and GLSL ES for shaders, an audio sync tool, which is used to fix dialogue voice timings, but can be also used to modify the sound, objects, and the necessary functions like saving and loading your project, and exporting it as a standalone. The tool also features a four editors, a scene editor, in which you setup the objects and the visual part of the scene, then a cutscene editor, where you can create scripted events, making the cutscenes rendered in real-time. The particle editor and the shader editor are the part of the composite nodes system, but they are major functions. The DLL's the engine uses are just my notes. Since FMOD is so damn expensive for commercial products, I will probably use a free version of a similar sound engine. Cypher will provide the file archiving and protection, so that others cannot steal the resources if you want.
4. The Game
This section is what is needed to be created by the user. It is the game content.
The bottom section shows the menu options for the game, that should be available.
It's been a while since I started making this, and it hasn't been easy. I've wrote that the engine would have "composite nodes", or that is a system of windows, each representing a function, that can be connected in order to modify something. Combining them you can get various results, without the need for a single line of code.
I started work on this a few weeks ago with the intention just to lay in a basis for it, since this is not the main feature of the program. And that's what I did. The system works to a point right now, and adding new nodes isn't hard, but programming their functions is. But the hardest thing with this is connecting them and getting the right results. The way the user connects the nodes is simple. You just drag the mouse from one output into an input in a different node. But programming this is very, very hard. Since I cannot see the results now, and try out if the system works, as I still haven't figured out how to connect these, I cannot give you an example of how this thing works, only how it looks.
In this image there are four nodes, two of which are the same, but one is minimized. I will explain what this system should do:
The first node (left most) is the Image File node. It is used to load an image into working memory and manipulate it. It is one of the key nodes, since the file can then be used in many purposes.
The second, and the minimized nodes are the same, and they represent the Colorize node. This node receives the image in the input, and returns the image with a changed hue in the output. The user can also select the intensity the hue is changed.
The third node is the Viewer node. This is the most versatile node as it will display whatever the input receives. That means anything from images, text, 3D, and others, except for sound, for which an another node is used.
The line drawn from the Image File node to the mouse is my script draw_spline_cubic, which can be downloaded from this page on my blog. It is used to connect two nodes together. One node can have multiple inputs/outputs depending on its function, and every input/output can have multiple other nodes connected into it. So for example, you can have one Image File node, two Colorize nodes, and two viewers. Connecting the image to both Colorize nodes, then each Colorize node to it's Viewer, will give you the same image in two colours. You can also connect two same nodes to get a different effect, or two Image File nodes to blend the two images together (however this will require a mixer tool to determine the amounts).
This system won't be worked upon now, but if anyone wishes to work on it, you can send me a PM either on GMC, or on the PM page here, describing your intentions, since I won't be sending this to just anyone! However you will be obligated to send me back your version of this system if you add/modify something. Credit will not be needed, since we will both profit, you in receiving this, and me for getting your modified file. If I add something also, you will receive the new file. Should someone manage to work out the connecting system, he/she will be credited for it, and will receive beta copies and the finished version of the engine, free of charge.