|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.
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...
Need to do:
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.
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|
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.
Se me acaba el tiempo, creo que es hora de darle un Easter Egg antes de que sea demasiado tarde...
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'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:
In addition to IF/ELSIF/ELSE, the interpreter also had commands to manipulate flags, such as:
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
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:
There are more stuff to do: Remove the old debug and configuration code, make the engine to use the MinGRo sprite system...