411 replies to this topic

[Gleeok]

If I'm not mistaken you just described a 3D perspective "Camera.Move()" function. (Correct me if I'm wrong.)

...
As for maps and such, I think the flag system needs to be retooled and revamped. There's gotta be a better way to deal with triggers and secrets. The current system is just too limited. 16 secret combos (per layer) just doesn't do the justice sometimes and 2 flags per combo just isn't enough.
...

Something like an event system found in RPG's? (Like rpg maker for instance)



All talk about scripting and secret combos aside, and speculating on the specifics of turning lead into gold; How about a GUI? who's going to make that, and what are the GUI guys going to use to do it? There's lot's of game engines with scripting languages out there but the only way it's going to be useful for Joe Shmoe is if there is a decent interface to it. I don't think a ratio regarding development time of GUI to Engine being around 4 to 1 would be a stretch by any means. ..In fact I suspect we might even have a pac-man or breakout clone before a GUI is even half done. (well I get bored sometimes.. >_> ..I assume the people that volunteer to test the scripting engine do too. lol)


No seriously. A gui is a big project. What ideas for this do people have?

[lucas92]

Remember : the gui is what make Zelda Classic easy to use.

There should be at least map pages and sprites pages.

I've thought about this: we should script the whole game, and the GUI should modify some things in the script. For example, the "enemy editor". You should have full control on what script is it assigned to and you should have a choice of 1 sprite sheet. I'm not quite sure if this is an easy task to program but I'll propose it: the enemy editor will be able to read the public variables of the enemy (object) and we should be able to modify these via the GUI. A little bit like the ffc editor but I would like to see the names of the variables instead of D0, D1, D2...

This is pure speculation, because I think we should get a Zelda game done before trying to create a GUI.

[Beefster]

We'll probably use wxWidgets for the GUI engine. I'm up for helping to design the GUI.

I imagine the GUI should look similar to the current large mode plus a good toolbar with shortcut buttons. I like my three combo panels- that's a good feature to keep. Perhaps move the map tabs up to the top and the layer interface over to the left side. They'll both be able to have arbitrary numbers of layers/tabs.

The event/entity system should be somewhat similar to RPG Maker's, but easier to use. A proper event/entity system will replace FFCs, guys, shops, warp combos, most flags, and room types, all requiring no real programming. There will be a script section for each entity, however you will easily be able to insert "snippets" and view it as either the laymen's way or in pure code.

Secret combos will be stored as replacement tables and you can have any amount of secret replacements which can all independently (or in series) be triggered by various events- and all can independently be made permanent. If multiple secrets are permanently active, it will apply the secrets in order. In the editor, it will give let you add comboes to the screen- the active layer will be desaturated- except for the secret comboes.

[Bourkification]

My most recent thoughts can be read in the wave Wolfman2000 created here: https://wave.google....com/w fVPHYsqXA

[lucas92]

Great tool Google Wave! It's a bit laggy on my computer, but it works fine.

[lonegraywolf]

Just to clarify, the Wave is meant to compliment the forum here while also allowing creativity with the widgets and extensions that can't easily be added here. In particular, look into expanding the UML diagram on the ProcessWave.org extension. We can accomplish most of our documentation/organization right there.

[lucas92]

How about supporting different displays? For example, a user that doesn't have an openGl driver will see a SDL video display instead.

[Beefster]

I can't imagine why you wouldn't have an OpenGL driver. Even Windows comes equipped with an OpenGL->DirectX translator. OpenGL is already cross-platform.

When rendering screens, it will probably be important to prerender each layer to a hardware surface. Why? Performance. OpenGL renders faster when there's less shapes to render- regardless of their size. (It's actually a texture...)

[Koopa]

Probably not an easy feat to get to Lua or C# speed.

ASM FTW.

Additionally, there's also many more people that might already be familiar with C C++ C# or Java (or ZScript), in which the typededness is basically the same. ..err, is that a word?

It is, but it's spelt "syntax".

Beside the syntax, there's also something that could be called "expressiveness". I'm currently working with the groovy language and while it's mostly based on the syntax of C++/Java, compared to Java some things are a whole lot easier. (An example might be that a language with the word "computer" is more expressive than one where you have to say "box that has buttons and cables and makes a noise"). Even within the same syntax languages can be better or worse for certain tasks. For us, expressive could mean that things people often want to do like "move Link" or "change a tile" are coded into the language as functions.

I've been away a few days and the activity here is incredible. Yes, we're definitely on to something.

Here's another suggestion of mine just randomly thrown in. It was mentioned that the flag system needs a revamp but also that its ease of use (compared to scripting) is a strong point.

A possible middle way is with an event system. An event consists basically of a condition like "bush at coordinates (3, 5) burned" and an action like "replace bush by stairs". What I liked about the existing system was its point-and-click approach. I could imagine an event builder where you first click on a tile on the screen, then select a weapon or similar condition like "burned" or "walked on", then you can set one or more actions that could include clicking a tile - the same or a different one - and selecting another tile to replace it with.

Possibly a menu item could highlight all tiles on the screen that have conditions or actions attached to them much like "F" currently shows where flags are set. Features like this are what can make an editor so much easier to use. Maybe we could even have some kind of graph showing how the actions relate, but that's if we have development time to spare.

We could do away with the 16 per screen limitaiton, include chaining actions (the equivalent of putting flags on secret combos - one action that is only active after another one has completed) and introduce the ability for a screen to have several actions in parallel, so on the same screen you could burn bush 1 to get stairs 2 or hit pole 3 to get passage 4 open (in any order) and so on.

[lucas92]

How is it going to store quest files? XML files?

[Koh]

Sounds just like RPG Maker's system, which to me, is extremely easy to use, and requires little to no effort.

[Gleeok]

I know all windows versions have OpenGL 1.1 software rendering support built-in, I assume it's the same with other OS's. If we are worried about supporting most configurations, like 10-year old comp, no gfx card or something similar, then we can simply target the OpenGL 1.1 specification and fall back on that by default. Hardware support for higher implementations is easily obtainable through a few queries.


@Koopa: Here's an idea (Hope it's not too crazy =P) How about condensing all secret combos, combo flags, tiered secrets into one system, like screen events? You can name screen events anything you want (just a std::string after all) and the difference between temperary and permanent is just one bit. So for example, say an event #1 "hit switch" is true; everything that checks for event1 would be activated. -Lets say a bridge appears and a door closes. Now on the other side of the bridge there is another switch. Instead of adding a separate event for that if you don't want, you can just have each switch toggle event1, so now the door reopens and the bridge disappears when event1 is false. Everything can be automatically tiered by default ..Just an idea.
- [edit] Also this might be nice also: For scripting you can have something like;

CODE

if( screen.event(1) is true) // do stuff

instead of the horrible horrible way of

CODE

if( Screen->ComboD[ComboAT(somethingX,somethingY)] == someData ) //...or how you have to write different code to check each separate little thing.

Even someone with no scripting skills can manage to write a few lines of script like that. Could even overload it:

CODE

if( screen.event("hit switch") is true) // do stuff

Edited by Gleeok, 29 June 2010 - 05:05 PM.

[lucas92]

I've made some class for the ressource manager, which will holds the images, scripts, musics, etc.

CODE

template <typename S>
class RessourceManager
{
    public:
        virtual void Load(std::string filename, std::string assetName);
        S Get(std::string assetName)
        {
            try
            {
                if(m_data[assetName] != NULL)
                    return m_data[assetName];
                else
                    throw std::string("Could not load " + assetName);
            }
            catch(const std::string& str)
            {
                std::cerr<<str<<std::endl;
            }
        }
    private:
        std::map<std::string,S> m_data;
};

ImageManager, SoundManager, etc should herit of this class. Point out if there's any error with my code.

[lonegraywolf]

lucas92: Just make sure people know to put that in the header files and not the cpp files, and you've got error free code.

As far as using it...I'm guessing I'm not quite sure of the point of this class.

[Bourkification]

I know all windows versions have OpenGL 1.1 software rendering support built-in, I assume it's the same with other OS's. If we are worried about supporting most configurations, like 10-year old comp, no gfx card or something similar, then we can simply target the OpenGL 1.1 specification and fall back on that by default. Hardware support for higher implementations is easily obtainable through a few queries.

Well, I'd say thats the graphics engine chosen then!

I would suggest WxWidgets for the GUI toolkit, mainly because it has a native interface and needs minimal changes to the code to work on different platforms. It is also supported on Windows Mobile and the iPhone.... Hmmm wouldn't ZC on an iPad be great.

@Koopa: Here's an idea (Hope it's not too crazy =P) How about condensing all secret combos, combo flags, tiered secrets into one system, like screen events? You can name screen events anything you want (just a std::string after all) and the difference between temperary and permanent is just one bit. So for example, say an event #1 "hit switch" is true; everything that checks for event1 would be activated. -Lets say a bridge appears and a door closes. Now on the other side of the bridge there is another switch. Instead of adding a separate event for that if you don't want, you can just have each switch toggle event1, so now the door reopens and the bridge disappears when event1 is false. Everything can be automatically tiered by default ..Just an idea.
- [edit] Also this might be nice also: For scripting you can have something like;

CODE

if( screen.event(1) is true) // do stuff

instead of the horrible horrible way of

CODE

if( Screen->ComboD[ComboAT(somethingX,somethingY)] == someData ) //...or how you have to write different code to check each separate little thing.

Even someone with no scripting skills can manage to write a few lines of script like that. Could even overload it:

CODE

if( screen.event("hit switch") is true) // do stuff

Yeah but if you go with a system like that it is still hard for Newbs to pick up as well as younger people. Because let's face it, most of us started using ZC when we were 10 or 12. However if you could incorporate that into an easier to use interface then I'm all for it.