411 replies to this topic

[Christian]

Eh, I haven't heard anyone promise anything, just a lot of talking. It's good to get some feedback from these discussions, good or bad, especially considering the frequency of topics about 2.5, 3.0, re-writing, when's it gonna be done, etc. have been popping up lately. The only thing resembling a promise I made is that I'd volunteer to be the OpenGL guy since I have experience with that and it would give me some motivation to finish the rendering library I started way back so I could perhaps put it up on sourceforge or make a game with it ..or something, I don't remember promising though. ..ho-hum.
Personally, I'd like to see it with 32-bit color and a proper alpha channel myself. The ability to almost instantly rip entire sprite-sheets from a snes or playstation game alike without having to spend hours recoloring or dicking around with a palette would just be too cool for school. I sort of feel sorry for you guys that have only worked with 8-bit graphics. Eye candy is so easy.

Only reason i said that was because we've had numerous of discussions like this either here or at AGN and nothing happens. If everything spoken here comes to realization, then you can count on me for help. I'll be glad to help a program that i love and hate but love it at the same time.

Also yes. Need moar peeples.

[Gleeok]

Only reason i said that was because we've had numerous of discussions like this either here or at AGN and nothing happens. If everything spoken here comes to realization, then you can count on me for help. I'll be glad to help a program that i love and hate but love it at the same time.

Probably because of the curse of 2.5. :\ ... Everybody would like to see that get finished (including myself). It's a really cool program, but sometimes I think intervention from a divine binary God is the only way it will be bug free... Or magic. Wait...Magic exists right? ..Quick, Someone teach me a LV3 refactor, and LV4 compile spell.

Edited by Gleeok, 24 June 2010 - 02:21 AM.

[Radien]

I am currently working towards a second bachelor's degree, this time in Computer Science. I would be happy to help out with a Zelda Classic-related project once I have some skills worth sharing. This may take another couple of years, but once I am at that point, you'll hear from me if you're still working towards developing something real. If not, I'll just apply for the original ZC developer team.

[Hoten]

Could someone relay to me the general consensus on what languages/format this will be in?

[Koopa]

As far as I can tell,

Language: Almost definitely C++.
Graphics/Sound/Keyboard interface: Probably SDL, though other options have been mentioned. Allegro (what the existing ZC uses) is not among the top contenders.
Platforms: Most likely Windows, Linux and OS X.
Scripting language: Still open. The two main language families under consideration are C-style and Python-style.

Another point of note; remember when ZC was featured on what used to be TechTV? They liked the program because it was simple. You could download the program and in a matter of minutes you could start building a game; in other words, it had a shallow learning curve. Now you could make the claim that ZC 2.5 is actually quite intimidating, with so many features and scripting. This is something that should be avoided. That doesn't mean that scripting shouldn't be part of the new program, but you should be able to do a lot of stuff without it. There have already been some good ideas in this thread about what to do with that so I'm not going to repeat them.

But I am going to repeat this. QFT.

I'm rathe busy until the end of the summer myself but if things go well, as I hinted at before, I could well imagine starting or helping with something in the late autumn.

I imagine the "getting off the ground" part will require the most concentrated effort and really needs someone or several people that can devote a week of holiday to it in one go, but once the foundations are laid progress could well be rapid. I know this is the latest in a long line of threads but I have a hunch we're on to something here. It's whetted my appetite again in any case.

[Hoten]

I started the painful process of learning C++ a week or so ago, and so if that continues to go well, I would love to lend a hand in getting this thing off the ground.

[lucas92]

I would rather use SFML than SDL. Everything is already made and it uses OpenGL.

C++ all the way though, there are so many tools at hand. I'm not quite sure if Python is adapted for fast calculations at all, and a game engine requires lot of speed.

I would definitely help programming that engine if it ever takes life, only needs some kind of lead programmer to check out what I'm doing is right, improvements in the code etc.


EDIT- btw, are you going to use a GUI library? GTK+? WxWidgets? Qt?

Edited by lucas92, 24 June 2010 - 03:29 PM.

[Majora]

Imagine ZC 1.00. Bug-free 101%, then scripting thrown in with python. Palette limitations out the window, as well as any other limitations present. I agree that limits inspire creativity, but sometimes ZC feels like it's forcing you to be imaginative on how to build an airplane out of two sticks and a paperclip. MacGyver would **** himself.

[Lemon]

What are the limitations anyway (besides the numerical ones like tile amount/dmap amount, though really no one could possibly run into those)? I don't think I've had an idea yet that couldn't be done through perseverance/time.

[lucas92]

• No Z3 scrolling
• No way to modify the hard-coded npcs
• No way to modify the player's speed
• The scripting language doesn't offer enough flexibility, there should some kind of classes or structures.
• The allegro GUI is not good, for me it causes graphical glitches.
• The small screen size

I guess there are more.

Edited by lucas92, 24 June 2010 - 06:10 PM.

[Majora]

IMHO, you should be able to make things whole "objects" instead of piecing together up to hundreds of tiles for some things. Perhaps farfetched/a pipe dream but it'd be awesome to import something like a GIF (and have it keep its own palette) and edit its solidity "live", i.e. on the game screen it's on.

[Gleeok]

It's true, zc has a whole lot of limitations. However, it was designed to ONLY make LOZ1 games and it does that *really* well. What comes with that is having to use LOZ1 style menus, maps, save-screen, resolution, enemies, items, game-mechanics, quirks, bugs, and everything related to that. But it does it well. In fact, it does it so well that it is pretty pointless to make another one (Z1 engine that is). Just my humble opinion.

Here's my question though: What makes zc so easy to use? Is it the combo flags? -I doubt it, since event systems might be just as simple. The DMap Map relationship is sort of weird and the message string interface is kind of clunky. Guys and guy rooms in lieu of a sprite or combo type that does the same thing is a little odd also. God only knows how the sub-screen editor works. =P ..So it seems to me what's left is
1) The GUI itself. As much as I hate Allegro GUI I have to say that the ZQuest GUI *just works*. Everything is easily accessible and laid out in front of you in a way that's easy to understand. Menus are simple, and menu functions have intuitive shortcuts. This leads me to believe that the newer features such as scripting, ffc combos, sub-screen editor *gulp* are only more complicated than what they really should be because of the interface to them. In fact, the script editor doesn't even have a proper interface. and
2) Map-Making. Drawing play-ablescreens that is. This is the heart of the editor I thinks, and the only other GUI that did this as simply as zc (that I've seen anyway) is probably rpg maker. Making dungeons is hours of fun for the whole family!

This is what I came up with anyway. Maybe I have overlooked something.


..This also brings up another question: Why does it take years for people to create a quest using zc when it is so easy to use? ("Scripting" is not a valid excuse here since this applies to 1.92 and 2.10 as well as 2.5.) Honestly, I'd like to know.

[Lemon]

• No Z3 scrolling
• No way to modify the hard-coded npcs
• No way to modify the player's speed
• The scripting language doesn't offer enough flexibility, there should some kind of classes or structures.
• The allegro GUI is not good, for me it causes graphical glitches.
• The small screen size

I guess there are more.

Only really Z3 scrolling seems like a big deal to me, and that would be nice simply because it would mean I wouldn't have to design screens around not having any unwalkables not matchup. Mock NPC's seem fine to me (invincible enemies or just combos), and the last three I've never had any experience with.

Gleelok's Question about what makes Zc easy:

After you nail down the basics and quirks (need a guy to have a string work, how to edit combos, what the items do and how they relate to combos) the entire program becomes very much a draw and play. You paint the screens with graphic, and then spend a little bit of time setting up flags, and boom, you can play it. If you dislike the graphic you have, you can grab some from a wonderful variety of graphic pack, or even draw your own through a very simple editor.

I guess it's simple because it's as complicated as you want to make it; and at the most basic level, it's just painting with Zc graphic.

[Koopa]

I slightly question the advantage of using OpenGL for a 2D spriting game. It's not like we're going to remake Twilight Princess. You can get good enough performance on today's computers without it, and it's probably not going to make development easier.

For the editor, I'd personally say wxWidgets. But like with ZC, the editor may come some time after the player.

[Hoten]

Gleeok, I think the complaints on the Allegro GUI aren't on the layout itself. It's been awhile since I've opened ZC, but I recall annoying bugs such as flickering. I believe that is the result of using Allegro.

OpenGl is a good choice because of it's multi-OS capabilities. Right?