Several suggestions for easier making game

[darkhog]

Since the developer is familiar with RPG Maker, I'll be using RM-related terms in this thread.

1. Item/enemies editors
You could choose basic item/enemy archetype (e.g. bomb/sword or shooting/fencing enemy) or you'll could use advanced option that would let you input item code directly. Think of it as RPG Maker's Database.

2. Better default project template
It should consists of the following:
- Basic game system like one in Legend of Zelda: ALTTP while not using any of their assets, that is all the menus/save system.
- Few enemies with at least one of each type
- Basic items (swords, bombs and so on)
- "Default" map, nothing fancy, empty one would do just fine. This way, people without too much coding skill could start making the game right away.
- Basic resource pack to get you started consisting of public domain/cc assets, something like in sample project would do just fine.

3. RPG Maker-like event editor
While Lua is nice and easy, not everyone has the right mindset to be a programmer. Therefore, some visual coding aid would be helpful. Since the developer is familiar with RPG Maker, I think RM-like code editor would do just fine.

That doesn't mean you have to make "event interpreter" either, it could read and generate Lua code. Some years ago I've contemplated doing so for another RPG engine that uses Lua (Novashell) before learning it was abandoned and therefore it would be just wasted time. But here's what I got.

The whole event editor would be based on "special" Lua comments that would be read to get event list, so for example the following code would be generated for say, <>Move Picture id: x, y event:

Code Select Expand

--@MovePictureEvent 6 12 18
picturelist[6].move(12,18)

The comments would have no effect on the game (Lua would just ignore those), while the event editor would look for these special comments and build the event list around that. When clicking OK, the event editor would just generate appropriate code, placing "special comments" as well. Every event editor-generated lua file would start with "--@EVENTEDITORGENERATED" comment to differentiate between regular Lua scripts and code made in editor, so the event editor can refuse such silly requests as trying to edit regular Lua file in it (which would break it since it doesn't have appropriate "event comments" to generate event list from).

[Christopho]

I agree, all of these suggestions are features that we would definitely like to have one day. But this is long term.
Keep in mind that Solarus is young, we are far from that. A few months ago, some data files like dialogs and quest properties still had to be edited by hand
(By the way, the last time I used RPG Maker was in 2002.)
But again, yes, these ideas are the long term plan for a Solarus 2.0 one day.

[darkhog]

Nice to know! I could make that event editor thing as a proof of concept, but my C++ knowledge is limited, more of a C#/Delphi guy (by the way, both RM2k and RM2k3 were written in Delphi).

[Christopho]

Suggestion #2 can probably be done this year thanks to the work of Diarandor, when he publishes his sprites with a creative commons license.

[Diarandor]

Hi! Yes, but still I have to draw some animations (for pulling, pushing, running, maybe for swimming, etc). The main animations (stopped, walking, attack with sword and maybe some other) of the swordsman are ok, but I plan to improve them. And the same for the sprites of the other 2 heroes I am creating. I will notify all of you when this is done to add them to the demo of Solarus (and maybe to "Children of Solarus" if you want, which would be an honor). You may need to wait until the end of the year until I have redrawn the 3 heroes, although the current sprites could be used temporarily (even if some animations are still missing). There are a few other sprites for other entities and tilesets that can be used too, but I will need more time to create more of them and improve them.

[darkhog]

Suggestion #2 can probably be done this year thanks to the work of Diarandor, when he publishes his sprites with a creative commons license.

Well yeah, but the most important part of #2 is IMO pre-made code. As for graphics side of things, graphics from sample quest could be used until better one are made.

Anyway, if editor would still be Java, I could already work on event editor thing, but alas, it isn't anymore.

[Christopho]

The sample quest has a nice hero sprite but only with stopped and walking animations. No sword, nothing more.
For the event editor, before any code we need a sketch of GUI, to discuss how to present it to the user. There are a lot of possibilities and I don't know yet. Suggestions are welcome!

[YoshiMario2000]

I think that a simple GUI for the editing of scripts and whatnot  would seem to be the go to option,
In terms of user friendliness, Try using editing blocks that are code, just in GUI format.
An example could be the online editor called "Scratch". Using the blocks as code. Just an Idea.

In terms of an enemy script editor, how about just having the Basic necessities up at the top of the editor,
and then have everything else in Block script editor fashion below.

Also maybe even have in quest editor tutorials for beginners?
The layout is pretty basic and mostly self expiatory, but I'm not your average person walking into a programming environment.
I'd imagine some people with no programming experience could potentially get lost in the editor.

Anyways, Just some ideas, Not meant to be the exact way of how it should be done.
(Lately my posts have been lengthy, haven't they?)

[darkhog]

The sample quest has a nice hero sprite but only with stopped and walking animations. No sword, nothing more.
For the event editor, before any code we need a sketch of GUI, to discuss how to present it to the user. There are a lot of possibilities and I don't know yet. Suggestions are welcome!

Just model it after one in RPG Maker.

[ffomega]

I have a couple suggestions as well.

Suggestion 1:
You could always make some elements models after Hyrule Magic.  For instance, you could place visible labels on entities like teletransporters like code (A0, A1, etc).  Currently, in my maps, I use sprites of actual letters I added to the tileset, placed them on high layer, made them dynamic and disabled them at start.  In Tunics, this is done as well but by using dynamic tiles of enemy icons and such in the tilesets.  However, the only way to identify stair, sensor, entry, destination, and switch entities is to double click them.  Giving entities a visible 'in-map editor' label will help streamline editing in my opinion.  Or simply hovering the mouse cursor over an entity can produce a brief tooltip you edit yourself telling you things like its name and, depending on the entity type, it's connection to other entities if it has any.  In the case of teletransporters:

Name:
to Map:
to X:
to Y:
Transition:

This tooltip tells you everything you need to know about the teleporter without ever needing to click on it.

Suggestion 2:
How about a user-interfaced HUD editor?  Players can visually create the HUD in the same manner as the sprites and tileset.  The entities and sprites for the HUD can still be placed like they always have been within the editor, but a separate section would allow you to add and remove elements to and from the HUD like hearts, magic meter, how many items players can use (up to 4), the action button and the main weapon (sword), Ruppe counter and icon, key counter and icon, clock (if one wants one), and text names for areas, rather than having to manually create the HUD from the LUA engine.  This could also be applied to the menu(s).  Just add a new menu (which would be a folder) and within it, the icons needed to display it, and their x, y positions.  All of which could be called upon like the menu is currently by LUA.

Suggestion 3:
Autotiles.  This would probably make map editing a lot faster for users who still prefer the RMK method of map editing.  Now I understand that this might be more difficult than it seems but in my opinion, if it could be pulled off it would be amazing.  being able to gran a shallow water tile (8 x and the ground shape around it would speed up map editing.  This feature could be turned on or off at any time to allow fine tuning of map editing, such as being able to create specific mapped patterns or decorations, and place roads in confugurations not possible with the autotiles.  I just feel more comfortable being able to click and drag the mouse over an area with an autotile and the tiles arrange in specific patterns according to how they are configured.  Autotiles can be entities that use the tileset, but can be determined by the player, and displayed in a submenu within the tile editor section.  You could have the autotile editor include decorations with a random factor that seeds random decorations the player determines such as flowers on green ground (or yellow ground), rocks on dirt soil, or diamonds on mountains, and how often they appear while 'painting'.  individual tiles can still be resized, copied and pasted as before, but you can switch between a paintbrush (or autotile) tool, and the current map editing methods if you like.

[Christopho]

1) There is already some information displayed in the status bar when you pass the mouse over an entity. There will be more details in future versions.
2) A menu editor would be awesome indeed. This is a huge work but it will be done eventually.
3) Autotiles are great, but currently I don't really know how to implement them. In Zelda ALTTP graphics, there are so much complicated rules of putting tiles together that I don't know how to unify them. Some have diagonal variants, other have not, and the ones that have some don't all work the same way... Shallow water tiles work differently than dirt pathways, that work differently than dungeon rooms. I need some help to decide how to do it exactly. With pictures of all different possible configurations. Then yes, an autotile editor that provides these configurations can be the solution. But again, I totally agree that the feature would help a lot.

[ffomega]

Well, I had a thought on dungeon auto-tiling.  The devs of Tunics created pre-rendered room segments that all fit together via RNG.  Also, Dream Mix is creating a Zelda-esque level designer based on the original Legend of Zelda with 16-bit graphics that utilizes auto-tiles, from the Game Maker engine.  You can check out all his past streams where he live codes, just like your channel, on youtube here.  He managed to make auto-tiles work great for indoor and outdoor maps.  He is also implementing diverse tiles.  I am not a coder or programmer myself, so I won't pretend I know what I'm talking about nor assume that it is a simple process.

Autotiles could be set up based on their properties and adjacent suctures.  For example, you could set up parameters that check which types of tiles touch others.  Say, green ground touching dirt soil, dirt soil touching shallow water, green ground touching deep water, etc.

Code Select Expand

--Pseudo Code

if green ground tile collides with shallow water tile
    then create shallow water edge tile at x, y;
end

if rock tile collides with deep water tile
    then create deep water wave tile
            create deep water tile at x, y;
end


Setup would be similar to RPG Maker's autotiling system.  placing a tile would create 8 tiles around the individual tile.  If a tile changed on, say, the right middle edge, you'd add tiles to top, top right, right, bottom right, and bottom of the new tile, but change the top right and bottom right tiles of the tile to the left of the newly placed tile, and then change the left-touching tile to a new tile.  Hard to explain in the right words xD

I suppose that auto-tiling, on paper, sounds a lot easier than it probably is in code though