Zelda Modern
#16
Posted 08 June 2010 - 02:38 PM
#17
Posted 08 June 2010 - 02:54 PM
#18 Guest_JohnStacy (Guest)
Posted 08 June 2010 - 03:11 PM
This post is super long. So I put it in a spoiler tag for convenience.
So, I have an idea.
Once 2.5 is finished, it could possibly branch into 2 branches. One stays on Allegro and goes along the path of a simple game engine a lot of people like that doesn't rely on scripting. This one will be Zelda Classic.
The other branch will change to SDL and become very script heavy and use the suggestions of the gentleman who started the topic. This one will be Zelda Modern.
Thoughts?
#19
Posted 08 June 2010 - 03:49 PM
Moving to true color would be beneficial, but probably would require rewriting everything that deals with the graphics.
One thing that's good about having palettes though is that you can change colors without wasting space by copying images and recoloring them just to make them a different color.
#21
Posted 08 June 2010 - 06:08 PM
Think RPG Maker XP. That's how ZM should function.
On that note, a snippet-based event scripting system would be very nice-- Something easy for newbies to handle- shown in plain English, but actually stored in #comment delimited Python or something similar.
And yes, ZM would undoubtedly be a fork of ZC with a focus on a clean codebase and modularity. Cross-compatibility with ZC is not a priority, but may be implemented later.
The quest file format will probably shift away from pure binary into something more like a .zip archive or a compressed .iso.
#22
Posted 08 June 2010 - 10:38 PM
I know the devs are highly against that, but remember that having a proper version control system means that you could have people introduce all kinds of features without f***ing the official builds (non-devs can see the source code, devs can both read and write to the source code repository).
In addition to that, people could check out the source code, make their own builds (share the source code which can be merged into the official source by an official developer--one who has read AND write access to the code repository).
Merging code isn't that hard, either... good version control software can do that entirely for you by looking at the differences between the new build and the old build and literally merging the code changes between the two (seamlessly).
If it were open source, we'd have a lot less problems to worry about.
Edited by TMS, 08 June 2010 - 10:38 PM.
#23
Posted 08 June 2010 - 10:53 PM
I would *love* to see ZC made open source and given a proper version control system.
I know the devs are highly against that, but remember that having a proper version control system means that you could have people introduce all kinds of features without f***ing the official builds (non-devs can see the source code, devs can both read and write to the source code repository).
From what I understand most of the devs agree that it should be open source; BUT the creator Phantom Menace wished that it remained closed, and they want to respect his wishes.
#24
Posted 08 June 2010 - 11:06 PM
#25
Posted 08 June 2010 - 11:29 PM
From what I understand most of the devs agree that it should be open source; BUT the creator Phantom Menace wished that it remained closed, and they want to respect his wishes.
That being said, if and when the dropping of Allegro occurs, it would probably be better off to start off an open source repository then--because it's no longer a derivative of Phantom Menace's work--it's a completely new codebase.
#26
Posted 09 June 2010 - 01:22 AM
And if that happens and Phantom Menace says no, it's staying closed source, then I don't see why this so very talked about 3.0 can't happen as the first version another project that takes inspiration from Zelda Classic but incorporates these features we all talk about having. A new program, new vision, a new name, built from the ground up.
#27
Posted 09 June 2010 - 10:25 AM
#28
Posted 09 June 2010 - 02:07 PM
@JohnStacy: Like I said before, EVERYTHING necessary to make a Zelda clone will be pre-scripted. The point of pulling away from hard coding is to make the engine more modular for power users, like myself, while still making it usable by ordinary users. Support for ZASM would be maintained, and a ZScript compiler will be available. Python is merely an option.
Think RPG Maker XP. That's how ZM should function.
On that note, a snippet-based event scripting system would be very nice-- Something easy for newbies to handle- shown in plain English, but actually stored in #comment delimited Python or something similar.
And yes, ZM would undoubtedly be a fork of ZC with a focus on a clean codebase and modularity. Cross-compatibility with ZC is not a priority, but may be implemented later.
The quest file format will probably shift away from pure binary into something more like a .zip archive or a compressed .iso.
Then do it. This seems like a pretty good idea. And with that many changes you would have to start all over again. There would be not much use from the old source code. If you want to see someething like this then you have to do it. I don't think the devs are just going to abandon ZC and start on ZM.
You want ZM? You have to start it yourself. Talking about it isn't going to do anything.
#29
Posted 09 June 2010 - 02:48 PM
#30
Posted 09 June 2010 - 03:49 PM
Sorry if I sounded a little harsh earlier.
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users