411 replies to this topic

[Lemon]

I suggest taking Zelda out of the name entirely, as this would allow us to stray away from any copyright infringement...just in case Nintendo ever decides they don't like us anymore.

Something as simple as "Pure" could work.

Nintendo knows about Zelda Classic and are alright with it. As long as it's non-profit, they aren't going to complain.

Zelda Classic is really the perfect name for this engine though. It completely describes what the program is; a thing to play Classic Zelda, or make your own Classic Zelda games.

Surely someone has to know a way to contact Phantom Menace. Just ask his permission to make Zelda Classic 2, or just keep the main program named Zelda Classic and name the various releases. Before we jump on the wagon of assuming he wouldn't like it if you made a new engine with the name, ask the guy.

[Yapollo]

I think we should create a new name, but using "Zelda Classic" as PART of the name could (and most likely will) work. But I think that if we through all the hard work to make a new Zelda maker, we should create a name specially taliored to PureZC's uniqueness (for we are not AGN).

[Geoffrey]

Nintendo knows about Zelda Classic and are alright with it. As long as it's non-profit, they aren't going to complain.
I know, I was just saying if they ever decided they didn't like it.

Zelda Classic is really the perfect name for this engine though. It completely describes what the program is; a thing to play Classic Zelda, or make your own Classic Zelda games.
For how it is now, yes. But for what is being described here, I have to disagree with you.

[Cameron]

So is this going to get started? I would love to help, but I am only just now learning the basics of C++ and therefore would be no help. Maybe someone could start getting a list of volunteers if we are really serious about doing this.

[Yapollo]

I am trying to learn C ++, but I can't say when I will know enough, I update my progress later.

I'd love to help otherwise.

[lucas92]

I know the basics of C++ but I don't know how to start out a huge project as this. :S

[Bourkification]

Phantom Menace, aka Jeremy Craner has a website that he hasn't updated since 2007, but does have an email account which he may still use. The email can be found right at the bottom of the page, it's worth a shot I guess.

Oh, and if this new program is developed, what will the format be for quests? Will they still be .qst, and have to be played in a separate program, or will they be exportable to .exe, .dmg, and linux formats? Does this mean that quests being made in 2.5 will have to be started from scratch? Or will a converter be made available so that 2.5 quests can be transferred?

Edited by Jimmyb, 17 June 2010 - 01:22 AM.

[Koh]

Woah, slow down JimmyB, we haven't even STARTED it yet XD. Let's just see if we are able to make a basic player with nothing but a movable Link first. Start small, then build on it.

[Bourkification]

But if you don't plan for the future and things exactly like that now, then the program will turn out exactly like Zelda Classic has. Developers need to keep room for improvement and expansion.

The question was asked because if there will be no use of the .qst file and no backwards compatibility with 2.5, then the program may as well be a different thing to ZC altogether, therefore severing all ties ZC which is seemingly what is going to happen sooner or later.

[Koopa]

C++, hands down. We'll probably use SDL for the game engine and wxWidgets for the GUI.

I'm thinking C++ with the TR1/Boost extensions is worth consideration. It sounds good and looks easier to develop with in some cases, but I have no experience with it yet. I'm also not 100% sure about compatibility with SDL. Wx for the editor sounds like a good option too, I've used it before and am very satisfied.

C++ as a basis and SDL for the graphics/sound/interface (player) are really the only sensible option.

One matter we'll need to consider is how we'll do password protection with an open source engine. I'd say password-encrypt it, but then you'd need the password to play the game...

Do we need this at all? If we're going to open-source it, we might as well have an open game and quest format too and we've got one less thing to worry about when developing. Passwords are part of ZC we can afford to leave behind, they're not a requirement for the new project.

Will they still be .qst, and have to be played in a separate program, or will they be exportable to .exe, .dmg, and linux formats? Does this mean that quests being made in 2.5 will have to be started from scratch? Or will a converter be made available so that 2.5 quests can be transferred?

The qst format is a part of ZC. We wouldn't be taking any of ZC's source code or files for legal reasons - or bugs, for that matter. It'd be a start from scratch. Compatibility with ZC quests is simply not realistic, and compatibility with the past is kind of limitation that is plaguing the current ZC development and hence the one thing we should avoid at all costs.
The separation between player and editor makes sense because we can have a proper windows interface for the editor. For windows, it's likely to be one or more .exe files along with some data files whereas for linux I could envisage a .deb package or similar.

[Moo2wo]

The qst format is a part of ZC. We wouldn't be taking any of ZC's source code or files for legal reasons - or bugs, for that matter. It'd be a start from scratch. Compatibility with ZC quests is simply not realistic, and compatibility with the past is kind of limitation that is plaguing the current ZC development and hence the one thing we should avoid at all costs.
The separation between player and editor makes sense because we can have a proper windows interface for the editor. For windows, it's likely to be one or more .exe files along with some data files whereas for linux I could envisage a .deb package or similar.

Besides, by the time we'd finish making an editor, most of the quests currently being made will be done. If it takes as long as I think it will, that is.

[lucas92]

SFML is better in my opinion. Faster and uses hardware acceleration instead of Software acceleration.

http://www.sfml-dev.org/index.php

[Beefster]

Why do we need the word "Zelda" in the name? We should use Zelda related names instead. Things like "Power Slash" or "Great Spin" or even something like "Hookshot" or "Hover Boots".

[Gleeok]

If there is going to be a "which Multimedia-Library is best" debate then let me just help you guys out and answer; None of them. =p They just do things differently -each does some things better than others, and usually you only need parts of the API as some add-ons aren't enough (or too much) for what you need.

I'd be willing to volunteer to handle the graphics, OpenGL, and hardware acceleration rendering aspects of the game (I've actually been meaning to finish my OpenGL rendering and math library I was working on), which would be much faster (especially on newer gfx cards) than SFML, SDL, etc. ..In fact I'd be interested in doing a benchmark comparison between something like SMFL (Is that considered fast..?) to see exactly how much faster it is. (Not to mention how limited you are by other API's)

This would work out fine for me since I don't have very much spare time right now to work on other issues like GUI, engine design, scripting, or any other major components that are mostly time-consuming, sorry this is the best I can offer right now -I haven't even been able to do much with 2.5 lately . ..Also this would simplify the task of picking a suitable library at least, since the hardware/software acceleration concerns would be a non-factor.

[Koopa]

As far as time goes, I'm pretty much booked out until September but if the Powers that Be are well-inclined towards me, things will be a lot better from the Autumn on. I'd be interested in contributing wherever I could.

SFML I don't know too well (not that that's a problem) but it looks interesting at first glance. Whatever libraries we choose, it may be a good idea to spend a day making a mini-demo that uses all libraries we're envisaging and then let everyone test it and report on compatibility - windows XP, Vista, 7, mac, linux and so on. That way we'll see if there's a potential problem early on.