User Tag List

Page 1 of 5 1 2 3 ... LastLast
Results 1 to 10 of 49

Thread: Next Gen ZC. (Otherwise known as ZC3.0)

  1. #1
    The Time-Loop Continues ZC Developer
    Gleeok's Avatar
    Join Date
    Apr 2007
    Posts
    4,815
    Mentioned
    259 Post(s)
    Tagged
    10 Thread(s)
    vBActivity - Stats
    Points
    12,933
    Level
    33
    vBActivity - Bars
    Lv. Percent
    23.44%

    Next Gen ZC. (Otherwise known as ZC3.0)

    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/showthrea...m-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.
    Last edited by Gleeok; 06-20-2015 at 01:10 AM.
    This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.

  2. #2
    Keese Samer's Avatar
    Join Date
    Jan 2015
    Location
    Detroit, MI
    Age
    32
    Posts
    66
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    512
    Level
    8
    vBActivity - Bars
    Lv. Percent
    12.42%
    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.

  3. #3
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,760
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.7%
    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.

  4. #4
    Wizrobe Nightmare's Avatar
    Join Date
    Mar 2000
    Age
    44
    Posts
    2,523
    Mentioned
    40 Post(s)
    Tagged
    3 Thread(s)
    vBActivity - Stats
    Points
    3,840
    Level
    19
    vBActivity - Bars
    Lv. Percent
    75.69%
    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

    Facebook: http://www.facebook.com/nightmarejames YouTube: http://www.youtube.com/nightmarejames

    Game Projects
    Zelda Classic:
    Completed: Zelda NES Remastered, Demo 1st Quest, Demo 2nd Quest, James Quest: Remastered (V 2.1), Memorial Quest, New Quest 2 2015. New Quest: Rebuilt
    In development: Demo SP, James Quest: Remastered (V 3.0)t, 6QI

  5. #5
    Keese Samer's Avatar
    Join Date
    Jan 2015
    Location
    Detroit, MI
    Age
    32
    Posts
    66
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    512
    Level
    8
    vBActivity - Bars
    Lv. Percent
    12.42%
    Quote Originally Posted by Nightmare View Post
    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.

  6. #6
    The Time-Loop Continues ZC Developer
    Gleeok's Avatar
    Join Date
    Apr 2007
    Posts
    4,815
    Mentioned
    259 Post(s)
    Tagged
    10 Thread(s)
    vBActivity - Stats
    Points
    12,933
    Level
    33
    vBActivity - Bars
    Lv. Percent
    23.44%
    @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.

    Code:
    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.

    Code:
    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...

    Code:
    const std::string& QuestResources::get_resource_type_name(ResourceType 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?
    Code:
    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-cont...r-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...
    Code:
    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++.
    This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.

  7. #7
    Wizrobe Nightmare's Avatar
    Join Date
    Mar 2000
    Age
    44
    Posts
    2,523
    Mentioned
    40 Post(s)
    Tagged
    3 Thread(s)
    vBActivity - Stats
    Points
    3,840
    Level
    19
    vBActivity - Bars
    Lv. Percent
    75.69%
    Quote Originally Posted by Gleeok View Post
    @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.

    Code:
    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.

    Code:
    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...

    Code:
    const std::string& QuestResources::get_resource_type_name(ResourceType 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?
    Code:
    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-cont...r-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...
    Code:
    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

    Facebook: http://www.facebook.com/nightmarejames YouTube: http://www.youtube.com/nightmarejames

    Game Projects
    Zelda Classic:
    Completed: Zelda NES Remastered, Demo 1st Quest, Demo 2nd Quest, James Quest: Remastered (V 2.1), Memorial Quest, New Quest 2 2015. New Quest: Rebuilt
    In development: Demo SP, James Quest: Remastered (V 3.0)t, 6QI

  8. #8
    Keese Samer's Avatar
    Join Date
    Jan 2015
    Location
    Detroit, MI
    Age
    32
    Posts
    66
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    512
    Level
    8
    vBActivity - Bars
    Lv. Percent
    12.42%
    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

    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.
    Last edited by Samer; 06-21-2015 at 10:10 AM.

  9. #9
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,760
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.7%
    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.

  10. #10
    Keese Samer's Avatar
    Join Date
    Jan 2015
    Location
    Detroit, MI
    Age
    32
    Posts
    66
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    512
    Level
    8
    vBActivity - Bars
    Lv. Percent
    12.42%
    @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.
    Last edited by Samer; 06-21-2015 at 12:39 PM. Reason: Spelling

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
About us
Armageddon Games is a game development group founded in 1997. We are extremely passionate about our work and our inspirations are mostly drawn from games of the 8-bit and 16-bit era.
Social