16

Your projects / The Legend of Vinesauce

« on: February 02, 2016, 08:56:33 PM »

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.

17

General discussion / Starter code pack?

« on: February 02, 2016, 08:45:49 PM »

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.

18

General discussion / Re: Are Zelda items/weapons copyrighted?

« on: February 02, 2016, 08:11:53 PM »

You should also use GPLv3 for the art, I read that if you want your game to be GPLv3, Creative Commons for sprites, sounds & music is not recommended, and all should be in the same license (I don't remember why)

Actually, FSF doesn't recommend using GPL (any version) for stuff other than code. CC0/public domain should be good for art, if you want to be credited, use CC-by-sa.

19

General discussion / Re: Free Legal Softwares

« on: February 02, 2016, 08:09:46 PM »

For video editing, there's awesome kdenlive (Linux only unless something has changed) and DaVinci Resolve Free (it's free for both commercial and non-commercial use, however it is closed-source unlike kdenlive and has few minor features, mostly pertaining to 3D stuff, which can be done via greenscreen and blender anyway, then mixed in, removed compared to paid version).

20

Bugs & Feature requests / Resize widgets

« on: February 02, 2016, 08:03:28 PM »

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.

21

Bugs & Feature requests / Re: Several suggestions for easier making game

« on: February 02, 2016, 07:59:09 PM »

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.

22

Game art & music / Would you be interested in port of RM2k/2k3 RTP?

« on: February 02, 2016, 07:55:59 PM »

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?

23

Bugs & Feature requests / Re: Several suggestions for easier making game

« on: February 02, 2016, 12:29:19 PM »

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

24

Bugs & Feature requests / Several suggestions for easier making game

« on: February 02, 2016, 12:07:50 PM »

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]

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