Welcome, new user. Please log in or register.

NunoMartinez Mon 17 Apr 17, 08:19

This is the end for me. I've found a weird bug that would take hours of GDB to fix (actually I've spend some yet) and I think it is something hidden in the old code that would be fixed just rewriting the engine from scratch instead of converting from the old one.

Anyway I'm proud of what I did. I did a post mortem of my TINS 2016 entry, find some bugs and the fixes, and designed a better engine from the previous experience. I'll actually work on the point'n'click engine as part of MinGRo.

But this is finished for me.

NunoMartinez Fri 14 Apr 17, 10:09

New animation subsystem done. It works since the first try. No errors (at the moment ;).

Right now it is used by the Player only, so I should refactor the items tree to complete the integration.

I'm thinking how to add scripting to the engine too. May be I have no time to add full scripting (i.e. define the whole game with scripting) but I think I'll have time to add sprite and room definition files.

NunoMartinez Thu 13 Apr 17, 17:43

I'm not being very productive. Anyway, I started with the engine refactorization. Attached a brief UML of the "new" engine. It's similar to the current one except the "items" tree (compare with the screen shot I show few days ago). The classes with prefix "Tmng" are MinGRo classes.

Finally I'll not use the full sprite engine. The sprites in MinGRo aren't too flexible right now. I think I should change this. The "TAnimations" stuff looks nice. If it works may be I'll add it to the MinGRo engine.

I still don't know how to add scripting in this engine. Anyway I'll not think about it until this mess is implemented.

NunoMartinez Wed 12 Apr 17, 18:29

More integration: Now game uses MinGRo "FindFile" method to look for data files. This method gets the file name you're looking for, then it looks for the file in a list of directories in order (working directory, application directory, etc.) until it finds it. This way it is easy to add "modding" capabilities to the game.

Also, I've found I've fixed a curious graphical glitch. Look at the attached image: top is the old one, bottom is the new one. Do you see it? The old (non MinGRo) rendering pipe added a small "tip" to the glasses! I'm sure it is because I used the "scaled" version of the Allegro drawing functions and now I use the "normal" ones but using a transformation matrix instead.

NunoMartinez Wed 12 Apr 17, 17:24

Resampling the sprites using Aseprite (old version). I've found that the walking animation is very ugly and bad done. I'll not waste time fixing it (at the moment). This is just to use MinGRo's sprite system.

NunoMartinez Wed 12 Apr 17, 11:28

Some hours working and the integration with MinGRo is complete. In the while the game was broken so I had to make a lot of changes, moving the initialization and control code from one place to another.

The main problem was that the TINS version does most of the initialization in class constructors but MinGRo expects that initialization outside them. Also the order the components are initialized is different that in the TINS version so I had to make a trick creating an "initialization stage".

Some of the advantages of using MinGRo are:
* Since it is component-based you can add and remove stuff (data, stages...) more easy, as well as manage memory better.
* MinGRo is mostly event-driven, including the error management. This makes things more easy.
* It deals with the "old-school graphics simulation" by itself so I haven't to deal with it. TINS version had to divide and multiply coordinates here and there, as well as to use "scaled" versions of the drawing routines. With MinGRo all that is managed by the engine clean. Much more easy.
* Includes several debug stuff inside that should make more easy to find problems. Actually I've found a few hidden/potential bugs (bad code actually) while converting the game!
* Much more advanced an easy to use configuration system. Includes some out-of-the-box stuff like the configuration file (not need to tell the name!) and command line options (and you can add more quite easy).

There are more stuff to do: Remove the old debug and configuration code, make the engine to use the MinGRo sprite system...

NunoMartinez Tue 11 Apr 17, 17:44

Tried to do a conversion to MinGRo in one single run and I failed. Don't know why it renders a beautiful black screen. Fortunately I'm doing backups for each goal done so I've roll-back and started again with smaller steps.

Do your backups wisely.

Tomorrow more.

NunoMartinez Tue 11 Apr 17, 11:00

Ok, that was fast.

I was using the update pattern* in both the game and the MinGRo engine so it was too easy to convert the map object in to a MinGRo component.

The attached screenshot shows the current class hierarchy. Now I'll move some of the "TGame" class functionality in to TGameMap, then specialize TGameMap in to a "Snow Cave Scape game" class with some more stuff from TGame and the engine will be fully integrated to MinGRo... Almost. I should modify the renderer to use the MinGRo's sprite subsystem, as well as to use MinGRo's mouse and keyboard.

* Update pattern: http://gameprogrammingpatterns.com/update-method.html

NunoMartinez Tue 11 Apr 17, 10:37

So, I've spend some time on the improvement, starting by adding a data container for game data (bitmaps and fonts at the moment). The engine isn't MinGRo-compliant yet but since MinGRo is component-based it wasn't hard to build the data container as a MinGRo component, use it, and keep the game in a "releasable state" as rules said. 8)

Next step is to convert the "map" object to a MinGRo component.

NunoMartinez Mon 10 Apr 17, 17:37

I've spend two days (three actually but Saturday I didn't do anything) and I've found a dead end. I can't remember the original story and I can't find a new one. So I learned to write the complete story along with the documentation even if it isn't implemented.

Anyway there are a lot of things to improve on the engine. Even if I don't add any new puzzle I can improve the engine to use it in future games. So that's what I'll start tomorrow: Integrate the engine in my MinGRo game engine (may be as an add-on or something) and use a scripting language to define the adventure.

In the meanwhile may be I have ideas about puzzles and the story...

NunoMartinez Sun 9 Apr 17, 10:24

Hello fellow,

The selected game to improve is my TINS 2016 entry: Snow cave scape. There are two ways of improvement: the engine and the game itself.

About the engine, I'm tempted to make it an add-on of the game engine I'm working for the last months: MinGRo (look at SourceForge) but I'm not sure yet. Also I was wondering to use a scripting language too but I'm not sure yet too. In any case the engine needs some refactorization to be more flexible.

Anyway the most important change is to make game bigger adding more puzzles. I did a list for the original entry but I lost it so I have to redesign the game again.

So the plan for today is do the game design. Then revise the engine and improve it. Finally apply the improvements and add the new puzzles.

Let's go.