gsamore 2019-10-08 20:23
It took me a second to get the gimmick of the game, but this is incredibly clever!! I'd love to see more of this type of presentation (emoji only) and am very curious about how you managed to program it!
Foon → Ludum Dare Explorer → LD45 → ๐
By nmccoy
| Category | Rank | Score | Count | |
|---|---|---|---|---|
| Overall | 2 | |||
| Fun | 2 | |||
| Innovation | 2 | |||
| Theme | 2 | |||
| Graphics | 2 | |||
| Humor | 2 | |||
| Mood | 2 |
It took me a second to get the gimmick of the game, but this is incredibly clever!! I'd love to see more of this type of presentation (emoji only) and am very curious about how you managed to program it!
All the source code is embedded in the html file, though not really documented or anything (I was kinda making it up as I went so there's some questionable design decisions), so to summarize: The core of the game consists of a dictionary serving as the "emoji pool", tracking the count of each emoji in play, and a dictionary mapping emoji->the "rules" associated with the emoji. Each rule is structured as "event:operation", the operation usually being a substitution effect (indicated with โก) but sometimes a shorthand (e.g., bare emoji without one of my specially handled "verb" emoji is a shorthand for "replace nothing with these"). Hovering over an emoji lists all the rules that could currently be executed if the appropriate event were triggered (or all the rules if hints are enabled); clicking on an emoji fires the ๐ event on that emoji, executing all the ๐ rules on it. ๐ and ๐ are the only events explicitly invoked by the Javascript framework, all others are triggered "in-engine" by the โถ verb-emoji. When this happens, the framework iterates over all non-zero-count emoji in the pool and executes the appropriate rules on each of them, a number of times equal to the count for that emoji. In terms of presentation, I set it up so that there's a couple divs in the page that "request" specific emojis from the pool in a given order using a data-value in their tag; the "render" function first checks for the requests made by the page, grabbing those emoji from a temporary copy of the pool and allocating them, then puts all the remaining non-requested emoji in the main centered div. (There were a lot of visual bugs in testing, like when I forgot to add ๐ฅพ to the inventory requests so they hung around in the main pool div instead.) Usable buttons (those with at least one ๐ event that could legally be executed) are given an extra class when being written to the html of the page, which the CSS then gives an eye-catching rainbow-animated background to. Figuring out how to have the emoji game engine track if the player was in combat/had defeated all foes was tricky; I didn't implement a categorization system, so all the combatant emoji had to have a rule where they responded to an event to indicate that they were still alive, and a rule that removed them when the player fled combat. Halfway through development, I made a helper function that I could give a list of "these emoji are combatants" and it would append those two rules to the dictionary's rules for that emoji, saving me a lot of further repetitive emoji-typing. The โ emoji signifies that the player is in combat; the โ :โ rule that the combatants all have means "when the โ event fires, add a โ emoji to the pool" as an indicator of "hey, I'm still alive". The defeat rule for each combatant looks like "๐:๐ฅ๐ฅ๐ฅ๐ฆโกโญโญโ" -- when clicked, trade 3 damage emojis and a shark for 2 experience points and a check mark, if such a trade is possible. The โ has a ๐ event that removes all โ , fires the โ event to ask if anyone's still around, makes a ๐บ if there aren't any โ in the pool after that, then replaces itself with nothing. In hindsight there may have been a cleaner way to do it, but I think that it's a good solution for not exposing too much unintelligible "system guts" to the player, since *all* of the game state is stored/represented by visible emoji! In the end, I was able to disguise most of the mechanical state as UI - unlike in most games where the health bar on the HUD is a visual depiction of the internal number that tracks the player's HP, in this game the health bar literally IS the player's HP! Kind of a wild concept, if you're used to the model/view/controller paradigm of game architecture; here the model and view are one and the same, and the controller mostly consists of things taped onto the modelview elements.
@nmccoy Thank you for all the helpful info! (Also be sure to play/rate other games so more people will see yours! You've got a winning game here imo)