Topics

I'm thinking more along the lines of discarding Tileset editor and utilizing same code for both editing sprites and tilesets.

I can't help, but see mostly pros:

- You'd be able to expand animated tile functionality to include as many tiles as one needs, with animation methods for loop (now 1-2-3-4 in tileset editor) and ping-pong (now 1-2-3-4-3-2 in tileset editor).
- Sprite editor's code is more mature and you can do such things like move stuff around with mouse instead of entering values by hand
- Easier to maintain - you won't have to maintain two different codebases that essentially do similar thing.

From runtime part not much would have to change, except tile animations as support for more than 4 frames would have to be added.

This way if I want to make game playable or linux/windows/osx I don't have to redownload Solarus just to get player executable.

Solarus editor crashes, when quest ran from the editor using "play" button encounters Lua error. That's annoying,

It's really useful thing and helps avoid tpyos that break the cdoe.

One thing I like about RPG Maker is that last project you were editing is automatically reopened when starting the program so you can easily continue the work. Maybe it's worth bringing over to Solarus?

Currently there's no place to ask for help regarding making games with Solarus. I mean, you could ask in General Discussion section, but it seems like more of "talk about whatever" section so your thread may get lost. I think "Help with Solarus" or similar would be a good addition to the forums.

I can't seem to find a way to resize/add patterns without editing the file in notepad.

Since I like these guys and I like Zelda, I want to make a fangame of both. Game writing, maps, some art etc. I'll do myself, however, I need the following that I can't do on my own:

- Hero sprite of Vinny of vinesauce that won't clash with ALTTP pack and where all I have to do is to just replace image files of tunics (I'd suggest using t-shirt colors to indicate tunic power)
- Basic code for things like menus, etc. Code specific to the game I can write myself, however I don't want to reinvent the wheel for systems that are in almost every Zelda games (and ALTTP) - gameplay-wise it'll be run of the mill zelda clone.

Is there any pack, mainly code, that would make it easier for me to just go and create most run of the mill zelda games, mainly talking about systems like enemies, menus, items, etc.? I mean, I could copy scripts from Solarus DX/XD, but I don't know which exactly I should copy, which to left in etc. I just want to start making the actual game, without reinventing the wheel.

I mean something like e.g. MS Paint have:



Not only it would be more intuitive, but also it has the added benefit of being able to resize in any direction you want.

Mostly I mean graphics as I'm not sure if Solarus is capable of playing midis. Of course for character sprites I'd need to make additional animations as those mostly only have movement cycle, but should be possible. As for chipsets (RM2k term for tilesets for those who are not familiar), it should be easy thanks to Solarus' easy and flexible tileset system, probably would put several chipsets in one bitmap as well since they tend to be quite small.

The question is, would anyone be interested in such pack?

[1. Item/enemies editors]

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