GDR Forum Index
Podcast Podcast
Dev Dev Logs
Search Search
RSS RSS
Register Register
Log in Log in
Reply to topic GDR Forum Index -> Game Developer's Refuge -> Development Log - Mingro
View previous topic :: View next topic  
Author Message
Niunio Martinez
Contributor

Joined: 26 Nov 2013
Posts: 100

PostPosted: Wed Dec 14, 2016 4:18 am    Post subject: Development Log - Mingro Reply with quote

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.

Anyway, I took the ugly game engine, I identifyed the very few good ideas I implemented and I restarted it using a newer library. Few weeks later it starts to look like an actual game engine that I'm comfortable enough. It isn't finished but right now it has:
  • 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.
  • One command-line simple tool to extract and build tileset bitmaps.

The sprite and the tile subsystems are inspired in the Action Arcade Adventure Set. Actually the code is very different not only because I'm using Object Pascal but also because everything is more object-oriented and component-based.

It will not be finished until I add:
  • More resource management (sound, raw data, packed files...).
  • Sound manager. Not just resources (samples, data) but also something to help to control it: stereo positioning, volume, effects...
  • Some shaders: CRT simulation, color palette animations, fake lighting... But I have to learn GSL yet.
  • The joystick part of the arcade input subsystem.
  • Mouse input.
  • A GUI. This would include default common dialogs like save/load game, input configuration, graphics configuration...
  • IFF file support. Did I say it's an old-school engine, didn't I?
  • Pathfinding.
  • More tools as better tileset builder (not editor), a sprite builder (not editor), a map editor (I didn't found one I like, except TileStudio and it is pretty dead), a data file packager (IFF style, of course)...
  • Optimize stuff. I'm using "brute force" algorithms and I'll not optimize them until I see how it works in an actual game.

I'm also tempted to add an integrated scripting intepretor. May be one based in BASIC or QuicBASIC.

A few screen shots I published on Twitter:

The sprite engine in action showing bounding boxes used by collision detection.


A generated maze imported by the tile map.


Another one showing animated tiles and a sprite

If you like it, you can take a look to the TRUNK. :-)
_________________
Under redaction...
View user's profile Send private message Visit poster's website
sonrisu
Moderator

Joined: 31 Aug 2005
Posts: 4990
Location: Silicon Valley!
PostPosted: Wed Dec 14, 2016 8:39 am    Post subject: Reply with quote

Nice. Looks cool.

Are all the sprites shared? I noticed the torches all animate the same frames. :]
_________________
loomsoft :]
View user's profile Send private message Visit poster's website
Niunio Martinez
Contributor

Joined: 26 Nov 2013
Posts: 100

PostPosted: Fri Dec 16, 2016 4:22 am    Post subject: Reply with quote

Torches aren't sprites: They are animated tiles. That's why they share the same frames.
_________________
Under redaction...
View user's profile Send private message Visit poster's website
Niunio Martinez
Contributor

Joined: 26 Nov 2013
Posts: 100

PostPosted: Fri Dec 30, 2016 3:46 am    Post subject: Reply with quote

I've finished an AY-3-8910 simulated PSG (Programmable Sound Generator). The idea is to have a simple way to generate old-school sounds. It has some issues (noise generator is ugly, the volume envelope should be adjusted and it generates ugly TICK sounds some times) but I'm quite proud of it. Anyway I've just found this paper explaining how does the actual chip work, so may be I can improve and fix all the problems.

While programming I've found a limitation of Allegro: it allows 5 sound stream only. May be this is the default configuration and can manage more, but anyway I'm using 3 of them only (I like to be accurate) so no problem.
_________________
Under redaction...
View user's profile Send private message Visit poster's website
Sirocco
Moderator

Joined: 19 Aug 2005
Posts: 9442
Location: Not Finland
PostPosted: Sat Dec 31, 2016 10:22 am    Post subject: Reply with quote

Very, very cool!

I learned an awful lot while writing a simple FM synth many years ago. It was ugly and hackish :)

But it gets you familiar with so many concepts I can't recommend it highly enough.
_________________
NoOP / Reyn Time -- The $ is screwing everyone these days. (0xDB)
View user's profile Send private message Visit poster's website
Niunio Martinez
Contributor

Joined: 26 Nov 2013
Posts: 100

PostPosted: Wed Jan 11, 2017 9:29 am    Post subject: Reply with quote

So, I've spend some time completing the documentation and polishing some parts of the engine API.

But when I did the first test on Windows I've found two examples don't work: the sound synth and the tilemap demos. I've tested in both WinXP and Win7. I have no idea what's wrong. I'll do some valgrind debugging to see.
_________________
Under redaction...
View user's profile Send private message Visit poster's website
Niunio Martinez
Contributor

Joined: 26 Nov 2013
Posts: 100

PostPosted: Sat Jan 28, 2017 5:25 am    Post subject: Reply with quote

After working on the Windows issues, some more functionality some bugs and some more documentation, I've finished with the map editor (at the moment). It is an old school one and I like it.

There are still unfinished things to do but may be I prepare an alpha release or something.

Here you have how the map editor looks in my good old Windows XP.

_________________
Under redaction...
View user's profile Send private message Visit poster's website
Niunio Martinez
Contributor

Joined: 26 Nov 2013
Posts: 100

PostPosted: Sat Mar 18, 2017 9:43 am    Post subject: Reply with quote

This week I worked mostly on the GUI, I didn't like how it was so I redesigned it from a GUI I wrote for Allegro.pas 4 some time ago. 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 it 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:

Compared with the one in the previous message, I think now it is less confusing (to the user and to the programmer). Also note that now the map editor shows the tile tags instead of just rendering an ugly T.
_________________
Under redaction...
View user's profile Send private message Visit poster's website
Sirocco
Moderator

Joined: 19 Aug 2005
Posts: 9442
Location: Not Finland
PostPosted: Wed Mar 22, 2017 6:29 am    Post subject: Reply with quote

Somehow, I don't know if making editors for games is heaven or hell. So much work :D
_________________
NoOP / Reyn Time -- The $ is screwing everyone these days. (0xDB)
View user's profile Send private message Visit poster's website
Niunio Martinez
Contributor

Joined: 26 Nov 2013
Posts: 100

PostPosted: Fri Mar 24, 2017 3:51 am    Post subject: Reply with quote

My editor is quite simple so it wasn't too hard to code and modify, but still a bit of hell.

Anyway, Mike Wiering said he is reworking on TileStudio at GitHub so I don't need more. I'll include tsd files so people will be able to use TileStudio to build maps and tilesets for my engine. I'll still working on my editor and other tools but they will include basic edition only.
_________________
Under redaction...
View user's profile Send private message Visit poster's website
Niunio Martinez
Contributor

Joined: 26 Nov 2013
Posts: 100

PostPosted: Mon May 08, 2017 2:43 am    Post subject: Reply with quote

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.
_________________
Under redaction...
View user's profile Send private message Visit poster's website
Niunio Martinez
Contributor

Joined: 26 Nov 2013
Posts: 100

PostPosted: Tue May 30, 2017 9:43 am    Post subject: Reply with quote

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.
_________________
Under redaction...
View user's profile Send private message Visit poster's website
Niunio Martinez
Contributor

Joined: 26 Nov 2013
Posts: 100

PostPosted: Wed Jun 28, 2017 8:53 am    Post subject: 1.alpha release Reply with quote

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/
_________________
Under redaction...
View user's profile Send private message Visit poster's website
Niunio Martinez
Contributor

Joined: 26 Nov 2013
Posts: 100

PostPosted: Mon Oct 02, 2017 4:00 am    Post subject: Reply with quote

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 ("structs" in C) so now it can reserve a bunch of "objects" in a run: 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.
_________________
Under redaction...
View user's profile Send private message Visit poster's website
Reply to topic GDR Forum Index -> Game Developer's Refuge -> Development Log - Mingro

Use this link to get a Sign-On Bonus when you get started!

All trademarks and copyrights on this page are owned by their respective owners. All comments owned by their respective posters.
phpBB code © 2001, 2005 phpBB Group. Other message board code © Kevin Reems.