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

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

Quote:

---

Originally Posted by Samer

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.

Quote:

---

Originally Posted by Zim

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.

Well that's an interesting discussion :)
(Including the programming language troll.)

Quote:

---

Originally Posted by Gleeok

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.

Quote:

---

Originally Posted by Christopho

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

Quote:

---

Originally Posted by Christopho

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?

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

Quote:

---

Originally Posted by Gleeok

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.

So ZC should be written in ALGOL then. :3

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.

Quote:

---

Originally Posted by Saffith

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.

Quote:

---

Originally Posted by Christopho

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.

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.