MinGRo game engine

[Ñuño Martínez]

Initially I was reluctant to make it public, but after some time talking about it on GDR (http://gamedevelopersrefuge.org/viewtopic.php?t=1543) I decided to give it to the world. Let me copy from the GDR thread:



After finishing Green Onions - The I Ching Saga (http://www.pascalgamedevelopment.com/showthread.php?32483-Green-Onions-The-I-Ching-Saga) I realize I did a big mistake: I worked in the game engine at the same time than in the game itself. Now I have an unfinished ugly game engine that uses an old library and a game filled with patches and workarounds because the engine doesn't work as expected.

For my next game I decided not to start until I have a complete engine. Actually I was looking for one. I tested Unity, Game Maker and some less famous ones (Castle Game Engine (http://castle-engine.sourceforge.net/engine.php), Tilengine...) but I didn't find something I like. All those game engines are cool and you can do great games, of course, but I don't feel comfortable with them as they look too much modern for me. I feel the need of an old-school game engine. I think I'm getting old.

So, after some months working on it I have a not-yet-complete old-school game engine with:
A stage based game loop, much like a finite state machine. Actually inspired by Delphi/Lazarus' application libraries.
Component based stuff. You need something? Extend the component base class, add it to the game application object and you can use it when you need it.
An event manager. Quite proud of this part. Didn't plan to add it but things are quite simpler since I added it.
Configuration file and command line options parser. It is extensible (i.e. define new commando options) and parses some common ones.
A quite flexible hardware accelerated sprite engine. Despite the "hardware accelerated" part I think I can optimize it a lot.
A tile based map engine. It also uses the hardware accelerated capabilities of your computer, but I think I can optimize it too.
A simple maze generator. It generates RAW data (i.e. can't use it directly in the tile map) but I think it adds some flexibility.
Arcade user input (keyboard only ATM). Arcade means one 8 direction stick with several action buttons.
A general purpose Finite State Machine. This was one of the few things I did correctly in my previous engine, but I didn't use it in Green Onions. Blame me. I deserve it.
A general purpose message subsystem. Needs more testing and I'm not sure it works or it is useful.
Semi-complex bitmap resource manager. Actually it's quite simple but it is the key to use the hardware accelerated sprite and tiles.
IFF (https://en.wikipedia.org/wiki/Interchange_File_Format) file support. Did I say it's an old-school engine, didn't I?
An old school map editor.
One command-line simple tool to extract and build tileset bitmaps.

A lot of the inners are inspired by Ken Silverman's Build engine (http://advsys.net/ken/build.htm) and Diana Gruber's Action Arcade Adventure Set (http://www.fastgraph.com/makegames/sidescroller/).

The engine isn't yet finished: it lacks joystick input, the GUI needs more work, needs a lot of optimizations... but I'm tempted to release an alpha package. May be when I write a simple example game. Anyway you can take a look here (https://sourceforge.net/p/mingro/code/HEAD/tree/TRUNK/).

[Ñuño Martínez]

Thanks to Trello I was able to do a better planning of what's pending. Last changes added the joystick input, better keyboard and mouse input, improvements in the map editor and several bugfixes. Next image shows the map editor as it is right now:

1446

The bad thing is that I really dislike the GUI system I designed. It really sucks. Also it is confusing for the user (even myself!). Before to release the first Alpha and start with a game I'll write a new GUI from scratch, may be using Allegro 4 GUI as reference.

[Ñuño Martínez]

This week I worked mostly on the GUI and it is finished. May be not complete, but it works and includes most of the stuff I need to build game configuration menus. Right now it can be managed by keyboard and mouse. Default GUI style is minimalistic but can be changed easily just extending the TmngDialogStyle class and assigning such object to the dialog property.

This is how a small dialog looks in the map editor:
1453

[Ñuño Martínez]

I had few time to work on Mingro, but I have participated in Easter Hack 2017 (http://tins.amarillion.org/easter17/log/4134) and I had test some stuff and realized the engine still lacks some basic stuff. So I decided to fill that as soon as possible.

tl;dr: There are a list of things that should be done before I start to make actual games with the engine.

Right now I started with text translations. Since Free Pascal (and Delphi) includes a language extension that allows to use .po files to translate constant strings without needing to call functions to retrieve translations (as GCC does), I've changed all internal strings to use such extension. Next is to do the same to the tools and they'll be able to be multilanguage. Then I'll add a text manager to help write texts to the game and even translate such texts.

I should define a way to make sprite animations more easy. It would be similar to the animated tiles but different (such a complete explanation, isn't it?). I had some ideas while the Easter Hack that should work.

The console simulation needs to be completed, adding keyboard input and a simple command-interpretor. This will allow to add such in-game console (in-game debug and testing, you know) and even simple scripting that whould work as batch files. Also I should revisit everything to see if it's easy to add scripting. I'm still thinking if I'll create my own scripting for the engine or use an external one. Right now there are some support to "definition blocks" you can use to define some sprite and tile properties using plain text.

The engine needs a pahtfinding system too. Actually planned (hence the mngPath unit) but I didn't started yet.

Beside that, I should complete the configuration system, add a (or improve the existing) resource manager with file packing (Allegro uses PhysicsFS but I have no idea how it works) and improve the sound subsystem.

[Thyandyr]

In your opinion, how well suited Allegro is for making 2D implementation of text-intensive UI? Lists, property tables, buttons for sorting, VCL-type stuff?

[Ñuño Martínez]

In your opinion, how well suited Allegro is for making 2D implementation of text-intensive UI? Lists, property tables, buttons for sorting, VCL-type stuff?
I don't know if I understand your question. Allegro is able to render texts. Note that it renders bitmap-based fonts only (ttf fonts are converted into bitmaps on loading (https://www.allegro.cc/manual/5/al_load_ttf_font)).

You can take a look to the MinGRo GUI system I designed (mngGUI (https://sourceforge.net/p/mingro/code/HEAD/tree/TRUNK/src/engine/mnggui.pas), mngGuiCommonCtrls (https://sourceforge.net/p/mingro/code/HEAD/tree/TRUNK/src/engine/mngguicommonctrls.pas) and mngGuiUtils (https://sourceforge.net/p/mingro/code/HEAD/tree/TRUNK/src/engine/mngguiutils.pas); sorry for mixing English and Spanish in IMPLEMENTATION comments ::)). Didn't implemented any list or table widget yet but textbox and textlist are planned and I think I'll not have any problem.

[SilverWarior]

In your opinion, how well suited Allegro is for making 2D implementation of text-intensive UI?

As far as I know Allegro as a game development library does not have UI support already built in. So basically you need to develop your own UI library or use one of the existing ones that are compatible with Allegro.

If you want to see what is eventually possible then I suggest you check game named Factorio (https://www.factorio.com/), if you haven't played it already. Factorio is a 2D game developed on top of Allegro game library using C++ programming language. It has quite complex and detailed UI, with some advanced features like scaling, automatic scrolling when needed and more.
Now I don't know whether they are using some 3rd party UI library or they made one themselves. But since in the past I have done quite some communicating with Factorio developers I could probably get you more detailed info about the UI library they use if you are interested in such information.

[Ñuño Martínez]

Backing to topic.

I've just finished the new animation module. I took more time and effort than expected because initially I planned to add animations as part of the sprite engine as I did with the tile engine (any tile may be animated), but just when I started the implementation of the sprites part I saw it would be better to do not do so. As I've said the tile engine is different: the animation module is part of the tileset. After doing some testing with the tilemap example (https://sourceforge.net/p/mingro/code/HEAD/tree/TRUNK/src/examples/tilemap.pp#l1) I think I took the correct decision.

But after that I see the current "definition file" I implemented hasn't a good design, so I'll remove the current procedures and implement a simple scripting system. The engine will not require to use it so a different scripting engine can be used instead.

Tello said I'm at 70% of the alpha version.

[Ñuño Martínez]

Last month I didn't work as much as I would like on MinGRo. Anyway I've added a complete command-line simulation so it is now quite simple to add an in-game console, even use the command interpreter to define a batch-like scripting language. It isn't fast and lacks any memory management though.

Also, I've done some internal improvements, bug fixing and documentation updates.

Next LudumDare is near so I decided to make a first alpha release so I can use it in the contest. You can test it too.

https://sourceforge.net/projects/mingro/files/1.alpha/

[Ñuño Martínez]

So I'm back, and I decided to go straight on to finish this engine, or at least a "beta" version.

The first I've done is to rewrite the animation manager and the sprite engine subsystem. In both cases I used classes for everything so each time the number of animations or sprites changed the engine has to destroy and/or create a lot of tiny objects. So I've replaced some classes by records (as discussed here (http://www.pascalgamedevelopment.com/showthread.php?32520-CLASS-vs-OBJECT-and-memory-management)): Less memory fragmentation and less spreading.

Also I've decided to use more ideas from Diana Gruber's "Action Arcade Aventure Kit" book in the sprite engine. As a side effect the change has reduced the code complexity: I think the code (both the engine and the examples) are cleaner and more easy to read and follow. I don't know if it is faster now, but I like it.

[Thyandyr]

Looking forward to the beta

[Ñuño Martínez]

Looking forward to the beta
Me too. ;)

Right now I'm thinking in "data containers". I have an idea of a "packed file" container format similar to Ken Silverman's GRP files but using IFF I think it will work. I'm not sure if a "data container" component that keeps all things in memory is actually needed though.

[Chebmaster]

Why not pk3 aka zip ? You can open and operate them using any file manager. And the code is already there in standard Free Pascal package.
I made me a modified version that can use streams, not just open files directly. Want me to share? (LGPL)

[Ñuño Martínez]

Why not pk3 aka zip ? You can open and operate them using any file manager. And the code is already there in standard Free Pascal package.
I made me a modified version that can use streams, not just open files directly. Want me to share? (LGPL)
Thank-you. Of course, share it. I was thinking about this a lot but I'm still open to new ideas. I'm using zlib/libpng license though and AFAIK it has some issues with LGPL.

Package systems I know forces a sequential access for files. I mean, you have to go file by file until you find the one you want (For example, TTarArchive.FindNext (http://lazarus-ccr.sourceforge.net/fpcdoc/fcl/libtar/ttararchive.html)). If the package is compressed then it is mandatory. I don't want to load all data at once but allow to load the data when it is needed, so direct access is desirable.

Also, I need to bind the package with the Allegro file system (http://allegro-pas.sourceforge.net/docs/5.2/lib/Allegro5.ALLEGRO_FILE_INTERFACE.html) so I can use Allegro to load data. Of course I can load data in a memory stream then interface the memory stream with the Allegro file system then use Allegro to "actually load" data, but why do it that way if I can bind directly the package with Allegro?

Finally, I like simple things and I find modern programming unnecessarily complex. IFF is simple, flexible and easy to parse. I think an IFF-based package system would be great.

[SilverWarior]

Package systems I know forces a sequential access for files. I mean, you have to go file by file until you find the one you want (For example, TTarArchive.FindNext (http://lazarus-ccr.sourceforge.net/fpcdoc/fcl/libtar/ttararchive.html)).

So why not use some different package/archive format instead of Tar which indeed does not support random read. You do know that Tar was initially developed to be used for storing data to magnetic tapes which by themselves also did not support random access.


I don't want to load all data at once but allow to load the data when it is needed, so direct access is desirable.

There are numerous package systems that do allow you to read any of the contained file individually at any time. It isn't even so hard to make a custom one by yourself.


Also, I need to bind the package with the Allegro file system (http://allegro-pas.sourceforge.net/docs/5.2/lib/Allegro5.ALLEGRO_FILE_INTERFACE.html) so I can use Allegro to load data.

Wasn't there an extension for Allegro game library which added support for working with various packages? Or do I perhaps just remember some game developers to make one for their own game?


Finally, I like simple things and I find modern programming unnecessarily complex. IFF is simple, flexible and easy to parse. I think an IFF-based package system would be great.

Well the problem of the IFF is that it still requires sequential reading since the file is divided into multiple chunks of various sizes. And in order to determine the size of first chunk you need to read its "header". In order to read the size of the second chunk you first need to know where it starts in order to read its "header" and that means the need to read the size of the first chink first.

Now what you would want is a package which has some sort of map (like file allocation table on disk drive) from which you can quickly read where certain file data begins and how big it is.

[Chebmaster]

What is IFF ? :(
Classes are *simpler* than procedural programming because they allow for *much* easier modifications.
I've never looked at Allegro, so I cannot tell how hard coupling them would be.

Ok, here is my conversion of the unzip.pp straight from Free Pascal RTL.

Note that I did not check it for last-minute syntax errors as my engine is currently in complete disarray (not compiles). Another downside is that I haven't tried it in FPC 3 yet, may require replacement of AnsiString with RawByteString or something.
I tried removing the calls to the API of my engine but I may have missed some :(

It worked perfectly last year, compiled using FPC 2.6.4. I tested it on .pk3 files from OpenArena and my own .zip files. The average unpacking speed on my laptop was ~30 Mb/sec

http://chentrah.chebmaster.com/downloads/un_unzip.pp

So, what I did? I took the working but horribly outdated (API-wise) code and made it flexible by wrapping it into a class. The most important feature is it takes TStream as the source allowing you to support Unicode paths (if you have custom Unicode-supporting streams), work with your entire zip file loaded into memory (TMemoryStream) and even create support for nested zips with some extra effort.

I left *all* previous code commented out but not deleted, in case I encounter a rare bug resulting from improper conversion (none so far).

Its interface is not super easy to use, but! When you begin using pack files of any format you quickly realize you need a *directory* of files so that newer pack files can overwrite files from older ones and separate files in external folders should take precedence over filen in your pack files. Just like any game out there is programmed to do, from Quake 3 to fallout 4.
I cannot help with that, it's up to you to create directory you need.

What does this class do?
- Lets you iterate over the zip file's directory ti get file list
- Jump to specific file by name (It does iterate over the directory, in fact, but that is fast)
- unpack the next chunk of the currently selected file

To get file unpacked into memory (and you *have* to do that because unpacking is sequential and you applied routine would probably want to seek all over the unpacked file), I use code like this:



// this is optimized for my engine, lots of overhead due to multi-threaded asset loading
// you may want to use something more elegant than the array of byte
// f_zip is the TUnzip class instance (field of TZipFile)
function TZipFile.ReadFile(fname: TFileNameString): TArrayOfByte;
var
ufi: unz_file_info;
fn, comment: AnsiString;
i, read_how_much: integer;
err: boolean;
q: Qword;
begin
[...]
if not f_unzip.LocateFile(fname)
then begin
AddLog(RuEn(
'Загрузка прервана: файл не найден в контейнере!'#10#13' файл %0'#10#13' контейнер %1',
'Aborting the load: file not found in the container!'#10#13' file %0'#10#13' container %1'
), ['{$MODULE}' + fname, UnmangleFileName('{$MODULE}' + f_name)]);
Exit(nil);
end;

Mother^.Timer.UsecDelta(@q);
err:= not f_unzip.GetCurrentFileInfo (@ufi, fn, nil, 0, comment);
if not err then err:= not f_unzip.OpenCurrentFile();
if not err then begin
SetLength(Result, ufi.uncompressed_size);
i:= 0;
while i < Length(Result) do begin
read_how_much:= f_unzip.ReadCurrentFile(@Result[i], Length(Result) - i);
if read_how_much <=0 then begin
err:= true;
break;
end;
i+= read_how_much;
end;
end;
if err then begin
AddLog(RuEn(
'Загрузка прервана: ошибка чтения из контейнера!'#10#13' файл %0'#10#13' контейнер %1',
'Aborting the load: error reading from the container!'#10#13' file %0'#10#13' container %1'
), [fname, UnmangleFileName('{$MODULE}' + f_name)]);
SetLength(Result, 0);
end;
if Mother^.Debug.Verbose then AddLog(' ..unpacked %0 bytes in %1 μs', [Length(Result), round(Mother^.Timer.UsecDelta(@q))]);
end;


and, directory building example:

function TZipFile.Initialize: boolean; //is ONLY called by threaded tasks from their thread!
var
ufi: unz_file_info;
i: integer;
fn, comment: AnsiString;
begin
Result:= inherited Initialize;
if Result and not Assigned(f_unzip) then begin
if Assigned(f_unzip) then Exit(true);
try
if Mother^.Debug.Verbose then AddLog(' Attaching a zlib object to the stream ...');
f_unzip:= TUnzip.Create(f_stream);
repeat
if not f_unzip.GetCurrentFileInfo (@ufi, fn, nil, 0, comment) then break;
if ufi.uncompressed_size <= 0 then continue; //there are folders and shit

//now there is my engine adding that file to its own directory
SetLength(f_list, Length(f_list) + 1);
with f_list[High(f_list)] do begin
name:= '{$MODULE}' + fn;
pak_file:= Self;
Hash.FileAge:= FileDateToDateTime(ufi.dosDate);
Hash.NameMd5:= Md5String(name);
Hash.FileSize:= ufi.uncompressed_size;
if Mother^.Debug.Verbose then AddLog(' %0 , size=%1, ratio=%2%',
[name, ufi.uncompressed_size, round (100.0 * ufi.compressed_size / max(1, ufi.uncompressed_size))]);
end;
until not f_unzip.GoToNextFile();
if Mother^.Debug.Verbose then AddLog(' Parsed successfully, found %0 files.', [Length(f_list)]);
except
AddLog(RuEn(
'Не удалось инициализировать распаковщик unzip'#10#13#10#13'%0',
'Failed to initialize unzip unpacker'#10#13#10#13'%0')
,[StopDying()]);
Result:= false;
end;
end;
end;

[Ñuño Martínez]

So why not use some different package/archive format instead of Tar which indeed does not support random read. You do know that Tar was initially developed to be used for storing data to magnetic tapes which by themselves also did not support random access.

(...)

There are numerous package systems that do allow you to read any of the contained file individually at any time. It isn't even so hard to make a custom one by yourself.
I like this. :)


Wasn't there an extension for Allegro game library which added support for working with various packages? Or do I perhaps just remember some game developers to make one for their own game?
Yes, there is: The PhysicsFS add-on (http://liballeg.org/a5docs/trunk/physfs.html) but I have no idea how to use it. I suppose PhysicsFS is a library you install in your Windows/Linux system then it calls it or something.

I'm used to the "old" API (Allegro 4.x) and I'm still a bit confused with some parts of the new one (5.x), it is mostly designed as a state machine now but the file IO looks like a state machine mixed with other stuff. Not sure how to use it.


Well the problem of the IFF is that it still requires sequential reading since the file is divided into multiple chunks of various sizes. And in order to determine the size of first chunk you need to read its "header". In order to read the size of the second chunk you first need to know where it starts in order to read its "header" and that means the need to read the size of the first chink first.

Now what you would want is a package which has some sort of map (like file allocation table on disk drive) from which you can quickly read where certain file data begins and how big it is.
Yes, I know about that IFF limitation, but I have two solutions:
Include a chunk at the begginning with the map of the file telling where each file is, in a similar way Ken Silverman's GRP files does.
Scan the whole file when opening building the map in memory.


What is IFF ? :(
It is a standard container file format developed by Electronic Arts and Commodore/Amiga inspired by some old Apple MacOS API widely used by AmigaOS. It's still in use by a few formats like Apple's AIFF and Microsoft's WAV (this one using a modified version called RIFF though). PNG file format uses a similar approach too.

You can read the complete description in this paper (http://www.martinreddy.net/gfx/2d/IFF.txt).


Classes are *simpler* than procedural programming because they allow for *much* easier modifications.
I've never looked at Allegro, so I cannot tell how hard coupling them would be.

Ok, here is my conversion of the unzip.pp straight from Free Pascal RTL.

(...)

Thanks for sharing this.

Didn't know ZIP files allows random access to files. May be I'll rethink this.

[SilverWarior]

Didn't know ZIP files allows random access to files. May be I'll rethink this.

Yes they do. In fact I believe this is one of the main features why ZIP archives became so popular even thou they were other arhive types which offered better compression ratios like RAR archives for instance. That is also the reason why it was possible to extend Windows Explorer to allow working with ZIP files like they are just regular folders.

[Ñuño Martínez]

Before to work in the data containers I was working on the graphics subsystem.

The old way to initialize the graphics display was quite complex. There were a method to create it telling the size, depth and if we want a window or full screen. Then I added a method that implements a few pre-defined "legacy graphics modes".

I didn't liked it so I've finally rewrote the initialization code with a simpler one. Now there's only one method that receives a single parameter: an identifier that tells the kind of display we want (i.e. the bigger definition available, or simulate an old graphics mode as the PC-VGA or the C64-multicolor mode). Then the class decides the actual size and mode (windowed or full screen) of the display from the system information and the configuration. It is possible to drive the way the display will be created by using the configuration file. For example, we can force to create a window of a specific size.

It also defines most methods as virtual so the default behavior can be modified as needed. For example, current code creates the display using true color pixels allways. I'm planning to add to the engine a display class that initializes the code using a shader that simulates 8bpp palette modes (i.e. VGA/MCGA) so it will allow to use color animations and the actual color values of old computers. I just have to figure how to load the color palette information from image files as Allegro 5 doesn't do it.

[Ñuño Martínez]

Ok, I got it.

I've just finished the data package subsystem. There's an abstract base class that defines the interface and defines a few basic tasks. Then you can extend it to use any package you want. Right now I've included a simple custom IFF-based package system, format description has been included in documentation.

I had to add a binding between Object Pascal TStream and Allegro's file system too. I had a few problems with this (the way C and Pascal use pointers and parameters makes binding stuff a bit tricky) but now it works seamlessly and you can use Allegro's functions to load stuff (bitmaps, fonts, sounds...) from my package subsystem.

I think it's time to release a new alpha version of the engine. May be this week-end or sooner.

[Akira13]

One thing overall I might suggest both for the examples in Allegro.Pas and Mingro: make them Lazarus projects instead of a single monolithic makefile. This will ultimately be far easier for everyone, on all platforms. It's far easier to change any settings you might need to within Lazarus than it is to scroll though makefiles and try to figure out exactly where things are going wrong if you run into a build failure.

[SilverWarior]

make them Lazarus projects instead of a single monolithic makefile. This will ultimately be far easier for everyone, on all platforms. It's far easier to change any settings you might need to within Lazarus than it is to scroll though makefiles and try to figure out exactly where things are going wrong if you run into a build failure.

Wouldn't that mean that people would be forced to use Lazarus IDE while now you can compile the whole project by using Free Pascal alone. This in turn allows people to use any code editor they want.

[Akira13]

Well, I wasn't suggesting that he has to delete the makefiles from the repository. He could of course (and should) leave them there for anyone who wants to build it that way. I'm just saying it's far easier to make project-specific settings adjustments when you have actual project files to work with.

[Ñuño Martínez]

Just uploaded a new alpha release. Pretty happy with it. Look at it: https://sourceforge.net/projects/mingro/files/1.alpha.1/

I'll take a break now, until the next LudumDare. I'll still programming but will be stuff for my website because it is a big mess.


One thing overall I might suggest both for the examples in Allegro.Pas and Mingro: make them Lazarus projects instead of a single monolithic makefile. This will ultimately be far easier for everyone, on all platforms. It's far easier to change any settings you might need to within Lazarus than it is to scroll though makefiles and try to figure out exactly where things are going wrong if you run into a build failure.

May be useful, but that mean the examples directory will became a (small) mess with duplicated names. Anyway, I'll think about it and I'll do something with the next Allegro.pas release (no date though).

[Ñuño Martínez]

One thing overall I might suggest both for the examples in Allegro.Pas and Mingro: make them Lazarus projects instead of a single monolithic makefile. This will ultimately be far easier for everyone, on all platforms. It's far easier to change any settings you might need to within Lazarus than it is to scroll though makefiles and try to figure out exactly where things are going wrong if you run into a build failure.

As I've said in the Allegro's thread (http://www.pascalgamedevelopment.com/showthread.php?10899-Allegro-pas&p=148667&viewfull=1#post148667), I think I've found a way to do this in an ordered way.

[Ñuño Martínez]

Project is far to dead.

After releasing a new Allegro.pas version I'm working in MinGRo. I want to release a new alpha version this Friday, so I can use it in Ludum Dare (https://ldjam.com/) and TINS (https://tins.amarillion.org/news/).

There are many changes, most subsystems are now more robust and with better API (I think). Some of the latest changes where to fix data loading and configuration management. Previous version was confusing and a bit buggy. Also I've improved the sound subsystem.

So a lot of under-the-hood work fixing bugs and improving design, much with the GUI subsystem which was quite confusing even for me! Now it has a more coherent design, it is easier to use and the map editor have (finally!) a proper file selection dialog:
1550
It is inspired in the file selector from 3D Construction Kit. I liked it because it is simple. On Windows it is a little bit different: Instead of the "CD", "media" and "mnt" buttons it has 5 buttons for drives.

And see how much has evolved graphically:
1453

[Ñuño Martínez]

Ok, did it. And four hours before Ludum Dare (yay!). If you're curious, visit the project page (https://sourceforge.net/projects/mingro/). And if you test it, let me know what do you think. :)

[Ñuño Martínez]

I'm quite happy. Today I've finished a simple music sequencer (https://sourceforge.net/p/mingro/code/HEAD/tree/TRUNK/src/engine/mngpsgsequencer.pas) that uses the PSG to generate music, and you can use BASIC Music Meta Language (MML) to generate music. I is quite simple and I'm sure it can be improved, but at the moment you can add music in a very simple way.

But I don't like the PSG sound right now. It doesn't sound very old school. It generates triangular waveforms, and it should generate square ones, like good old micros did. I think this will be the next thing I'll do.

[Ñuño Martínez]

Well, LD didn't go very well, but it and later TINS allowed me to find some bugs in the engine. I fixed three of them and made a new release (1.a.3.1 (https://sourceforge.net/projects/mingro/files/1.alpha.3.1/)). Note this doesn't includes the new functionality added in TRUNK, they'll be published in version 1.a.4.

As a curiosity, I did a stream showing how I did fixed them in Twitch (https://www.twitch.tv/niuniomartinez/). I know my English is horrible but some friends joined me and said they enjoyed a bit (well, one said he didn't :P ).

[Ñuño Martínez]

This can be in the Green Onions: The I-Ching Saga (http://www.pascalgamedevelopment.com/showthread.php?32483-Green-Onions-The-I-Ching-Saga) thread, but it is more related with MinGRo so here I am.

These months I was working a lot on the engine, specially fixing bugs. A lot of them were discovered while making the final version of the GO game. The last release is 1.α.4 (https://sourceforge.net/projects/mingro/files/1.alpha.4/) but I'll release 1.α.4.1 soon (maybe this weekend) to apply all these bugs I've fixed. At the moment they're in the SVN repository (https://sourceforge.net/p/mingro/code/HEAD/tree/TRUNK/).

Most of the bugs are like dude, how is it possible you didn't saw that obvious mistake? Anyway most are fixed, so it is good.

I want to say also that version 1.α.5 will take a while, not only because I have to finish the GO game but also because I made a big decision, I'll not talk about it yet because I know some of you will scream "Don't do it!" but I've really meditate the pros and cons and I think it is the best move.

[Ñuño Martínez]

Still working in the Green Onions game (dude, it's taking too long :-[) and I'm confirming things about the engine. Actually I think it is pretty solid (after so much changes) but:

There's a lot of over-engineering and
Game code isn't so clean (and classic) as I intended.

Today I realized that part of the problem is that the engine is too much generic: I was thinking in any game genre and style.

So once the GO game is finished I've decided to focus the engine in a single direction: 2D action games. That should simplify things enough to remove all over-engineering and help to use more classic programing style. And for the other game genres/styles I want to do (3D action games and interactive fiction) I can create other engines using this as base/inspiration.

Then I've read this thread at Lazarus' forum (https://forum.lazarus.freepascal.org/index.php/topic,50910.0/topicseen.html) and now I'm thinking about the possibility to integrate it in to Lazarus. I should think more about it (and once the game is finished), but instead to integrate with Lazarus I think it is better to build an IDE similar to UNITY using my engine and PascalScript, then use FPC to build the final executable. I know, Game Maker does it, but it (or any other) doesn't use Pascal, does it?

What do you think?

[Ñuño Martínez]

With LudumDare about to start, and since I've finished the Green Onions game (https://www.pascalgamedevelopment.com/showthread.php?32483-Green-Onions-The-I-Ching-Saga&p=149669&viewfull=1#post149669), I've decided to fix some stuff of the engine and I've uploaded version 1.α.4.2. Not a lot of changes but should help to avoid the stupid bugs that always prevents me to finish the game in time.

You can download it from here (https://sourceforge.net/projects/mingro/files/1.alpha.4.2/).

After that, I'll see what it will evolve for version 1.α.5. I have some ideas.