Welcome, new user. Please log in or register.

Eric Fri 14 Apr 17, 16:32

I'm falling behind schedule. Much of yesterday and the day before was spent working on the library rather than the base game.

I am officially calling it quits on allegro5.js. There are some things that make sense in C on the desktop that do not make sense (or could be implemented better) in JavaScript on the Web. I wanted to very closely recreate the API and functionality into JavaScript, but it's looking like it just won't be possible. So instead I've started my own bare-bones library called "Momo" (Japanese for "peach"... I like peaches).

Momo is on GitHub: https://github.com/ecj2/momo

Momo so far can draw primitives (arcs, circles, rectangles, triangles, lines, and filled versions of each), draw images (normal, rotated, scaled, partial), draw text (normal or outlined), and can detect key presses. I've tested it in the stable versions of Chrome, Opera, and Firefox so far, where it works without issue. If I add audio support to the library, and if I have enough time before Sunday, I will convert Keebo's Quest to use Momo.

Fun fact: Firefox renders text differently than all the other browsers. Especially in regards to textBaseline, its "top" value is fundamentally different. It took me a few hours, but I made a commit that circumvents the issue (surprisingly the "fix" is just a few lines): https://github.com/ecj2/momo/commit/8f2580280559d863b6d61f32bc4d8b5c88dcedda

Anyway, back to Keebo's Quest...

- Decreased bomb detonation time (so it detonates twice as quickly now).
- Fixed a bug where chat dialogues would be drawn behind objects.
- Made it such that Keebo can not move during a conversation (previously Keebo could move and start multiple conversations, which lead to some issues).

Need to do:
- Add multiple things for Gourdonians to say.
- Be able to give items to Gourdonians.
- Add cool-off timer on bombs.
- Add and be able to use special item
- Keep track of goal on HUD
- Spawn enemies


There will be bees (I'm calling them "Bumbles") in the game. Oh, and I just realized I'm missing "you" from the text dialogue (see the screenshot). Whoops!

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.

Eric Thu 13 Apr 17, 17:47

Gourdonians now spawn with a name, a desired item, and a desired quantity of said item. There are eight names total (four male and four female), but I might add more names later.

Yesterday I began learning about how classes are handled in ECMAScript 2015. My game uses the the old-style function-based "classes". I don't think I'll change the classes for this hack unless I have time at the end. Can you believe that JavaScript has inheritance, but no visibility of classes (everything is public!)?

My text manager is not working as I had hoped. I might just scrap it for monolithic blocks of hard-coded text instead. That's what I did for Mori, and while I don't like it, it'll work.

Keebo can now chat with Gourdonians. Currently, this feature is limited to only being able to hear their name and desired item. There is currently a bug where the text dialogue appears underneath other objects, which I'll need to fix. I also need to make the dialogues able to be closed, as well as not allow Keebo to move during a conversation.

I made a handful of cosmetic changes: the HUD text now sports subtle drop shadows (I still need to finalize its design); there is a dialogue box that appears when talking with Gourdonians (it's "animated" like the rest of the graphics); and the intro text and background colors have changed.

Lastly, I have some concerns regarding performance. My game runs quite well in my browser, but I wonder how it will do in other browsers on other machines. I'll have to do some testing before finalizing it all.

Oh, one more thing: I have stopped developing allegro5.js (https://github.com/ecj2/allegro5js) for the time being. It is now a standalone library, which is good, but I am having issues implementing an event queue like Allegro 5 has in C. So I might call it quits on the library and start my own custom JS library instead (so I won't be a slave to the functions and expectations of Allegro).

Just a few days left now! I hope to finish sometime on Saturday, the 15th.

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.

elias Thu 13 Apr 17, 04:37

Reimplemented line-of-sight calculations. Basically I'm drawing black triangles over everything blocked from view.

SiegeLord Thu 13 Apr 17, 04:04

Wow, that took too long. Finally managed to port the game to the newer ECS.

26 files changed, 2116 insertions(+), 2467 deletions(-)

Many things became simpler, but some were somewhat annoying to port. Some things were not ported, such as the the easter egg system.

Now I'll do a little bit of cleanup and then onto adding more fun!

RmBeer Thu 13 Apr 17, 02:04

Yo ando un poco oxidado, hace muchisimos años que no hacia este tipo de hacks. Ya elegi el juego que quiero mejorar sin echarlo a perder (No tengo uno open source de allegro y no encontre otro entre los proyectos a mano), tengo planeado hacerle varias cosas. Pero esto es lo que hice hasta el momento:

El juego elegido es Fairy Godmom. Un juego de DOS creado en 1991.

- Primero. Eliminé el descompresor LZ manejando manualmente la memoria. Esta vez lo hice con ayuda del depurador DosBox. Y creo un nuevo ejecutable limpio del descompresor.
- Creo un visor de archivos utilizando Allegro para visualizar el contenido como grafico, utilizando el ancho, la profundidad de bits y la posicion inicial. Agrego el control de navegacion. (Use esto para todo lo demas)
- Creo un editor simple de Sprite.
- Creo un importador/exportador de mapas.
- Hasta ahora modifiqué los sprites de los cangrejos en alta resolución.
- Creé 14 mapas nuevos que son todo un desafio exponencialmente dificil.

Se me acaba el tiempo, creo que es hora de darle un Easter Egg antes de que sea demasiado tarde...

I'm a little rusty, many years ago not to this type of hacks. I already chose the game that I want to improve without lost (I do not have an open source game from allegro and I did not find another one among the projects at hand), I have plans to do several things. But this is what I did so far:

The chosen game is Fairy Godmom. A DOS game created in 1991.

- First. I removed the LZ decompressor by manually manipulating the memory. This time I did it with the help of the DosBox debugger. And I create a new clean decompressed executable.
- I create a file viewer using Allegro to display the content as a graphic, using the width, bit depth and initial position. I add navigation control. (I use it for make all the rest)
- I create a simple Sprite editor.
- I create an importer/exporter of maps.
- So far I have modified the sprites of the crabs in high resolution.
- I created 14 new maps that are an exponentially difficult challenge.

I'm running out of time, I think it's time to give it an Easter Egg before it's too late...

In the image see First and last in the same level of game.

amarillion Thu 13 Apr 17, 00:01

Apart from storywriting, I hadn't actually done much coding. Today was the first day of serious code writing for this competition. It was about time.

The original B.U.N. (speedhack 2015 version) already had a domain language for the dialog trees, and the game included a hand written interpreter. It can handle short scripts such as the following:

The rain gets stronger.

IF cap
Your bunny is dry under his cap. You go on.

In addition to IF/ELSIF/ELSE, the interpreter also had commands to manipulate flags, such as:

SET variable
UNSET variable
TOGGLE variable

The new story is more complex, and also has a need for variables that can take more than two values, i.e. integers. I updated the parser to handle commands like:

LET variable = 1
IF variable > 2
ELSIF variable <= 3

Besides updating the parser, I also took the time to refactor it a bit. My 33% rule remains in effect though: my belief is that if you spend more than 33% of your time refactoring, then you're not getting things done.

And I added unit tests! Not something I had time for in the original speedhack. I always write lots of unit tests when I do Java code, but for some reason I don't really have the habit when writing C++ code. It's just a bit more messy, and you have to add some ugly bits to your makefile. Nevertheless, I'm happy I invested the time. Parsers are excellent candidates for unit testing. And I immediately managed to iron out a few kinks in the parser, something that would have cost me much more time by playtesting.

Is it cheating to post a screenshot of code?

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.

Eric Wed 12 Apr 17, 14:23

Happy Wednesday, everyone. There's an Italian restaurant in town that sells calzones at half price on Wednesdays. I might go there for lunch.

Anyway, progress has slowed down considerably. I spent much of yesterday making commits and bug fixes to allegro5.js instead of working on my game.

Here are the things I did manage to accomplish:

1. I changed the bomb to also destroy dropped items. They newly blown-up tiles were even accompanied by a "blow up" spot. However, I didn't like the accidental destruction of tiles, nor did I like the way the "blow up" spot looked, so I scrapped them both.

2. I fixed a bug where the way Keebo would spawn would result in getting out of bounds.

3. I increased the blast area of the bomb. See the screenshot for details.

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...