Page 1 of 4 123 ... LastLast
Results 1 to 10 of 32

Thread: MinGRo game engine

  1. #1

    MinGRo game engine

    Initially I was reluctant to make it public, but after some time talking about it on GDR I decided to give it to the world. Let me copy from the GDR thread:

    After finishing 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, 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 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 and Diana Gruber's Action Arcade Adventure Set.

    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.
    No signature provided yet.

  2. #2
    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:

    C5sWUDuWcAIJaR-.jpg

    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.
    No signature provided yet.

  3. #3
    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:
    170318_1824.png
    No signature provided yet.

  4. #4
    I had few time to work on Mingro, but I have participated in Easter Hack 2017 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.
    Last edited by Ñuño Martínez; 08-05-2017 at 11:20 AM.
    No signature provided yet.

  5. #5
    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?

  6. #6
    Quote Originally Posted by Thyandyr View Post
    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).

    You can take a look to the MinGRo GUI system I designed (mngGUI, mngGuiCommonCtrls and mngGuiUtils; 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.
    No signature provided yet.

  7. #7
    Quote Originally Posted by Thyandyr View Post
    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.

  8. #8
    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 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.
    Last edited by Ñuño Martínez; 30-05-2017 at 05:45 PM.
    No signature provided yet.

  9. #9

    Post 1.alpha release

    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/
    No signature provided yet.

  10. #10
    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): 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.
    No signature provided yet.

Page 1 of 4 123 ... LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •