New Game Creator

[pgregory]

Thank you so much for taking the time to post this, it is very much appreciated. I'm developing this at the moment largely based on my own experience and with some input from some game developers who have experience working with AGD. So it's always valuable to get another perspective. I'll try to address each of your points independently.

Suggestions

1. Fill tool
You mentioned you're planning to add more sprite drawing tools including 'fill'. Yes, fill will be particularly essential, so you can make the outside of a sprite transparent with a single click.

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.

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.

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.

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.

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.

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 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.

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.

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.

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.

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.

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:

1. Saves you having to draw out the colour in every single room.
2. Saves data, since you don't need to store maps of colour data.
3. 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.
4. 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 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.

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.

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]

Thanks for listening and thanks for the responses!

[Lee Bee]

Just a few more quick thoughts, mostly minor issues…

(Note that I am still a bit ignorant about some of these issues and how stuff will work. Hopefully my ignorance will be useful in highlighting possible points of confusion.)

Objects in a room

1. For the sake of clarity, on the room tab, I'd like to see the "Objects" heading renamed to something like "Local objects" or "Objects in this room". Maybe also a heading over the 'global' objects saying "Global objects" or "All objects" (or just "Objects"). Maybe the 'global' objects window should appear above the 'local' objects window, so that you'd have a more natural downward progression?

2. When you add multiple copies of the same object to the room, I like that the program adds numbers to the name. Perhaps it should also add the object after the previous instance, so all objects of the same kind are neatly grouped together?

3. When you select objects in the local objects list, the objects become highlighted in their location in the room. I think it would be useful if they were temporarily highlighted whenever you merely roll the cursor over them in the list, so you can quickly see what is where. Possibly also the reverse, so rolling over the objects in the room would highlight their entry in the list (if visible).

Map and navigation

4. I feel like the Rooms tab and the Map tab are inextricably connected when building a game world. Perhaps it will become clear in the future, but at the moment I'm still not 'getting' why it's not possible to have them both in the same window/tab, or why having multiple instances of the same room on the map precludes that. Maybe it would solve the problem if the first instance of a room on the map is considered the "master", with subsequent instances as "copies", so if you select that room from the list of rooms, you're taken to the map location of the "master"?

5. While I agree with all objects having names, I'm not sure if every room needs a name, or the idea of selecting rooms by their name. If I'm dealing with a huge map of dozens or hundreds of rooms, I wouldn't want to have to name them all, or think of them by name. I'd want to think of them only by their location.

6. I'd also prefer to move between rooms quickly in a visual way, by clicking on exits on the map (or the edge of the screen) to move to the adjacent room. Or, perhaps you could have a small 'navigation' window showing the current room and the rooms adjoining it on the map? Or pressing Ctrl+cursor keys moves to the next room (in a game with a grid map)?

7. In your videos you show a system of setting up off-screen objects which take you to the next room when you collide with them. That will certainly be useful sometimes, but surely there will be many games where you can exit the screen at any point on the border, so the program should automatically take you to the corresponding place in the adjacent screen, without the need to set up hidden objects everywhere?

[pgregory]

Thanks again for taking the time to write this, very much appreciated.

1. For the sake of clarity, on the room tab, I'd like to see the "Objects" heading renamed to something like "Local objects" or "Objects in this room". Maybe also a heading over the 'global' objects saying "Global objects" or "All objects" (or just "Objects"). Maybe the 'global' objects window should appear above the 'local' objects window, so that you'd have a more natural downward progression?

Yeah, I agree the UI could in places be clearer, I'm sure that'll improve over time, it has changed many many times since I started already.

2. When you add multiple copies of the same object to the room, I like that the program adds numbers to the name. Perhaps it should also add the object after the previous instance, so all objects of the same kind are neatly grouped together?

Yeah, I need to add some sorting to the list, it just shows based on the order they were added right now.

3. When you select objects in the local objects list, the objects become highlighted in their location in the room. I think it would be useful if they were temporarily highlighted whenever you merely roll the cursor over them in the list, so you can quickly see what is where. Possibly also the reverse, so rolling over the objects in the room would highlight their entry in the list (if visible).

That's a useful idea, I'll make a note, thanks.

4. I feel like the Rooms tab and the Map tab are inextricably connected when building a game world. Perhaps it will become clear in the future, but at the moment I'm still not 'getting' why it's not possible to have them both in the same window/tab, or why having multiple instances of the same room on the map precludes that. Maybe it would solve the problem if the first instance of a room on the map is considered the "master", with subsequent instances as "copies", so if you select that room from the list of rooms, you're taken to the map location of the "master"?

It's more about the way the room is defined, a room isn't a fixed size, so being able to edit the room tilemaps in the larger game map is likely to become cumbersome. Remember also, that this tool isn't just for maze-type games, it's meant to be flexible, some games will have only one room, but it'll be much larger than a single screen. Flexibility is key, I don't want to get into a position where the games created by the tool all look and feel the same.

5. While I agree with all objects having names, I'm not sure if every room needs a name, or the idea of selecting rooms by their name. If I'm dealing with a huge map of dozens or hundreds of rooms, I wouldn't want to have to name them all, or think of them by name. I'd want to think of them only by their location.

Names are key for the logic. There will be places in the logic editor where the nodes need to refer to rooms and objects, doing so by name is the most effective and reliable method.

6. I'd also prefer to move between rooms quickly in a visual way, by clicking on exits on the map (or the edge of the screen) to move to the adjacent room. Or, perhaps you could have a small 'navigation' window showing the current room and the rooms adjoining it on the map? Or pressing Ctrl+cursor keys moves to the next room (in a game with a grid map)?

I'm sorry, I'm not sure I understand what you mean here, can you elaborate?

7. In your videos you show a system of setting up off-screen objects which take you to the next room when you collide with them. That will certainly be useful sometimes, but surely there will be many games where you can exit the screen at any point on the border, so the program should automatically take you to the corresponding place in the adjacent screen, without the need to set up hidden objects everywhere?

See my comment above about it not being just about simple adjacent rooms games. If you see in the latest videos, the two rooms to the right of the start room aren't even aligned, they could be anywhere, they overlap in terms of the screen size, and are offset vertically. This kind of flexibility is key in ensuring that game designers have the freedom to create innovative game mechanics, rather than being forced into particular game styles.

Please keep the feedback and ideas coming, I'm making notes of all of it.

[Cheez26]

The number one thing I need are project savefiles that aren't snapshot files. Besides that, I might want a VGM file converter built into the devkit.

Thanks for the hard work btw. Don't forget to make a native aarch64 Linux build.

[Cheez26]

I forgot to mention something about Furnace Tracker and I think you should look into it for sound and music. As somebody who wants to create soundtracks for the Speccy, I wanna mention Furnace because that can export VGM files, hence why I talked about converting VGM files earlier.

I'm sure you'll find a better solution though.

[pgregory]

The number one thing I need are project savefiles that aren't snapshot files. Besides that, I might want a VGM file converter built into the devkit.

Not sure what you mean by project savefile that aren't snapshot files, can you clarify?

[Cheez26]

Not sure what you mean by project savefile that aren't snapshot files, can you clarify?

When you do gamedev using a native tool in Fuse and whatnot, you don't get a lot of options. You either save to a *.z80 (or *.sna, whichever you prefer) or you have to put it on an entire TAP/TZX image. Back in the day, you save WIP games on tape too. So, it's nice to use cross-compilers instead.

[pgregory]

When you do gamedev using a native tool in Fuse and whatnot, you don't get a lot of options. You either save to a *.z80 (or *.sna, whichever you prefer) or you have to put it on an entire TAP/TZX image. Back in the day, you save WIP games on tape too. So, it's nice to use cross-compilers instead.

If you're referring to the game you're developing, it is saved in a Godot resource format on your PC. The export is to C source and header files and you compile it to a .TAP file.

[Cheez26]

@pgregory Thanks for answering. Bless you. Really.

[ParadigmShifter]

Export to C is probably best option yeah.

* Not too hard to convert C to ASM if you need to speed it up as long as the C compiler emits understandable and readable code.

You may want an option to export data as DB or DW or DG though. DB for binary data, DW for tables of pointers, DG for graphics (since you can then tweak them in a text editor). Option to reimport from those formats would be a bonus as well.

[Lee Bee]

Regarding the UI layout, I totally appreciate that it's a work in progress and windows/panels haven't settled in place yet.

Flexibility is key, I don't want to get into a position where the games created by the tool all look and feel the same.

absolutely!

The program should automatically take you to the corresponding place in the adjacent screen, without the need to set up hidden objects everywhere

[It's not] just about simple adjacent rooms games. [In my example game] the two rooms to the right of the start room aren't even aligned, they could be anywhere, they overlap in terms of the screen size, and are offset vertically.

I totally appreciate that some users might want the ability to connect rooms in non-linear/non-adjacent ways. But surely the vast majority of your users will want linear passage between adjacent rooms on the map, without having to set up exit points.

With many games, you can exit the screen almost anywhere, example:



In most flip-screen games, you can walk off the side of the screen into the next room, or jump/fall through the side of the screen, exiting at almost any different y position. This should not require setting up multiple exit points.

Perhaps you should add a universal setting:

 ☑ Allow player to freely pass between adjacent rooms on the map

This can be disabled if you want to tightly control all exit points.

I'm sorry, I'm not sure I understand what you mean here, can you elaborate?

Let me try to explain better…

I appreciate that your software is going to allow games where rooms connect in non-linear ways, perhaps with two different doorways leading to the same place. But obviously for 99% of games, all the rooms connect in a linear way.

If I'm working on such a game, perhaps one with dozens of screens, I will want a way to quickly move around between rooms. Obviously, I can do this by selecting the room name from the list, but that's not a spatial/graphical way of navigating my game world. It would be better if I could traverse the map in a visual way.

Here's one idea: Let's say I'm working on a room that has two exits to adjacent rooms, both on the right hand side of the screen. I move the cursor over to the right edge of the screen and two arrow icons appear - one at the top, one at the bottom (with room names below them). I can click on these to jump to that room.

[Room] names are key for the logic. There will be places in the logic editor where the nodes need to refer to rooms and objects, doing so by name is the most effective and reliable method.

Sure, though if a game has hundreds of rooms, you wouldn't want the user to feel compelled to come up with descriptive names for them all. Hopefuly, then, rooms are assigned automatic names (eg "Room 1", "Room 2") with renaming optional. I also hope that all references to a room in the code are automatically updated if the room is renamed!

[AndyC]

I totally appreciate that some users might want the ability to connect rooms in non-linear/non-adjacent ways. But surely the vast majority of your users will want linear passage between adjacent rooms on the map, without having to set up exit points.

Not necessarily, think about things like the pipes in Super Mario - they don't actually make sense spatially but feel very logical. Then there's Pseudo-3D arrangements like Tir Na Nog or Wonderland Dizzy, where you can go into the screen. Even something like Sonic the Hedgehog or Earthbound, which feel superficially spatial layouts have sections where that isn't quite true (levels in Sonic, the weird cloud world thing in Earthbound).

[pgregory]

Export to C is probably best option yeah.

* Not too hard to convert C to ASM if you need to speed it up as long as the C compiler emits understandable and readable code.

You may want an option to export data as DB or DW or DG though. DB for binary data, DW for tables of pointers, DG for graphics (since you can then tweak them in a text editor). Option to reimport from those formats would be a bonus as well.

The current exporter exports to C, including C structures, it's part of the way the whole flow works. However, the system is build to support other exporters as necessary.

[pgregory]

I totally appreciate that some users might want the ability to connect rooms in non-linear/non-adjacent ways. But surely the vast majority of your users will want linear passage between adjacent rooms on the map, without having to set up exit points.

With many games, you can exit the screen almost anywhere, example:

In most flip-screen games, you can walk off the side of the screen into the next room, or jump/fall through the side of the screen, exiting at almost any different y position. This should not require setting up multiple exit points.

Perhaps you should add a universal setting:

 ☑ Allow player to freely pass between adjacent rooms on the map

This can be disabled if you want to tightly control all exit points.

I'll probably end up keeping the current ultimately flexible system in place, or something like it, and offer various tools to make it easy to configure it to work the way you describe, and perhaps other common ways too.

Let me try to explain better…

I appreciate that your software is going to allow games where rooms connect in non-linear ways, perhaps with two different doorways leading to the same place. But obviously for 99% of games, all the rooms connect in a linear way.

If I'm working on such a game, perhaps one with dozens of screens, I will want a way to quickly move around between rooms. Obviously, I can do this by selecting the room name from the list, but that's not a spatial/graphical way of navigating my game world. It would be better if I could traverse the map in a visual way.

Here's one idea: Let's say I'm working on a room that has two exits to adjacent rooms, both on the right hand side of the screen. I move the cursor over to the right edge of the screen and two arrow icons appear - one at the top, one at the bottom (with room names below them). I can click on these to jump to that room.

I get that, but I'm not clear what you mean by "traverse the map". In the Map editor you just drag around and zoom and you can see all the rooms in the map. In the Rooms editor, there isn't really a concept of the spatial relationship of the current room, as it might exist in multiple locations in the map.

Sure, though if a game has hundreds of rooms, you wouldn't want the user to feel compelled to come up with descriptive names for them all. Hopefuly, then, rooms are assigned automatic names (eg "Room 1", "Room 2") with renaming optional. I also hope that all references to a room in the code are automatically updated if the room is renamed!

Of course, I'll make it as easy as possible to not have to put any unnecessary effort in, and when things change that affect other places, I'll endeavour to make sure all places are fixed up appropriately.

[Lee Bee]

In the Rooms editor, there isn't really a concept of the spatial relationship of the current room, as it might exist in multiple locations in the map.

I see what you're saying, a "room" is basically just like a "big tile" that can be re-used all over a map. But I do think you need to be mindful of what I would imagine to be the majority of users, who will use one room once each, in one map location.

In any case, if you've set up a room with off-screen collision objects which take you to another room, it would make sense to allow the user to use them to quickly move to that room. For example, if you roll the cursor over any object containing a link to another room, maybe an arrow should appear to the side allowing you to click the arrow and jump to that room?

[Lee Bee]

Not necessarily, think about things like the pipes in Super Mario - they don't actually make sense spatially but feel very logical. Then there's Pseudo-3D arrangements like Tir Na Nog or Wonderland Dizzy, where you can go into the screen. Even something like Sonic the Hedgehog or Earthbound, which feel superficially spatial layouts have sections where that isn't quite true (levels in Sonic, the weird cloud world thing in Earthbound).

On the issue of non-linear map linking, even the games which have these places, they are generally the exception and not the norm, while the bulk of the game will still operate on the principle that you can jump and fall at any place in the border between screens, so the idea of having to set up specific exit points doesn't seem natural for most games.

You mentioned Mario, well, not that we'll be using your program to make Mario games, since they're scrollers, but in my mind, Mario's pipes lead to different "levels" ie a different "map". This raises the issue of whether you're going to allow multiple maps within a game, or whether you have all your levels in one big map. That's something for you to think about I guess. Personally, I like structure so if my game had multiple levels or worlds, I'd prefer for these to be broken down into individual maps.

I might be tempted to move the "Map" tab to the very left and call it something like "Stages" or "Levels", from which you can select the basic stage/map of your game you want to work on. But that's just a random thought. This could also include non-playable "stages" of games such as "Game Over" sequences, intros, etc. I guess these need to appear somewhere in your program.

[pgregory]

I see what you're saying, a "room" is basically just like a "big tile" that can be re-used all over a map. But I do think you need to be mindful of what I would imagine to be the majority of users, who will use one room once each, in one map location.

In any case, if you've set up a room with off-screen collision objects which take you to another room, it would make sense to allow the user to use them to quickly move to that room. For example, if you roll the cursor over any object containing a link to another room, maybe an arrow should appear to the side allowing you to click the arrow and jump to that room?

Unfortunately, that's not going to be possible with the current implementation. There is no inherent logic applied to the collision shapes that define them as portals, that is the role of the logic assigned to the objects by the game creator. For example, the current test world has the transition logic assigned to the Player object, not the collision shapes, they are just dumb objects. The Player object detects a collision with another object as part of the logic that moves it under input control, checks the type of object collided with and moves to the appropriate room if it's the right type. There is nothing specific on the collision objects that the editor can use to determine that they are in fact objects used to transition to another room, that is up to the game creator.

[pgregory]

On the issue of non-linear map linking, even the games which have these places, they are generally the exception and not the norm, while the bulk of the game will still operate on the principle that you can jump and fall at any place in the border between screens, so the idea of having to set up specific exit points doesn't seem natural for most games.

I'm very consciously trying not to consider what is "the norm", as I've heard complaints on many forums that other game creation tools result in all games looking the same due to the limitations of the tool. My ultimate goal is to give as much freedom as possible to the creator, and impose no assumptions about what is normal or typical at all.

You mentioned Mario, well, not that we'll be using your program to make Mario games, since they're scrollers, but in my mind, Mario's pipes lead to different "levels" ie a different "map". This raises the issue of whether you're going to allow multiple maps within a game, or whether you have all your levels in one big map. That's something for you to think about I guess. Personally, I like structure so if my game had multiple levels or worlds, I'd prefer for these to be broken down into individual maps.

There is nothing preventing the engine from being used to create scrolling games. This is why the room editor does not restrict tile placement to within the screen area, a room can be any size and I plan to have methods to draw rooms based on offsets, allowing the creator to scroll (with limitations).

I might be tempted to move the "Map" tab to the very left and call it something like "Stages" or "Levels", from which you can select the basic stage/map of your game you want to work on. But that's just a random thought. This could also include non-playable "stages" of games such as "Game Over" sequences, intros, etc. I guess these need to appear somewhere in your program.

Currently, it is one game map. I do plan to have some other screen elements, but I haven't thought yet about how that will work. Things like menus, inventory, etc. are still not defined.

[pgregory]

In any case, if you've set up a room with off-screen collision objects which take you to another room, it would make sense to allow the user to use them to quickly move to that room. For example, if you roll the cursor over any object containing a link to another room, maybe an arrow should appear to the side allowing you to click the arrow and jump to that room?

Thinking about this, I actually believe that, if I understand what you're asking for correctly, the Map editor solves, or can be made to solve, this problem. The Map editor gives a high-level overview of the rooms in the game, and their relation to one another. So navigating in the Map editor makes more sense, you can not only see the rooms but how they relate. So clicking, or double-clicking, on a room in the Map editor could take you to the Room editor with that room selected. This would be better than working in the Room editor and navigating to other rooms with no clear indication of where you're going, in the Map editor you have the full view.

[Lee Bee]

There is nothing specific on the collision objects that the editor can use to determine that they are in fact objects used to transition to another room, that is up to the game creator.

Paul, thanks so much for taking the time to respond and explain this stuff to me, that makes sense.

I know you welcome feedback, but I hope you don't feel I'm wasting your time or becoming an irritation by banging on about this stuff. The issue of "easy navigation" is something I do feel is going to be important to your users, or else I wouldn't be making such a song and dance about it!

Bearing in mind what you've now told me, I would like to end this discourse by presenting you with 3 ideas, all of which you may well reject, but I feel I should at least mention them for your consideration.

1) If an object's code contains a link to another room, you could - in that case - still provide an easy-clickable way for the user to follow that link, to help navigate the map quickly. Sure, this won't work if the code isn't found in the object, but at least it will work in some cases, which may be helpful.

2) Or, create a standardized "linking object" (or call them "portals"), objects dedicated to links, which make it easy to create links between rooms. These also allow the user to jump to the place they link to with a single click. These "linking objects" wouldn't appear in the regular list of local objects, which would help keep the list neater, more focused on regular visible objects rather than navigational tools. Of course, the user wouldn't have to use this method of linking rooms, but it would serve as a handy default method that allows easy movement around the map.

3) It's your project and entirely up to you how you proceed with it, but please consider that some users, perhaps a large number, will want to use a standard grid-like map, as seen in the majority of flip-screen Speccy games. Therefore you may wish to consider if there's an easy way for you to implement facility for this style of game, perhaps a global map setting which tells the program to treats the game map like a grid. Such a game map could then be very easily traversed in the program, perhaps with shift+cursor keys for example.

I must emphasise that I'm not trying to bend your project in a direction that suits my own needs, I'm merely thinking about what I believe there will be demand for overall. But please don't take my word for it, I'm not a developer and have no experience. Ask friends and associates about this and see what they think! I'm not going to say another word on that issue and thanks again for the time you've spent indulging me!

Also, please don't take my questioning in a negative way. I am absolutely 100% positive and excited about your project. I'm just bringing up stuff I think may be "worth mentioning" for your sake.

There is nothing preventing the engine from being used to create scrolling games.

Blimey! If this all comes together, it's going to offer some serious competition to AGD!

[pgregory]

Paul, thanks so much for taking the time to respond and explain this stuff to me, that makes sense.

Thank you for the feedback, I never ever get fed up of receiving feedback from users/potential users, that would be foolish. I can't always promise I'll be able to implement everything everyone wants, because there are so many users with different requirements, but I always take it on board.

I'll definitely make some notes about your suggestions, and think about how to make some common game styles easier to create while retaining the flexibility of the system to create things that do not fit into the traditional spectrum game molds.

Please do keep the suggestions coming, always welcome. Hopefully it'll be in a place soon where some very early alpha testers might be able to start playing with it and giving first hand feedback.

[pgregory]

Another short update, this time with background collisions.

[Lee Bee]

Great updates! A few quick ideas (no reply needed)…

• Maybe each tile's "☑ Solid" option could appear directly under the pixel editor?

• Maybe non-solid tiles in the tile selector could have a more transparent (ie darker) bounding box? Better still, non-solid tiles could have a dotted bounding box? Something like:



• Please consider moving the palette down to line up with the top of the tiles window. That would bring all the "drawing tools" together into one place.

• A more involved suggestion - Could the tile selector window work differently, so tiles aren't "auto arranged" to top left, but are freely draggable like Desktop icons - letting you drag any tile to any empty space within the window? This would allow groups of related tiles (like your plant pot) to be organised in a more visually orderly manner to make stuff easier to find. In order to clarify that the window works this way, new tiles could be added to a random location in the window rather than always top left. The program could pre-allocate a certain amount of blank space to start with, then any time a tile intrudes the bottom 2 rows, two more empty rows are added below it.

[AndyC]

One option for quickly applying tile attribute changes would be to allow multi select. Use tri-state check boxes for attributes not currently consistent but allow toggling one between on/off to apply to all.

Another (or an alternative) would be to allow them to be viewed grouped by a given attribute or attributes (i.e. all solid blocks together) - then allow multi select and drag-drop between groups to apply the relevant attributes. This would also help users find the kind of blocks they're looking for when they have a large number of them.