HL-CMS Image-Support

 Now working on adding file/image support to CMS and game... there's a little surprise I have in store for the new UI... nothing too fancy, no full-on graphics yet, but something we definitely needed for combat ;)

I just need to create a special condition for unusual column names `[file].size`, `[file].data`, `[file].name`, etc. - so that the CMS recognizes all the columns prefixed with "[file]." are related/sub-data to be provided by a single File-Input form element. (and of course I need to change the form encoding so it will submit the file, not just the name)

Making the "++Batch Add"/list-add feature work with files is a little hairier. I need to switch the loop from using the Name(s) field (newline delimited), to File(s)... which will need to auto-pop names for the loop... then there's a bit of post processing I need to do on the files, namely generating thumbnails for the CMS UI (and adding the thumb-view for the Files table).

Relatively easy stuff in general, but I deliberately left the CMS generic in terms of table/form structure so I could easily add tables and fields without needing do define new UIs for each. And, Files fundamentally breaks the simpler structure with its multi-part field(s). To avoid adding tons of case-specific logic (over time), I decided to base the association off the special-characters in the column names. This should allow me to create other related interfaces without breaking the flexible CMS architecture. So, down the road if we want to split the Files table into media-specific sub-tables, with their own special fields (like music, sound effects, video, images, sprite-sheets, zipped-content, and some other types), we could.

For now, I don't expect to be adding too many files... and I may just have images and sprite-sheets as separate tables that simply reference the files-table as needed.

Before I started HardLife, when I was first tinkering with Twine to make a game based on Kendra, I was playing around with using faces during dialog (the faces were created/ripped from RMMV and the sprite-maker). That is a fun feature I would like to get back to, but the dynamically generated characters in HardLife (and planned for Kendra) will be rather challenging, unless we composite layers and do some palette/hue-shifting tricks...

So... yeah, that's basically what we're doing. Though it's not dialog faces (at this time), but something else we can do with layers and color-shifting. ;p

I'm expanding on the new UI, so that you have 2 views for your party and targets... the scene-overview, which shows every object summarized with a single "health" bar, and a more detailed view for your currently selected target. (if you leave it in that view, the plan is to keep it locked on that target)

The expanded view will show their stats, conditions, and other-such. Eventually it will contain layered character graphics, but that still requires a lot of planning and rendering for different body-shapes, though I have worked out how to handle the color-variations without too much extra overhead. For now the information will be purely statistical...

(once the 2 branches are ready to be re-merged, the expanded "target view" will have a link to display the character appearance/description in either the scene-viewport, or the story-log area (perhaps a bit of both, depending on what we show).

Eventually, the scene-viewport will be compositing object and character layers into the room... but that is likely still a long way off, and much lower on the list than the basic engine expansions we've been discussing. None the less, as we will soon have proper image support, some generic objects/characters may be used for a live scene mock-up early next year.

For those wondering, the HL-CMS will take in the binary data for (small-ish) files, and spit it back as JSON with Data-URIs so the content can be loaded inline, and contained within the game's .htm file.

Once I get the file-import and target-view done, I should have an early alpha for the new UI ready.

Character creation will likely be added directly to the new-UI branch, with the intent of merging the old system back in, rather than the other way around, and it should make it into the 2nd or 3rd alpha for the new UI. Then it's on to room/scene based navigation and populating for encounters/situations. The merging comes not long after that  (once all the inter-dependent updates/redesigns are stable).

After the new UI is fully merged/released, I'll start working to get the webserver/hosting back up and running again, there are some things you just can't do on social platforms alone... (this will also give us an open channel in case we run into issues with game content and ToS on other distribution channels) ...and none of these sites are terribly good at managing a content-archive and private scrap-book for works in progress.