List view
Currently (October 2025) in the data/*.json we have all three: * layers.json is purely for implementing the view with Konva, and not intended to be modified by different adventures * rooms.json contains Konva data directly, but also "this furniture is in this room" information * character.json is purely data about animation frames and the different animations * items.json contains name, category and image source of each item but no more; could be split to contain model data (name and category) and view data (name and image file) Implementation proposal: Split data inside relevant jsons (such as rooms.json) in a way that model, view, and specific view implementation related details are clearly defined separately. For example: ``` { "room_one": { "view": { "fullScreen": true, "backgrounds": { "room_one_background": { "src": "data/images/room1.png" } } }, "furniture": { "macguffin": { "initiallyVisible": true, "view": { "src": "data/images/macguffin.png", "x": 230, "y": 445, "konva": { "className": "Image" } } }, "room1_door_to_outside_closed": { "initiallyVisible": true, "view": { "src": "data/images/room1_door_to_outside_closed.png", "x": 16, "y": 8, "konva": { "className": "Image" } } }, "room1_door_to_outside_open": { "initiallyVisible": false, "view": { "src": "data/images/room1_door_to_outside_open.png", "x": 16, "y": 8, "konva": { "className": "Image" } } } } } } ``` I'm not sure if there is such a thing as a "view" without its implementation, but we'll find out! Image, resolution, position on screen, type of the object (Image, Text, Shape) could be shared between view implementations via some sort of a hierarchical structure. Or it could get overly complicated very fast. Some jsons are purely about view, some are purely about model/game mechanisms (such as interactions). layers.json purely considers the Konva implementation. Scope of this milestone: * guess which bits of view information are Konva-specific * split data in jsons between model, view and the Konva view implementation according to the above guess * can't make it perfect before we have at least another view implementation, which is very far off * consider the directory structure (move layers.json somewhere else as clearly Konva-specific?) Thoughts: * Previously considered splitting jsons to separate model, view and konva data; this is not very handy from the adventure author's point of view, who would need to maintain _and keep in sync_ multiple jsons related to the same entities
No due date•2/6 issues closedOriginally KGAE was implemented as a quick prototype with Konva (then KineticJS) and you could say that the game state was fully maintained in its UI state. This milestone contains work to separate current game state from UI state. The transition to some sort of an event-driven model-view-viewmodel or model-view-controller structure is ongoing. * Changes in the model trigger events * View/view model listen to those events and change the UI accordingly * View model has the responsibility of tracking the state of _presenting_ the game state in the UI. The game state in the model is not affected * Player interaction with the UI triggers events to change the game state in the model The aspiration is to eventually have multiple different presentation implementations. This could be in the form of different front-end frameworks, right now the game is presented in a HTLM5 canvas element, but it could just be a HTML web page as well. But more than that, the engine could eventually drive text adventures, choice-based choose-your-own-adventures, have a character walking around in the room - with point-and-click interface or a Sierra-style parser. Scope: * TBD * KiiGame main class does not contain functionality of models, view models, controllers or views
No due date•11/13 issues closedScope: * LZ separated to its own project. KGAE installed as a dependency of LZ. Bonus (out of scope?): * Possible to install KGAE as a dependency and start creating new adventures easily(ish) * KGED stil (again)l working fine and KGAE installed as a dependency of KGED (as it is now). * KGAE game engine JS separated to its own package from assets etc ## The game engine as an installable dependency For the javascript code, this is not a biggie. This actually is already true (as of 0.4.1, maybe not the current development version due to json differences) in KGED. But for the assets (default UI graphics) and data files (layers.json at least), this needs some thinking. Maybe we need to have some sort of setup scripts that copy/generate the basic files. ("Empty" jsons in the right places etc). These could be separate dev dependency packages. Could have a metapackage for an adventure creation suite. ## Game engine refactoring ### Menus refactored into rooms (DONE) Menus can be created as rooms with furniture, and use interaction commands (such as do_transition etc) - no need to hardcode menu stuff. This makes it easier to create "menus" in the editor as well. ### Make player character optional. This way, the engine and KGED do no need to come with player character graphics. For KGED, it might be good to come with some example graphics. Placement of the speech bubble needs consideration without PC graphics.
No due date•6/10 issues closed