That would be multiline-friendly
DESCRIPTION-INTERACT, MONOLOGUE-INTERACT, and
RANDOM-MONOLOGUE-INTERACT, which are all very
amicable to mapping generic entities. =w=
This allows embedding the map data directly
into the game system, instead of relying on
external files!
This’ll make distribution easier, for sure. =w=
That is, directly moving an entity from the map
into the player’s pocket. Real simple
implementation, it’s just another
interact-function for use with your entities.
I spent a good chunk of time trying to get rid of
the maps’ global variables, instead packing each
map into a :map variable in a “game” hash-table…
but, wow, that took a while. And also made things
a bit more complicated. And also… we could just
do this. From this commit. So much easier! @-@
That is, a new “Trigger” Tiled object-type has
been made, which is just a rectangle with an
associated function. If the rectangle is stepped
upon (uwu step on me owo), the function is
triggered. Y’know, standard RPG stuffs.
It’s not using gettext or anything, just a simple
system I cooked up for having the translations
hard-coded in, side-by-side.
… it’s easier for me this way when writing, and
it’ll make things easier later on, during
distribution :P
No functional changes.
Re-order functions in overworld.tiled so SBCL
doesn't complain at me.
Split some functions from overworld.tiled into
a new overworld.util package. Also rename the
files in a nice way!
Having MAP be a hash-table makes it a little more
mutable (friendly for a game of this structure.
Because, y’know, we… I’m too lazy to explain this.
Read the code. Which I’m pretty sure is illegible.
Sorry… =w=""""") :w:
>o< cries cries cires criesd
It draws to the screen, now! Err, well, it has
been able to do that, since my first day on
this project. But until now, there wasn't a
menu leading you there! c:<
Adds a small layer for translating input characters from non-QWERTY
keyboard layouts into their QWERTY counterparts. After all, it's
not the WASD that counts, but the position: ,AOE is just as valid!
Yes, ncurses. Look, I caved, okay?!
But in my defense, I couldn't find a simple way to
get raw input in both a framebuffer and an xorg
terminal, so… ncurses can handle the details.
I'm just a dummy, you can't expect me to do
everything!
Well, input is parsed into a somewhat-semantic
format, so at least I did *something* alright.
The previous method — clearing the screen and
completely redrawing every frame — caused severe
screen-flickering. This is better, calculating the
changed characters per-frame and printing only
those.