Absolutely, each of the "drawing" features will be embellished with additional tools appropriate for the type of drawing facility they provide, which is definitely on the roadmap. My current process is to try to get the basics working across the board, and then enhance with usability and efficiency improvements.
Agree 100%, the location of these things has "evolved" to a degree, so there is an inconsistency I'm aware of, and the add button isn't the only place. I'm not overly concerned about this, it's just me experimenting with how different approaches feel, I'll settle on one common paradigm at some point and retrofit it across the board.Lee Bee wrote: ↑Fri May 17, 2024 12:32 pm 2. Location of the 'add' button
There's currently an inconsistency to the location of the "add button" - generally it appears below the window it applies to, but this is different for the tiles and sprites windows, which have the 'add' button within the items list. Then, I believe the main sprite window has both styles in one. I think consistency is important to quickly understanding how the interface works. My own instinct says that an add button should affect the window BELOW it, but I do like the neatness of it being below the window and can very quickly adapt to that, so long as it's consistent.
This is something I've been thinking about. If you look at the earlier videos, there was a separate "Tiles" tab, and then I incorporated it into the Rooms editor because it made more sense. I may well do the same with the Sprite editor. I'm not rushing into this because it may be better to have more, simpler tabs, than fewer overloaded and overcomplex tabs, it's a balance.Lee Bee wrote: ↑Fri May 17, 2024 12:32 pm 3. Do we need a separate 'Sprites' tab?
Given that sprites are a sub-property of objects and aren't used for anything else, I'd feel less confused by the interface if there were no 'sprites' tab but the sprites editor was integrated into the objects tab. In the Objects window, on the right, you have two tabs saying 'Animation' and 'Logic'. How about you add a third tab on the left of these called 'Sprite editor'? For me, that would be more logical.
The information displayed in the Rooms editor has changed a lot recently, and will no doubt continue to change as I find better ways to represent it cleanly. The confusion about the different object lists is due to their functionality. The visual grid at the bottom is the global list of object definitions from the Objects tab, that can be dragged and dropped into a room, hence the visual representation. The text list is the list of "Object References" in the currently edited room. An Object and and Object Reference are two different concepts in the system and represent different information. For example, the Object (lower panel) contains the visual (sprites) and logic, while the Object Reference (top list) contains location information, instance-specific settings for variables exposed in the logic editor, etc. The interface definitely needs to be improved to make the distinction clear and easy to understand.Lee Bee wrote: ↑Fri May 17, 2024 12:32 pm 4. Confusing windows
If I'm understanding this correctly, the map screen seems to contain TWO different versions of the rooms and objects windows - each having a 'text list' version, plus a graphical version at the bottom. This "two versions of each thing" may be a little confusing at first, especially due to the absence of headings for the two lower graphical windows.
I would recommend adding headings to the lower windows. Or, better still, make it so you have the 'rooms' across the top and 'objects' at the bottom, in each case, with the text list on the left and the graphical view on the right. This brings connected windows together.
Alternatively - would it be possible to simply combine the 'text' and 'graphical' windows into a single window? So you would have a 'rooms' column on the left and an 'objects' column on the right, each has a vertical list of text, with each item having a square graphical icon on its left.
The room and map tabs serve different purposes at the moment. The rooms tab is where you define the visual representation of a room, the map is where you place those rooms onto a larger map, along with things like global objects. It is important to keep them separate for efficiency reasons. An example is that it is entirely possible to use a single room definition multiple times in the map. Right now I think having the room editing functionality in the map tab would be confusing, especially when it comes to reusing rooms, but I'll make a note and keep it in mind.Lee Bee wrote: ↑Fri May 17, 2024 12:32 pm 6. Do we need a separate 'Map' tab?
The main "rooms" window seems very similar to the 'Map' window. Do they really need to be two separate things? Aren't you basically just 'zooming out' a bit? How about losing the dedicated 'Map' tab, changing the name of the 'Rooms' tab to 'Map', then on the right, below the big room window, add a magnifying glass icon which toggles between zooms out to the full map and back in to the last viewed room. Double clicking any room on the list of rooms will zoom into it, as will double clicking the room on the map.
Definitely, this is planned. I do plan to have a default paper and ink colour per room and per project. In many cases this will obviate any need for colour painting at all, saving on space and at runtime.Lee Bee wrote: ↑Fri May 17, 2024 12:32 pm 7. Default paper colour
I also think you should be able to set the default global paper colour (black by default), plus every room should allow an optional room default paper colour. So, for example, if you're making a forest game which normally has a green background, you can make the universal paper colour green. But for a room where you go in a house, you can set this room's default paper colour to white.
This is interesting, I'll have a think about this. In reality, it wouldn't necessarily save data, as due to the nature of the code on the Spectrum side, there is still a requirement to output the colour information in the room data, whether that comes from the separate room colour map or the tile definition doesn't change anything. I quite like the idea of having a default colour for a tile and being able to change that colour in the tile definition and have any use of that tile still relying on the default colour to update. Thanks for this, very interesting, I'll make some notes and have a think about it.Lee Bee wrote: ↑Fri May 17, 2024 12:32 pm 8. Colour mapping system
OK I've left the most controversial one for last. Bearing in mind I have NO experience of making Speccy games, so take this very humbly with a pinch of salt - I feel that the decision to store colour independently of tiles is a bad idea. Yes, it allows colour variations, but surely the majority of the tiles in any game will be the same colour in most cases?
Instead, I would strongly suggest having colour being directly assigned to tiles. You'd still want to keep the ability to freely draw custom colours onto any room, but that would be something you'd do on more rare occasions.
I believe that assigning colours directly to tiles would have four huge benefits:
As for alternative tile colours, I believe it would be better to have a feature called 'colour variants'. So, with a tile selected, you click a button at the bottom to "add colour variant" which adds another tile directly after the current one in the list but with a little "+" or something overlayed in the corner, indicating it's an "instance" using the graphics of the tile before it. You can then edit its colour independently.
- Saves you having to draw out the colour in every single room.
- Saves data, since you don't need to store maps of colour data.
- Lets you instantly edit the colour of tiles all over the entire game map - important when you're gradually developing your game's graphics, adding new tiles and seeing how they all look together.
- Makes drawing maps much faster because when you glance at the tiles window to pick a tile, you will quickly and clearly be able to see what's part of a tree and what's part of a wall, because they're green and red. But in black and white it's harder to quickly see that and will create a barrier to the workflow.
As for controls - you could keep the exact same colour controls you've already added there on the room screen. But when you have a tile selected, its ink and paper colour would be highlighted on the palette, which you can change by left- and right- clicking on the palette.
Also, add a "transparent" swatch to the palette. You can assign this to a tile's paper colour, which will mean that ONLY its ink will show on the map and the paper will use the default paper colour.