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.
Finally this system is completed! And its crucial for a lot of things. Why? Well, I can modify it so that a static background can have objects that are actually just a mesh area. And then this mesh area can have its properties, colour, actions... Everything but the visual part, that can only be achieved with objects.
After the object mesh and the player movement, I will start work on a networking system for events and actions. It will support GML code, but it will mainly focus on the programs functions. However, this wont be probably finished soon, so after a base has been laid, I will put it aside until I can finish the rest of the engine.
Thanks to TheSnidr and slayer 64 for assistance with the code.
The NavMesh is almost ready. Here is a quick explanation on how it works:
You start the mesh by clicking anywhere on the screen to create a node (red circle). Nodes can be deleted and moved (green one) so the mesh can be further edited after placement. I am currently trying to add the function to insert a node between two old ones...
I am currently thinking what kind of a NavMesh creation I would put in the tool/engine I am making. What is a NavMesh? Well, it is a area that the program uses to set the boundaries in which the player can move freely. So that doesn't mean that you can only move on a single 2D path, you can move in "3D". Something like this:
So now you can move not just left right, but up and down. This kind of movement system is used in all point and click games (save the few exceptions). So the NavMesh is the red line. And it's the whole mesh, or the area in which the player can move.
But now comes the problem how should the mesh be created. And I have two answers. The first way of doing it, is using nodes at every corner that can be moved around, and new ones created. So you would end up with a single NM. The second possibility is to use rectangles, that can be manipulated to create blocks or parts of the mesh. Then they would be connected using a connector tool.
Both of these have their good sides and bad sides, but what kind do you prefer, and which one would be simpler to use?
After 2 years and 9 days (lol) it was updated from 1.3.1 to 1.3.2, bringing some new stuff like Davve's textbox and GML colouring, and some minor bugfixes and changes.
You can download it here: Download
See the original topic: Original topic
Today I managed to put up the actions bar, that is the HUD, and as well I created a basic dialogue. The dialogue and the HUD allows for customization, so every game can look different in every aspect. This is one of the main goals of this engine - diversity. Make every game look different, or same if one chooses so. I am putting as much possibilities as the program allows me.
The pause menu is working now, not all of the buttons, but the ones that can work now, work. The entire engine is faster (0.000001%) as I improved some code. The engine runs good with everything connected, and here is the screenshot to prove so:
The "Hello GMC" is how the dialogue can look. The dialogue has several options:
Stroke or shadow, as well as both at the same time, and independent colors for both.
Font and size
Timing (time it stays on the screen)
The pause menu is the big thing in the center of the screen. It looks like ScummVM's pause, but I said it is only temporary. It is as well changable, and it can even be a roundrect. The info shown on it will be the program's logo (or game logo) the engine's current version and time/date.
The white cross on the "Save" button is the current cursor.
Below all of that, on the bottom is the old-familiar action menu. It is currently set to 9 actions, but more can be easily added. It is all automatically drawn, so it is quite easy to modify any aspect of it.
I started working on this engine as I don't see many point and click games made in GM due to the complicated nature of the games. And because I love P&C games, and with this engine I can make a ton of them. The engine should be able to create LucasArt's like SCUMM games, as that is my inspiration.
The first day went good, I've managed to finish the most important things of the base for the engine - controls, engine interface and engine settings, as well as making the Pause menu, but only its visual part. Although it looks like the ScummVM emulator, I will change it before the first release, currently I am only mimicking it.
I've also implemented the set of scripts I almost always put in every project of mine. You can see and download these scripts here soon.