PDA

View Full Version : Next Gen ZC. (Otherwise known as ZC3.0)



Gleeok
06-20-2015, 12:48 AM
This has been brought up an inordinate amount recently and based that it might be time to take it seriously. Here are a few resources from past discussions and proposals:

Recent thread (Very recent, only a few weeks old) :
http://armageddongames.net/showthread.php?96959-ZC-3-0-From-Scratch-Plan

Old DarkDragon post that was previously hidden from public view:


ZC 3.0 proposal

I'll step forward and make some concrete proposals for ZC 3.0. All comments are welcome.

The big picture: goals of ZC 3.0

1. Legitimacy and modularity
ZC 3.0 will be divided into two parts: a 2D game engine, and a Zelda "content pack," likely distributed separately. The game engine will be generic enough that we can develop and promote it with no fear of violating anyone's intellectual property rights, and would be capable of playing any of several user-developed content packs.

2. Usability
The engine, combined with the Zelda content pack, will allow a user with no knowledge of programming or scripting to create a quest of complexity similar to Link to the Past. Both the game and the quest editor will feature a modern GUI. The engine will be Internet-aware, with in-game support for downloading quests from and submitting them to the Internet.

3. Customizability
Users who are comfortable with scripting will be able to customize most aspects of game play, up to writing their own content packs.

4. Fresh start
ZC 3.0 will not be able to play 2.50 quests. Auxiliary tools may be able to convert some 2.50 assets (tiles, etc) to 3.0 format.

Technical details

The game will be written in C++, using Qt for its user interface, and LUA for its scripting engine. The code will be as cross-platform as possible, supporting at a minimum Windows XP and later, OS X, and Linux.



To summarize, any discussion on this in the past two years has just boiled down to the following:

1. Will be open source and primarily written in c/c++.
2. Take advantage of well tested 3rd party libs for portability (ie,; windowing, input, etc.). Don't use allegro.
3. A game engine or framework should be at it's core, and should be independent of Zelda-related IP or other copyrighted materials. The community can easily add a Zelda resource pack just like using a tileset in ZC.
4. Use qt for the GUI.
5. Use a fast and powerful scripting language like Lua, or C#. (Alternates have been brought up before, such as python or javascript, but are usually met with mixed results, however there's nothing stopping anyone from adding bindings to all of these later on!)


Obviously no single person is crazy enough to do this by themselves.

I'm willing to contribute one component to the project if it gets started, and maybe more as things get finished, or I finish with that. I also have a lot of things that I've done for my own project that may be able to be used without much work as well. maybe more if the core code is very similar. Maybe lots if it is compatible.

If anyone is interested in working on it then reply here and feel free to throw yer two cents into the well and make a wish.

[edit]
Side note: This isn't a "Add more combo flags to ZQuest, or add this feature to ZC" discussion. Please use the suggestion forum for that.

Samer
06-20-2015, 01:04 AM
Craziness...

OK, yeah Allegro sucks really bad so that's good.
3rd party libs, hell yeah
Third point is good too, this'll be more like a game engine
Qt 5.4 for GUI is the easiest and most flexible
C# is easy to use but difficult to integrate, but I think the majority of non programmers would like Lua more

A single person doing this is a fool, TIP. SIP has been deprecated in the industry.

It'll need a lot of people for this.

ZoriaRPG
06-20-2015, 08:01 AM
Right, so I'll reiterate some points here:

The description of this, and it scope, seems essentially identicla to Solarus. With nine-to-ten years of development already done there, if 2.xx compatibility is not considered feasible for ZC3, and because the scripting interface would also be Lua (the same as Solarus), I don't see a point in doing it all from scratch.

My proposal, is this:

<1> Take the Solarus sources.
<2> Add GUI elements, to make them easy to use, such as enemy, and item editors.
<3> Iron out some bugs in Solarus.

If you see some reason not to do this, I'll happily consider it, but what DarkDragon described is Solarus, in every respect, save one: Solarus lacks the ZQuest style editors. That is the only thing that makes it less user-friendly. That would also reduce the development overhead from ten-plus years using three to five core developers, to one to two years, with one to three core developers. I simply don;t feel that it is wise, or evem practical to start this kind of entire re-write from scratch, given that there are far more logical options.

Beyond that, with zero compatibility to 2.50 quests, renaming it with a different scheme 'Zelda Classic III', v1.0, would fully disambiguate it from any further development of the Zelda Classic 2.x engine. That meaning, with ZC open-sourced, it's possible, and even probably that there could be a v3.x based off the 2.xx sources, and then another entirely different thing (this) called ZC 3.0. it would become a confusing mess.

Naming it ZC-III, (with Roman numerals) enforces the Zelda 3 scrolling engine, and separates itfrom the identity of the present Zelda Classic. Being a wholly new product, numbering it at v1.0, with a naming difference, simply makes sense. I think there is room for both programmes, as many people who use ZC aren't interested in adopting a new format, or learning a new language. They want more features, in the tool they've been using for sixteen years. That would mean that ZC 2.xx forks, and future versions, are highly likely.

Even if you do base everything on an engine like Solarus, an API that allows the use of ZC 2.xx packages, quests, tilesets and such, could work. You could even include a ZScript compatibility API, for such projects. If ZC 2.x compatibility os not an option, I see no goo reason to avoid disambiguating the name, identity, and such. Part of what ZC is, is the identity of how it operates; so, by changing that, and with the risk of confusing, '3.0' versions co-existing, I think that would be ideal.

For the record, I'm interested in seeing this happen, but with all the resources we have for ZC 2.x, I do not believe that improvements to the 2.xx basecode should be dropped, just to support this. It will take years to start building up any reasonable library of scripts, graphics, and games; whereas we have a vast foundation of that for our present software. It's also important to note, that many of the 'core scripters' for ZC 2. are not programmers. They would not be interested in adopting another language, and would likely opt out of learning Lua, continuing to use 2.xx for many years. Therefore, your audience will be entirely different to the present userbase.

Whatever you do, making this entirely from scratch, is just a recipe for disaster.

Nightmare
06-20-2015, 07:08 PM
I think we should just do it from scratch, even if it doesn't work out. Use Solarus and ZC 2.x as examples.

But it does need to be worked from the ground up, OpenGL and DirectX would be musts.

-James

Samer
06-20-2015, 08:57 PM
I think we should just do it from scratch, even if it doesn't work out. Use Solarus and ZC 2.x as examples.

But it does need to be worked from the ground up, OpenGL and DirectX would be musts.

-James

Working from scratch would cause everyone to quit, OpenGL is the best graphics processor so far. Cross-compile and smoother. DirectX is horrible now, it's not much different than it was when I had a Windows 98. Sure the graphics look nicer but they are pretty much the same.

Gleeok
06-20-2015, 10:57 PM
@Solarus:

Good point. Using an existing project can save a lot of time and effort since you gain years worth of code. However, the down side to that is you also gain years worth of code. ;) Has anyone looked at the code yet? Are binary formats what we'd need, or do they have to be replaced? Do tilesets or tilemaps work wonky? How does scripting work, both internally and in scripts? Is it fast, or slow, or what? What problems are there with the code? What is not a problem with the code? Has it even been assessed?

To be completely honest I looked at only a few files a few years ago then stopped there because it looked like "typical c++ garbage, where everything is a string, a map, or a map strings." I don't mean any disrespect to the authors, the project itself looks great and I might even play it once it is complete.

I just took another unbiased look and it looks like I am about to rip Solarus a new one :) , but keep in mind I do think it's a cool project and I am doing this not to be a dick, but because I am looking seriously at it as something the community might be a part of.

I looked first in something low-level to see how other code gets and uses data.



namespace {

const std::map<ResourceType, std::string> resource_type_names = {
{ ResourceType::MAP, "map" },
{ ResourceType::TILESET, "tileset" },
{ ResourceType::SPRITE, "sprite" },
{ ResourceType::MUSIC, "music" },
{ ResourceType::SOUND, "sound" },
{ ResourceType::ITEM, "item" },
{ ResourceType::ENEMY, "enemy" },
{ ResourceType::ENTITY, "entity" },
{ ResourceType::LANGUAGE, "language" },
{ ResourceType::FONT, "font" }
};

Really?! This is typical c++ at it's finest. Of course this NEEDS to be a map, and it NEEDS to be dynamically allocated strings that hold a "name" that is used to lookup other things. Because efficiency is not OOP enough.



QuestResources::QuestResources() {

for (size_t i = 0 ; i < resource_type_names.size(); ++i) {
resource_maps.emplace(static_cast<ResourceType>(i), ResourceMap());
}
}

Oh of course, it's a map of resource maps...



const std::string& QuestResources::get_resource_type_name(ResourceTyp e resource_type) {
return resource_type_names.at(resource_type);
}

const std::map<ResourceType, std::string>& QuestResources::get_resource_type_names() {
return resource_type_names;
}

This is completely necessary. We don't know things that are a constant compile-time value that can't be changed...

So how do we use it?


ResourceType QuestResources::get_resource_type_by_name(
const std::string& resource_type_name
) {
int i = 0;
for (const auto& kvp: resource_type_names) {
if (kvp.second == resource_type_name) {
return kvp.first;
}
++i;
}

Debug::die(std::string("Unknown resource type: ") + resource_type_name);
return ResourceType();
}

Great. Lets do a linear look-up a value that never changes from a string that's constant, and then let's add debugging info. Hey, you forgot exception handling dood!
It's a good that we didn't just make an enum instead of using proper OOP c++.

Well I stopped here after looking in only two files: The Quest*.cpp files. This post is going to be ridiculously large if I do more than that.


A quick question: How do tiles work?
http://www.solarus-games.org/wp-content/uploads/2015/05/map-editor-1024x619.png

It looks like tilesets are just bitmaps and it doesn't really differentiate between the two. If that's the case what happens if you have a 100 tile animated tile?

I looked in Tileset.h but then holy fuck...


const std::string id; /**< id of the tileset */
std::map<std::string, std::unique_ptr<TilePattern>>
tile_patterns;


I haven't even checked the rendering at all, but it looks like it was all software rendered then switched to SDL2 but kept the same interface and soft styled drawing. I did a search of the sources and there is nothing in the way of "Batch" in any keywords. This throws up some major red flags.

My point stands: If you want to use the Solarus data and code, it might be a good idea to look seriously at the Solarus data and code and assess it from the inside out.


tl;dr - I hate c++.

Nightmare
06-20-2015, 11:58 PM
@Solarus:

Good point. Using an existing project can save a lot of time and effort since you gain years worth of code. However, the down side to that is you also gain years worth of code. ;) Has anyone looked at the code yet? Are binary formats what we'd need, or do they have to be replaced? Do tilesets or tilemaps work wonky? How does scripting work, both internally and in scripts? Is it fast, or slow, or what? What problems are there with the code? What is not a problem with the code? Has it even been assessed?

To be completely honest I looked at only a few files a few years ago then stopped there because it looked like "typical c++ garbage, where everything is a string, a map, or a map strings." I don't mean any disrespect to the authors, the project itself looks great and I might even play it once it is complete.

I just took another unbiased look and it looks like I am about to rip Solarus a new one :) , but keep in mind I do think it's a cool project and I am doing this not to be a dick, but because I am looking seriously at it as something the community might be a part of.

I looked first in something low-level to see how other code gets and uses data.



namespace {

const std::map<ResourceType, std::string> resource_type_names = {
{ ResourceType::MAP, "map" },
{ ResourceType::TILESET, "tileset" },
{ ResourceType::SPRITE, "sprite" },
{ ResourceType::MUSIC, "music" },
{ ResourceType::SOUND, "sound" },
{ ResourceType::ITEM, "item" },
{ ResourceType::ENEMY, "enemy" },
{ ResourceType::ENTITY, "entity" },
{ ResourceType::LANGUAGE, "language" },
{ ResourceType::FONT, "font" }
};

Really?! This is typical c++ at it's finest. Of course this NEEDS to be a map, and it NEEDS to be dynamically allocated strings that hold a "name" that is used to lookup other things. Because efficiency is not OOP enough.



QuestResources::QuestResources() {

for (size_t i = 0 ; i < resource_type_names.size(); ++i) {
resource_maps.emplace(static_cast<ResourceType>(i), ResourceMap());
}
}

Oh of course, it's a map of resource maps...



const std::string& QuestResources::get_resource_type_name(ResourceTyp e resource_type) {
return resource_type_names.at(resource_type);
}

const std::map<ResourceType, std::string>& QuestResources::get_resource_type_names() {
return resource_type_names;
}

This is completely necessary. We don't know things that are a constant compile-time value that can't be changed...

So how do we use it?


ResourceType QuestResources::get_resource_type_by_name(
const std::string& resource_type_name
) {
int i = 0;
for (const auto& kvp: resource_type_names) {
if (kvp.second == resource_type_name) {
return kvp.first;
}
++i;
}

Debug::die(std::string("Unknown resource type: ") + resource_type_name);
return ResourceType();
}

Great. Lets do a linear look-up a value that never changes from a string that's constant, and then let's add debugging info. Hey, you forgot exception handling dood!
It's a good that we didn't just make an enum instead of using proper OOP c++.

Well I stopped here after looking in only two files: The Quest*.cpp files. This post is going to be ridiculously large if I do more than that.


A quick question: How do tiles work?
http://www.solarus-games.org/wp-content/uploads/2015/05/map-editor-1024x619.png

It looks like tilesets are just bitmaps and it doesn't really differentiate between the two. If that's the case what happens if you have a 100 tile animated tile?

I looked in Tileset.h but then holy fuck...


const std::string id; /**< id of the tileset */
std::map<std::string, std::unique_ptr<TilePattern>>
tile_patterns;


I haven't even checked the rendering at all, but it looks like it was all software rendered then switched to SDL2 but kept the same interface and soft styled drawing. I did a search of the sources and there is nothing in the way of "Batch" in any keywords. This throws up some major red flags.

My point stands: If you want to use the Solarus data and code, it might be a good idea to look seriously at the Solarus data and code and assess it from the inside out.


tl;dr - I hate c++.

I'll get back to you on it. I'm proficient in C++.

-James

Samer
06-21-2015, 10:03 AM
C++ is usually the most balanced programming language for games.
Memory management has to be done manually though.

It's not that Java and others are bad, they just aren't really cross-compatible and they spring up memory leaks like there's no tomorrow.

Sharing this Game Design Book:
Intro to Game Development
(https://drive.google.com/open?id=0Bx5kF50gjLAvMTRiXzEzZURERmM&authuser=0)
It's pretty big, and it's graduate level but I'm sure everyone here knows what they're doing.
It's too big to preview so you have to download it.

ZoriaRPG
06-21-2015, 12:27 PM
I come from a paradigm that's so antiquated, it's laughable, so, I don;t notice these things as easily as those properly trained in C++. It's certainly something that is worth of discussing with the author (Christopho).

I got a sense from my conversations with him, that he is always happy to improve the engine, and he would likely work with you (or anyone), in the process of adaptations that streamline the engine.

I understand that you might inherit flaws, but consider that by the time you make something wholly new -- another ten years -- most of those flaws could have been fixed, and the entire programme improved upon. You also get the advantage of an extant community of coders, and users; which you would need to establish. This, coming from a man who waited nine years to start using ZC 2.5, thinking it a hopeless, dead project, for the last six of them, until RC1. I avoided developing any project under 2.50 due to instability, and perpetual internal changes, for nine years.

Does anyone remember back in 2006, when I was intensely excited about it? Then, I stopped caring, when promises of a simple compilation couldn't come through, after over a year of waiting. That's what happened with Solarus too: Nobody took it seriously, until very, very recently. Two years ago, i would have laughed at a suggestion to use it for anything, because it was too primitive. Now, it's looking more, and more practical.

I never looked at how it converts portions of graphic files into objects, but I did suggest optimisations for this to Christopho, that he wants to include at some point. Working with the dev community there, and asking questions would promote something more beneficial here; and beside that, you could be merging with a competing concept, rather then trying to compete. That means that at produce launch, you have a library of games, too. ZC 2.5 was a success, because it had a userbase, and a library of games. If it was incompatible with everything that came before it, I doubt you'd have a community for it at this point.

Compare it to releasing a new console. You can make something with every feature, and be very far--sighted in developing something cutting edge, then have no users, because you have no library of games; or because developing for it is too difficult. I can list many examples of this happening in VG history, starting with the Atari 5200, and the Vectrex, and all the way up to the Wii U.

Samer
06-21-2015, 12:38 PM
ZoriaRPG
I agree with everything you just said. Evolution doesn't mean that the things that came before it are useless.
I mean, even though the original C libraries have been deprecated, you could still use the "improved" ones for Visual C.
I know my game history as well, keeping classic and modern in sync seems to be the best approach.
To put it briefly, before the main transition to the New Gen of Zelda Classic, we need to make a cross-compiler (like CMake), to make the ZScript libraries and present quests to be compatible with the New Gen. I use CMake all the time for cross-platform development, yet ZScript and .qst are very impractical so it would take a lot of work.

I know how to make compilers using Trees and Stacks, yet, it would be very tedious and difficult.

Gleeok
06-21-2015, 07:03 PM
I understand that you might inherit flaws, but consider that by the time you make something wholly new -- another ten years -- most of those flaws could have been fixed, and the entire programme improved upon. You also get the advantage of an extant community of coders, and users; which you would need to establish. This, coming from a man who waited nine years to start using ZC 2.5, thinking it a hopeless, dead project, for the last six of them, until RC1. I avoided developing any project under 2.50 due to instability, and perpetual internal changes, for nine years.
.

I just have to point out the fact that 90% of the time it took for 2.5 to be finished was getting the new code to work with the old code, not because adding new features is hard or takes 9 years. There was so many bugs at one time that the ZC bug forums were split into many subforums.


Also, I did take a look at "TilePattern" and co. It looks like animations have to be exactly 4 frames and there is a static frame counter in there as well, meaning all animations are the same duration even though a TilePattern is virtual (More red flags.. This actually doesn't even make sense). I was also pondering, it seems, about how a "Tileset" was a Bitmap with extra tile information. I was also correct about how there is no true low level data design in the rendering pipeline: Everything is object-oriented and treated as though only one ever exists, then shipped to SDL. (Unless I just happened to miss a file or two) :/

If you talk with him maybe just ask him about that.

ctrl-alt-delete
06-21-2015, 07:21 PM
Gleeok, if you hate C++, why are we possibly programming it from scratch using C++?

Samer
06-21-2015, 09:01 PM
Well, C++ is the most cross-compatible.

C# only works on .NET platforms; Windows
Java springs up a bunch of memory leaks, plus you are required to have a JVM (Java Virtual Machine)

It's for the greater good. I can work with C# if need be.

Zim
06-22-2015, 12:23 AM
I don't know about building another version of Classic from the ground up.
http://youtu.be/N3J2PZzuA0w
Here is a video of some functions I coded for Zelda Classic.
Its just more scrolling functionality, demonstrating warp return points and the like. (Also looping world map for Epoch, [you might want to skip from 1:50-2:20] which is fully functional and cannot land on solid combos even. I am aware that the enemy death graphic is a small boy.)
My PC is a little outdated and not very powerful, so please don't hassle me about the glitches/bugs.
The overall speed and everything of the engine is just fine like this.
Since my game doesn't use one single built in combo flag or anything like that (aside from Solidity), a build of ZC with all those things factored out of it would make a great game engine.
This code I wrote could actually replicate Chrono Trigger to the T, but it plays more like Zelda and looks like Chrono Trigger due to the fact that I haven't wrote a battle engine (yet) and probably won't.

Let me know if you're interested in having this file for yourself. It does what is described that 3.0 will be able to do with 2.5. The difference being that I overwrote combo flags to get it done instead of it being hard-coded into ZC.

I will only send the file via PM per request in an effort to keep it off the database pages so people don't see it and start using it thinking there will be updates for them like its 3.0 alpha build or something.

Chris Miller
06-22-2015, 12:53 AM
Plain old C might be the way to go.

Take that with a grain of salt, as my programming abilities are rivaled by my ability to model Speedos.

Gleeok
06-22-2015, 01:38 AM
Gleeok, if you hate C++, why are we possibly programming it from scratch using C++?

lol. I guess nobody got that joke. :P

I suppose it's just something you have to just accumulate over the years of working on c++ to understand. c++ is one of the few languages that lets you do both low-level and very high-level programming, and everything in between.

Let me put it this way: Essentially c++ is like a hardware store; you can use a tractor and a chain-saw to make an end-table, or you can use a lathe and some hand tools. From the computers perspective [when I said "typical c++"] it sees programs as using bulldozers and wood-chippers. :P

So when I said I hate c++ I mean to say it's so easy to completely fuck up even something that could be considered trivial. I know this because I've done it over and over again. If anyone ever tells me otherwise I will show you someone that has either never tried to solve an actual problem with c++, or someone that who doesn't understand any problems.

tl;dr, No, c++ is fine. >_>

ctrl-alt-delete
06-22-2015, 02:31 AM
I think we should make ZC 2.whateveropensourcefinaledition. Then we should completely leave Zelda and Zelda-like engines behind focusing on FFC.

Samer
06-22-2015, 08:19 AM
I think we should make ZC 2.whateveropensourcefinaledition. Then we should completely leave Zelda and Zelda-like engines behind focusing on FFC.

I like this idea, OOP has been the mainstream since 2001. Data oriented programming is difficult for me, I could just objectify the data and that's that. Let's do FFC before Nintendo does.

ctrl-alt-delete
06-22-2015, 01:04 PM
Is starting from scratch really starting from scratch? Is ANY of the existing codebase usable?

Samer
06-22-2015, 02:25 PM
I don't think anyone with any sense would make something from scratch, unless you are extremely ambitious and never give up.

I'm not a kid anymore so if it takes too much effort I could care less.
I like ZC, which I stumbled across AGN about 2003 but never formally joined.

ZC, in earnest, is a joke of a game engine in my opinion.
It's good for beginners though who like the tediousness.

Programming is easier than scripting for me.
I only script for cross compatibility, fix some outdated applications, resource files (mainly pictures). Which are normally done in Assembly or XML. The only thing I can find scripting good for in a game engine is for AI, for which the base structure of enemy and NPC objects do not change. The only thing that changes is how they move, how they act, react. Events can be scripted as well, yet I would prefer a more real time situation. The best AI structure I have ever come across is Radiant AI which is used in Skyrim. It is so complex it is as if the NPC/Enemy is alive.

Why OOP is Important
Instead of having "Enemy" as one object, which it is insinuated, you could have a class for every enemy through inheritance. You can further increase it's capacity with encapsulation and polymorphism which are OOP basics.
Enemy Class Examples: Moblin, Goriya, Darknut, etc.
Then you can go further by making even more subclasses for specifics, and once the evolution has finnished, scripting is required.

Normally scripting is only needed for phase-out, which all patch work has ceased for a particular version (servicing/No Development/No Evolution)

Gleeok
06-23-2015, 05:04 AM
- It's not really from scratch as long as the design goals are known ahead of time. Plus there's always ZC and whatever else for reference. There's a lot of 3rd party code and libs available if you need something in particular. There's really no such thing as "from scratch" nowadays.

- ZC is the best damn LOZ1 engine on the planet Earth and don't you forget it.

- America. Fuck Yeah. ..Also prime rib and bikinis.



Why OOP is Important
Instead of having "Enemy" as one object, which it is insinuated, you could have a class for every enemy through inheritance. You can further increase it's capacity with encapsulation and polymorphism which are OOP basics.
Enemy Class Examples: Moblin, Goriya, Darknut, etc.
Then you can go further by making even more subclasses for specifics, and once the evolution has finnished, scripting is required.

Normally scripting is only needed for phase-out, which all patch work has ceased for a particular version (servicing/No Development/No Evolution)

That's exactly how ZC does the enemies.
Another approach is to use scripting so that you can have scripted enemies, since you can never add enough polymorphism in c++ to account for all enemy types that users will create themselves at runtime.

ZoriaRPG
06-24-2015, 09:08 AM
I don't know about building another version of Classic from the ground up.
http://youtu.be/N3J2PZzuA0w
Here is a video of some functions I coded for Zelda Classic.
Its just more scrolling functionality, demonstrating warp return points and the like. (Also looping world map for Epoch, [you might want to skip from 1:50-2:20] which is fully functional and cannot land on solid combos even. I am aware that the enemy death graphic is a small boy.)
My PC is a little outdated and not very powerful, so please don't hassle me about the glitches/bugs.
The overall speed and everything of the engine is just fine like this.
Since my game doesn't use one single built in combo flag or anything like that (aside from Solidity), a build of ZC with all those things factored out of it would make a great game engine.
This code I wrote could actually replicate Chrono Trigger to the T, but it plays more like Zelda and looks like Chrono Trigger due to the fact that I haven't wrote a battle engine (yet) and probably won't.

Let me know if you're interested in having this file for yourself. It does what is described that 3.0 will be able to do with 2.5. The difference being that I overwrote combo flags to get it done instead of it being hard-coded into ZC.

I will only send the file via PM per request in an effort to keep it off the database pages so people don't see it and start using it thinking there will be updates for them like its 3.0 alpha build or something.

Zim, I would not mind a recent engine pack from you. The latest one that I have is roughly two years old--unless that is the latest version. PM it to me, if you would, please.

Christopho
06-24-2015, 11:27 AM
Well that's an interesting discussion :)
(Including the programming language troll.)


To summarize, any discussion on this in the past two years has just boiled down to the following:

1. Will be open source and primarily written in c/c++.
2. Take advantage of well tested 3rd party libs for portability (ie,; windowing, input, etc.). Don't use allegro.
3. A game engine or framework should be at it's core, and should be independent of Zelda-related IP or other copyrighted materials. The community can easily add a Zelda resource pack just like using a tileset in ZC.
4. Use qt for the GUI.
5. Use a fast and powerful scripting language like Lua, or C#. (Alternates have been brought up before, such as python or javascript, but are usually met with mixed results, however there's nothing stopping anyone from adding bindings to all of these later on!)

This is actually a very accurate description of Solarus.

I don't know ZC much but I am always open to learn and share things. I am sure both teams can learn from each other.
What I know is that I have a lot of respect for what you guys do, because the ZC community is very active, and this is an amazing source of fangames! The number of ZC quests is just crazy.

Solarus is a young project. It started in 2006, that's true, but at that time it was a not a Zelda Maker at all, it was a dedicated engine for a particular game I was developing (Zelda Mytery of Solarus DX). Now, Solarus as a general Zelda-like creation tool is quite new. Before the latest release (1.4) of May 2015, there was no GUI to make dialogs or to set the properties of the quest. Each release brings new features to allow users to achieve great things more easily.

You seem to want to make things open and this is obviously going into the right direction. Since Solarus code is open-source, and only relies on open-source third parties, it can be compiled on a lot of plaforms. We officially support a lot of operating systems, but for example people are also working on a (non fully working yet) Wii port!
Keeping everything open is important. Not only the code, but we also spent a lot of time on the documentation. We try to give a very complete documentation of the scripting API. We also provide a full specification of the format of data files, so that people can develop their own tools. For example, thanks to the openness of data file formats, people developed automatically generated maps with procedural generation with Solarus.

Whatever you decide, we are here to help and your feedback is welcome. Including bug reports and even pointing out ugly parts of the code ;)

Any way, even if you decide to start from scratch, the least we should do together is to work on some conversion tools to import/export resources between ZC and Solarus.

Finally, to answer particular previous remarks:
- Don't forget about rule #1 of optimization. Which is "Don't optimize.". Premature optimization is the root of evil. About the code that finds an enum value from a name, you really want yet another map to have a faster reverse mapping? No, I will not optimize a linear traversal of constant container of 10 elements :) Unless there is a use case where profiling shows that this is a bottleneck.
- On the contrary, useful optimizations were done. Like hardware 2D acceleration (with SDL2), pre-rendering of maps (no, we don't redraw all fixed tiles at each frame!), lazy loading of tiles, clever management of obstacles… And we also use LuaJIT for great performance of scripts. The latests realeases are fastest than ever. Solarus can run on limited hardware like the GCW-Zero handheld console. Maps with thousands of tiles can load and run without problem. Actually, individual tiles don't even exist at runtime (except animated ones).
- Animated tile patterns can only have 3 frames in the current version of Solarus. Like with RPG Maker (hmm, 2000 at least). And the code that manages that is clearly terrible, let's admit it :) A funny relic of when I was a beginner in C++. Anyway, more customized tile animations is a planned feature.

Gleeok
06-25-2015, 04:56 AM
Finally, to answer particular previous remarks:

Hi Christopho. I hope you didn't take offense to anything I said. I was simply trying to make the point that you can't take a decision to start a major project so willy-nilly; in this case deciding to use an existing code base that no one bothered to look at first, or even knew in depth how it worked or what it did. Nothing against the good things that you have accomplished.

I haven't played it yet, but Solarus looks like a very cool project. I watched the video of it a few years ago. I really hope you can complete it. :)



Finally, to answer particular previous remarks:
- Don't forget about rule #1 of optimization. Which is "Don't optimize.". Premature optimization is the root of evil. About the code that finds an enum value from a name, you really want yet another map to have a faster reverse mapping? No, I will not optimize a linear traversal of constant container of 10 elements :) Unless there is a use case where profiling shows that this is a bottleneck.
- On the contrary, useful optimizations were done. Like hardware 2D acceleration (with SDL2), pre-rendering of maps (no, we don't redraw all fixed tiles at each frame!), lazy loading of tiles, clever management of obstacles… And we also use LuaJIT for great performance of scripts. .

I guess I am on the other end of the spectrum here with "Premature optimization is the root of evil". To me that is one of the dumbest things I have ever heard, right up there with "The war on drugs" and "Stop underage drinking before it starts." :P ..I wish people would stop saying that. At the very least, I guarantee you that quote originated from someone who absolutely was not a game programmer trying to run an entire simulation in 16.7 milliseconds.

The pre-rendering of maps is an interesting idea that I have never tried. This almost sounds like something in the old pre-GPU card days where bitmaps were marked with dirty flags. I believe this concept was called "dirty rectangles." Interesting. Would this also work with palette effects or color changes to individual tile layers, like a day-night system?

Christopho
06-25-2015, 06:37 AM
No offense taken :)

What I mean with "don't optimize too soon" is that there is no point in making the code more complex (in that example, adding a redundant reverse-mapping structure) to save 0.0001% of CPU time. It has no effect. I would probably accept a pull request if someone does it, but this is a waste of time for no improvement. The right approach is to keep time-insignificant code straightforward and work on optimizations where time is spent. Usually, in games, we will focus on rendering and collisions (and, if you use a scripting language other than Lua, in scripts :D Sorry, I only managed to resist in my previous post).

I made a fundamental mistake in 2006 when I started the project: I decided that all maps should be identified by an integer id for better performance. Because integers are faster than strings, right? So map files were named 1.dat, 2.dat, etc. More friendly names could be set in the project resource list file, and were displayed in the GUI of the editor, so it worked well. Except that it was completely stupid. It made life more complex for users. In scripts, when you want to teleport the player to another map, you have to write the map id, so you first need to find the integer number of the map you want. Unless you know all of them by heart. Obscure file names are also painful to manage (https://github.com/christopho/zsdx/tree/master/data/maps) in your version control system. What if two people of the team work on new maps at the same time? (I did like this because it felt natural, everything was organized with integer ids in RPG Maker. Map file names, saved variables, etc.).
Now, maps are identified by a string and can be organized in a hierarchy (https://github.com/christopho/zelda_mercuris_chest/tree/master/data/maps), for example you can name your map "water_temple/1f" and it is fast as before. As fast as before because at runtime, we don't work with map ids a lot, but only when loading a map. Parsing a map id is completely insignificant compared to loading the map content.

For the pre-rendering of maps, I only pre-render fixed tiles. Anything dynamic, like enemies or other moving entities, as well as animated tiles, and other graphics added by scripts like a day-night overlay, is redrawn normally at each cycle. Since the number of non-animated tiles is often huge in big maps, the performance gain was huge. Basically, I lazily pre-render non-animated tiles in areas that are in the camera or close to it. The algorithm is not as simple as one would think, because tiles can not only be animated, but can also have various sizes, can overlap each other and can have transparent parts. Determining what can be pre-rendered and how to recombine everything to get the correct final drawing is a bit tricky (https://github.com/christopho/solarus/blob/master/include/solarus/entities/NonAnimatedRegions.h).

Saffith
06-25-2015, 06:24 PM
At the very least, I guarantee you that quote originated from someone who absolutely was not a game programmer trying to run an entire simulation in 16.7 milliseconds.
Donald Knuth. He starting coding in the 1950s, so I'm sure he was plenty familiar with speed concerns.
The point, mind, was that optimization efforts should be narrowly focused where they're useful; trying to optimize every line of code is a waste of time.

Chris Miller
06-25-2015, 06:53 PM
So ZC should be written in ALGOL then. :3

Samer
06-25-2015, 07:48 PM
I'd only optimize when the need arises, or at least try to get most things in average case time. Best case time is infeasible.

Usually planning abstractions and such can save the hassle of optimizing later, one step at a time.

Gleeok
06-25-2015, 09:27 PM
Donald Knuth. He starting coding in the 1950s, so I'm sure he was plenty familiar with speed concerns.
The point, mind, was that optimization efforts should be narrowly focused where they're useful; trying to optimize every line of code is a waste of time.

Donald Knuth. That's right!
It's still a dumb blanket statement, since most people that haven't actually practiced optimizing will have no idea when 'premature' really is or even know what to optimize or how to optimize.

http://www.joshbarczak.com/blog/?p=580

Obviously. If you were to actually optimize every single line of code you'd end up with a lot of assembly, very little objects--only POD components and data--and little OOP, and adding even an extra byte to some struct somewhere might throw off your alignment requirement or cache usage strategy and require a rewrite so it stays 'optimized'. Not only that, but it would take so long that by the time you were done compute hardware would be better anyway and require your program to be redesigned, so it is really not useful at all. However if you ignore optimization altogether and just wait until a game is done to optimize it then it is too late--you can't actually optimize it in a meaningful way without rewriting all the parts that need it, you can only tune it or fix hotspots. That's my story and I'm sticking to it.

Anyway, the topic is rather silly anyway without a proper context. Truth be told, I very rarely optimize anything because it involves looking through the compilers generated code, and that is not very fun or productive; I'd rather not even do it at all, and 99.99% of the time I don't. However, "prematurely" optimizing through design is often easy and will likely remove the need to optimize later, unless profiling shows otherwise.

PS: Yes, this is from experience only, not some random blog post I read from 2008. My first shooter game I made in c++ would not run at 60 FPS [on my machine] no matter what I did, and it was only a single level. I spent months trying to improve it to no avail and finally just gave up on it. Not a fun experience. Years later I prototyped a similar type game--same computer, same OpenGL, same compiler--except that I was smarter and faster than before, and designed everything from scratch by reading lots of information on pretty much whatever was available online for free. Let me just skip to the end of this story now: Not only have I never hit less than 60 FPS since then, but it's not even close. Most of the time the game is just telling the OS to sleep, or waiting to vsync. Of course modern hardware is so fast nowadays that most people won't even have to go through this. They can use bloated libraries, slower languages, write bad code, and have no problems.



No offense taken :)

What I mean with "don't optimize too soon" is that there is no point in making the code more complex (in that example, adding a redundant reverse-mapping structure) to save 0.0001% of CPU time. It has no effect. I would probably accept a pull request if someone does it, but this is a waste of time for no improvement. The right approach is to keep time-insignificant code straightforward and work on optimizations where time is spent. Usually, in games, we will focus on rendering and collisions (and, if you use a scripting language other than Lua, in scripts :D Sorry, I only managed to resist in my previous post).

True. I am aware that the maps' dynamic lookup table is only ever run for getting resource data when some entity is initialized. It's probably not worth it to optimize, you are right. The point I was trying to get across was complexity and usage, not speed, ie., how complex would it be to use or modify existing code. How complex wold it be to add to...et al.

Yep. Rendering, collisions, particles, and data layout are the most important. I totally agree.

Isana
06-28-2015, 05:08 AM
Sounds pretty good to me. I'd be willing to help out.

Personally, I'd really like to work on a compiler that would compile projects/quests down to C++ or C and produce a stand alone game
that doesn't require the player to install ZC. I've done something like this in the past, albeit much smaller in scale and rather messy.
Don't get me wrong though; I'm not adverse to keeping with the current distribution model or some variation of it.
This would take quite a bit of work and planning, but at the moment I'd just like to hear some opinions on this.

More realistically, however, I'd like to suggest internationalization support. Qt makes internationalization pretty painless.
I'd be willing to provide a Japanese translation and I know someone who could provide a Korean translation as well.
I've wanted to translate ZC to Japanese for a while, but I've been waiting for the open source release.

I've been watching Solarus' development for a while now and Christopho has been working on a new quest editor with
Qt in C++. It looks really nice so far. If I remember correctly the old editor was written in Java, but don't quote me on that.
I really like Solarus' portability and in my experiences it's pretty lightweight.

This post is a lot shorter than I would like as I have a lot more I'd like to contribute to this discussion, but it's 4:00 AM
here at the time of writing and my lack of sleep just hit me like a sack of bricks haha. I'll be back later today though
so I'll just leave it at this for now.

Samer
06-28-2015, 01:46 PM
Mostly to Gleeok but could apply to everyone
Gleeok
I'm really not trying to be offensive, just spreading knowledge.

Data structures and OOP are one in the same. OOP is just organization. Here's an example program I was using myself with a team for a university project for software change requests.
https://github.com/Gr1N/EasyPaint

The implementation for classes (data structure) is still data-oriented but designed in a way to improve stability and balance, speed is important but you'd be better off writing everything in assembly if that's your main goal.

The classes used for drawing graphics and memory management can still be data-oriented, but encapsulated.

Gleeok
06-28-2015, 07:03 PM
Mostly to Gleeok but could apply to everyone
Gleeok
I'm really not trying to be offensive, just spreading knowledge.


And I'm really sorry I even brought up concerns about the performance of drawing tiles and maps in Solarus. :(

I only did so because I know how it works internally. :badrazz:

From SDL 2.03 source:


static int
GL_RenderCopy(SDL_Renderer * renderer, SDL_Texture * texture,
const SDL_Rect * srcrect, const SDL_FRect * dstrect)
{
GL_RenderData *data = (GL_RenderData *) renderer->driverdata;
GL_TextureData *texturedata = (GL_TextureData *) texture->driverdata;
GLfloat minx, miny, maxx, maxy;
GLfloat minu, maxu, minv, maxv;

GL_ActivateRenderer(renderer);

data->glEnable(texturedata->type);
if (texturedata->yuv) {
data->glActiveTextureARB(GL_TEXTURE2_ARB);
data->glBindTexture(texturedata->type, texturedata->vtexture);

data->glActiveTextureARB(GL_TEXTURE1_ARB);
data->glBindTexture(texturedata->type, texturedata->utexture);

data->glActiveTextureARB(GL_TEXTURE0_ARB);
}
data->glBindTexture(texturedata->type, texturedata->texture);

if (texture->modMode) {
GL_SetColor(data, texture->r, texture->g, texture->b, texture->a);
} else {
GL_SetColor(data, 255, 255, 255, 255);
}

GL_SetBlendMode(data, texture->blendMode);

if (texturedata->yuv) {
GL_SetShader(data, SHADER_YV12);
} else {
GL_SetShader(data, SHADER_RGB);
}

minx = dstrect->x;
miny = dstrect->y;
maxx = dstrect->x + dstrect->w;
maxy = dstrect->y + dstrect->h;

minu = (GLfloat) srcrect->x / texture->w;
minu *= texturedata->texw;
maxu = (GLfloat) (srcrect->x + srcrect->w) / texture->w;
maxu *= texturedata->texw;
minv = (GLfloat) srcrect->y / texture->h;
minv *= texturedata->texh;
maxv = (GLfloat) (srcrect->y + srcrect->h) / texture->h;
maxv *= texturedata->texh;

data->glBegin(GL_TRIANGLE_STRIP);
data->glTexCoord2f(minu, minv);
data->glVertex2f(minx, miny);
data->glTexCoord2f(maxu, minv);
data->glVertex2f(maxx, miny);
data->glTexCoord2f(minu, maxv);
data->glVertex2f(minx, maxy);
data->glTexCoord2f(maxu, maxv);
data->glVertex2f(maxx, maxy);
data->glEnd();

data->glDisable(texturedata->type);

return GL_CheckError("", renderer);
}


Can we drop it now?

Samer
06-28-2015, 10:18 PM
Consider it dropped. Your concerns are warranted so don't worry about it.

Jaydeadone
06-30-2015, 05:56 AM
C++ is usually the most balanced programming language for games.
Memory management has to be done manually though.

It's not that Java and others are bad, they just aren't really cross-compatible and they spring up memory leaks like there's no tomorrow.

Sharing this Game Design Book:
Intro to Game Development
(https://drive.google.com/open?id=0Bx5kF50gjLAvMTRiXzEzZURERmM&authuser=0)
It's pretty big, and it's graduate level but I'm sure everyone here knows what they're doing.
It's too big to preview so you have to download it.

Thank you...
I can use this.
J~

Samer
06-30-2015, 03:40 PM
Jaydeadone
No problem, it's for the good of the community. Sharing is caring and w/e.
I just wanted to put an end to useless banter.

I put that out there because ZC suffers from too many flaws.
I'm glad you could use it.:D

Jaydeadone
07-01-2015, 04:34 AM
Jaydeadone
No problem, it's for the good of the community. Sharing is caring and w/e.
I just wanted to put an end to useless banter.

I put that out there because ZC suffers from too many flaws.
I'm glad you could use it.:D

Well don't expect much contribution out of me for quite awhile...I am still in the beginner's phase of of Python and then I plan to learn C++. The memory management part of C++ kind of scares the shit out of me...

J~

Samer
07-01-2015, 02:51 PM
Jaydeadone
Don't worry about it bro. It all comes with practice.

One rule of thumb, NEVER delete pointers outside the destructor as which it will relatively always cause Heap Corruption.
I'd start with data structures first before moving to Object-Oriented. If you don't know data structures it will be really difficult, tedious, and you will give up.
I can send a link for my Data Structures & Algorithm Analysis if you want and slides to Software Engineering using the AGILE manifesto/Scrum/XP, etc.

Start with the basics, I've been there. Ambitions w/o a plan relatively always end up in failure and/or defective software.
Software development is the same as making games (quests are different, they're more like rom hacks).

Depending on how you want your memory managed there are many different ways to do it. For saving, the Doubly-Linked List (dynamically allocated) is the best one. If you need A LOT, then you'd need like an AVL Tree, or Balanced Binary Search Tree.

Start with the basics.

Jaydeadone
07-01-2015, 05:37 PM
Jaydeadone
Don't worry about it bro. It all comes with practice.


Start with the basics.

Is C++ for dummies basic enough? Lol...
My first goal is to make copies of programs, then open up the working program and tweak it and see how it reacts. Something like Fallout or Baldur's Gate comes to mind. These would be easy to mess with I think. They might have their own language mixed in though...BG uses the Infinity engine. IE: adding a weapon or enemy that doesn't exist in the original game...but this also requires that I have a concept of how the graphics work. I am certain I will frustratingly fail my first few attempts.

J~

Gleeok
07-01-2015, 11:31 PM
I would actually recommend to start with the basics of the basics. ;) Not only will you have no idea what a big game is doing, you also won't know why, or how.

What is the basics? Don't bother with any big libraries (including stl), and just use plain data such as simple structs, arrays, and pointers for everything. You won't have any memory problems if you don't allocate memory for every stupid little thing that shouldn't even of been allocated in the first place. KISS: Keep it simple stupid. Make a simple game, like breakout or asteroids. Once you understand what you are doing then you can do more complicated things and learn design patterns. I can honestly tell you that I've never once ever, ever used a BTree (ie., map),or Doubly-Linked List, in game programming. They are mostly useless. Just take a simple graphics API like SDL or allegro, and make something, anything, using only basic c++. Don't use templates.

Chris Miller
07-02-2015, 03:31 AM
http://www.codeacademy.com

This might be of help to you.

Samer
07-02-2015, 09:17 AM
Sometimes I feel like I'm going insane from all this craziness where I am, but Gleeok is right, basics of basics.

C++ for dummies in the beginning is good enough. I think codeacedemy might help you too. Sometimes craziness makes us (me) forget the struggle we had to go through.
You are doing good, practice, I have serious ADHD and I'm only 23 I just don't know how to put my age on here.

Anarchy_Balsac
07-04-2015, 02:47 AM
I think the lack of backwards compatibility sets a bad precedent, or it could...........but then the part of this being capable of making ALTTP style quests gives me an idea.

What if this WASN'T Zelda Classic 3.0, but ALTTP Classic? ALTTP's popularity was high enough to spark the development of A Link Between Worlds, and with that, comes an opportunity to reignite interest in Zelda Classic and the whole AGN. It would be easy to distinguish ALTTP Classic quests from ZC quests and separate them into different databases. And then, the old Zelda Classic could always be updated again if anyone at AGN so chooses without it seeming weird. Not to mention, it doesn't isolate itself from past custom quests, but compliments their existence by being both a different game and a different tool, which would not have happened without a long devoted fanbase of the former.

I think this idea is seriously worth considering. Plus, it may inspire someone to finally make Zelda 2 Classic......I hope anyway........

Jaydeadone
07-07-2015, 02:20 AM
I would actually recommend to start with the basics of the basics. ;) Not only will you have no idea what a big game is doing, you also won't know why, or how.

What is the basics? Don't bother with any big libraries (including stl), and just use plain data such as simple structs, arrays, and pointers for everything. You won't have any memory problems if you don't allocate memory for every stupid little thing that shouldn't even of been allocated in the first place. KISS: Keep it simple stupid. Make a simple game, like breakout or asteroids. Once you understand what you are doing then you can do more complicated things and learn design patterns. I can honestly tell you that I've never once ever, ever used a BTree (ie., map),or Doubly-Linked List, in game programming. They are mostly useless. Just take a simple graphics API like SDL or allegro, and make something, anything, using only basic c++. Don't use templates.

Thank you very much for the advice. I tend to take on projects bigger than my skills most of the time, in everything I attempt. This has both had positive and negative results. (However, it usually ends up with my frustrated to the point of taking a hiatus). I'll try to program a couple of your recommendations and move from there.
Thanks again for the Advice,
J~


Chris Miller
http://www.codeacademy.com

This might be of help to you.

Thanks Chris, I'll check this out.


Samer
Sometimes I feel like I'm going insane from all this craziness where I am, but @Gleeok is right, basics of basics.

C++ for dummies in the beginning is good enough. I think codeacedemy might help you too. Sometimes craziness makes us (me) forget the struggle we had to go through.
You are doing good, practice, I have serious ADHD and I'm only 23 I just don't know how to put my age on here.

Thanks for the vote of confidence Samer and I totally know how you feel with the ADHD...I am pretty sure I managed to slip through school wearing a good mask to keep from being medicated. In my adult life I have somewhat managed to get a hold on my randomness in tasks and have been learning to prioritize like normal people do. It's not always easy though.
Thanks again for all your patience and help.
J~

Valientlink
07-13-2015, 02:43 PM
Jeez, 2.5 is still way too much for me to handle/comprehend lol.

Joe_Cracker
10-09-2015, 04:58 AM
ALTTP Classic sounds like a good title, yet 2.5 quests should either have a dedicated 3.0 zelda-w.exe for playback plus it's own zquest.exe because some of us are only just beginning to learn what 2.5 can do plus some of us have been using it for years now.

Tamamo
10-11-2015, 06:19 PM
If we don't include the default graphics we might as well make 32x32 the default tile size and 20x15 tiles with anti-aliasing for a change since we are probably going to be using 24 bit real color.
You might say this is madness. Note that Zelda Classic's color depth is hardcoded at 8-bit (256 colors 16 of which are system reserves). The palette system is stupid and archaic and most programmers use shaders now a days.

tl;dr it's not 1986 we need to update the graphics mode.

Majora
10-11-2015, 06:36 PM
My two cents:

efficient, efficient, efficient!

Wherever possible make things more efficient. One thing that annoys me is the ever-increasing bloat of software. RAM usage can be whatever it needs to be, but processing power required should be as low as feasible. Especially considering this will be a 2D thing.

Personally i have an affinity for netbook. I prefer them vastly over touchscreen-based devices (which are garbage). If ZC 3.0 can run at 60FPS no matter what (barring maybe having a metric shit ton of sprites/effects/whatever) on screen at once of an amount that is abnormal) on say, a CPU that is 1.5 GHz dual-core (which I know doesn't mean a lot as 1.5 GHz varies in power depending on what CPU model you're dealing with) then it will be perfect.

To that end: MULTI-THREADING.

Please please PLEASE, if it's reasonably possible/feasible to do so, grant ZC 3 the ability to use as many cores as are available, as necessary. I assume ZC 3 will be hardware-accelerated so CPU power becomes less of an issue, but still.

So yeah that's about it from me. My thing is efficiency. If this was the year 2115 then I want ZC 3 to still be playable on an Intel N2600 (CPU model).

SChase123
01-22-2016, 08:00 PM
If ZC 3 is in the works right now, I'd love to Beta test it!

Tamamo
01-31-2016, 10:56 AM
This has been brought up an inordinate amount recently and based that it might be time to take it seriously. Here are a few resources from past discussions and proposals:

Recent thread (Very recent, only a few weeks old) :
http://armageddongames.net/showthread.php?96959-ZC-3-0-From-Scratch-Plan

Old DarkDragon post that was previously hidden from public view:



To summarize, any discussion on this in the past two years has just boiled down to the following:

1. Will be open source and primarily written in c/c++.
2. Take advantage of well tested 3rd party libs for portability (ie,; windowing, input, etc.). Don't use allegro.
3. A game engine or framework should be at it's core, and should be independent of Zelda-related IP or other copyrighted materials. The community can easily add a Zelda resource pack just like using a tileset in ZC.
4. Use qt for the GUI.
5. Use a fast and powerful scripting language like Lua, or C#. (Alternates have been brought up before, such as python or javascript, but are usually met with mixed results, however there's nothing stopping anyone from adding bindings to all of these later on!)


Obviously no single person is crazy enough to do this by themselves.

I'm willing to contribute one component to the project if it gets started, and maybe more as things get finished, or I finish with that. I also have a lot of things that I've done for my own project that may be able to be used without much work as well. maybe more if the core code is very similar. Maybe lots if it is compatible.

If anyone is interested in working on it then reply here and feel free to throw yer two cents into the well and make a wish.

[edit]
Side note: This isn't a "Add more combo flags to ZQuest, or add this feature to ZC" discussion. Please use the suggestion forum for that.

Since plans have changed since then, is this really needed here, it might confuse some people.