411 replies to this topic

[Christian]

It's nice to see Gleeok is putting some sort of effort into making this. I wonder why the other developers haven't posted here. Like Joe123 for example.

[Beefster]

Gleeok: if we're going with your engine, indirect rendering is a must if we want native menus in the player. SFML, for instance, clashes with compiz (Linux eye candy, and the more important title and menu bar) over screen ownership.

Good controller support is important. POVs are underrated.

Scripting languages should have easier learning curves than C++. You can learn Python in a week, for instance.

As for the matter of hard vs soft coding, here's a metaphor: Imagine you just moved into a new house that has been pre-furnished. Imagine that all of your furniture is welded to the house. That's hard coding. The new program will be a nice new house that is also pre-furnished, but you can freely move around and exchange the furniture. That's soft-coding. Both are fully functionaly houses, but look, Ma! Now I can move the couch! (or for that matter, replace the couch with a hammock.)

You could also liken it to pipes for terms of bugs: hard coding is welded copper pipes. Leaks are hard to find and fix. Soft coding is PVC pipes. You can mess with them however you want and leaks are easy to find and fix. You can easily interchange parts for the best fit and the least leaks.

As for the customizable editor, it's actually fairly straightforward. ika uses a frontend that maps "fields" for attributes (like HP) to database entries. Comment meta is unnecessary if you use a free-attribute scripting language. (like Python or Ruby)

[Nathaniel]

It's nice to see Gleeok is putting some sort of effort into making this. I wonder why the other developers haven't posted here. Like Joe123 for example.

Well, this developer input is still pretty young, and the coding part of the discussion is incredibly new. The fact that we are seeing any code in this topic at all at this point is a very positive sign. Some of them might not be aware of what Gleeok even brought up in the first place, and not every developer checks PureZC almost every day, and some never come here at all. We don't even know how the current developers have communicated with each other about this, if much at all. As for Joe, I don't know why he hasn't posted. It doesn't necessarily mean that he doesn't have any ideas or that he isn't interested. Unless he (or any other developer) says so or hints at it, it is probably best not to assume that he (or any of the other developers) has zero interest in this.

[Gleeok]

As for the matter of hard vs soft coding, here's a metaphor: Imagine you just moved into a new house that has been pre-furnished. Imagine that all of your furniture is welded to the house. That's hard coding. The new program will be a nice new house that is also pre-furnished, but you can freely move around and exchange the furniture. That's soft-coding. Both are fully functionaly houses, but look, Ma! Now I can move the couch! (or for that matter, replace the couch with a hammock.)

You could also liken it to pipes for terms of bugs: hard coding is welded copper pipes. Leaks are hard to find and fix. Soft coding is PVC pipes. You can mess with them however you want and leaks are easy to find and fix. You can easily interchange parts for the best fit and the least leaks.

QFT. Proof of concept: AGN Quaranteed/Exterminated/Old beta Bug Forum(s).
Also sounds like that might be compiz'z or a graphics drivers fault?

@Lucas: Nono, it's not as fast as C/C++ by a longshot. It's a scripting language like ZScript. I meant fast in the relative sense. (Fast enough to script a game, not do complex physics simulations.) ..Also fast enough that I think I will use it from now on for other projects I may work on.

Also about the learning openGL api: Unless you are proficient with it, there should be no reason to use it directly. For example; the script calling draw.triangle() literally calls the cpp code *Gulp* Draw.TriangleFill() and that's it. Pretty self explanitory. Doesn't take pages of reference manuals to learn. >_< ..This is actually technically wrong for a game engine though, (It should sort and batch them) but hey it's only a couple of triangles for fun. Sue me. =P



Actually about the scripting, and what language to use: This is a good point, and I don't have an answer. The way I look at it is this: They are all good, and they are all BAD. A programming language is a programming language. It's going to be ugly most of the time and only beautiful only a small percentage of the time regardless. I linked this a while back, but it's worth another go:

http://www.timestret...lBenchmark.html

This is a great page because it has the same function written in (basically) every major scripting language so you can compare the syntax. Forget the speed comparisons if you want, now go down the list take a look at how each language interprets the same exact code. .Go on, I'll wait.

...When you got to the end were you all like "WTF"? I know I was. ..And what's up with that last one? That's just plain retarded. ...*ahem* sorry. So anyway as you can see they all suck.



Personally though, I think it's cool that people (myself included) have learned how to write in C/C++ just from learning ZScript. Joe123 did as well, along with some others here I believe. I don't think that should be taken away from the users of the program without a fight, and I think everyone needs a say in it. 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?


[edit] I'm done making long posts now. I swear. >_>

Edited by Gleeok, 27 June 2010 - 06:06 AM.

[Yapollo]

My knowledge of how to script is essientially nul, but I do know how to recognize and analyze most types of code. Gleeok's code looks promising, but I will let those who practice coding do the real critiqing.

[Joe123]

It's nice to see Gleeok is putting some sort of effort into making this. I wonder why the other developers haven't posted here. Like Joe123 for example.

Well I've been away for a week and the thread's now 11 pages long which I'm sure you can't blame me for not wanting to read; I had been keeping up with it previously.
I hadn't posted yet because I'm fairly skeptical as to whether things are likely to get off the ground, I imagine I'd be able to help if they actually do.
At the moment the main discussion appears to be on graphics libraries, none of which I have any specific preference to. The only ones I have any idea with are Allegro and SDL, neither of which I'm too hot on so I'd have to learn whatever it was decided to use regardless.

EDIT:
Oh, I like the look of Gleeok's scripting language though.

[Beefster]

There isn't much preventing us from implementing multiple scripting languages. The top choice would be to use Lua as the frontend for its speed and simplicity, (including VM warmup) and offer a retooled ZScript/Gleeok and Python via a translator to Lua. Three fairly simple languages merged together into a good scripting engine.

[lonegraywolf]

I must have missed the part about Lua being used. If you guys need some samples of how Lua has been used in/implemented with C++, check out StepMania or one of its forks sm-ssc.

Disclaimer: I have contributed to both linked projects in the past.

[Gleeok]

EDIT:
Oh, I like the look of Gleeok's scripting language though.

Well it's not really my scripting language exactly, as I mentioned earlier it's built from AngelScript http://www.angelcode...nual/index.html which I've sort of fell in love with already <3, which I originally downloaded along with Lua. (Sad to say it but after binding stuff with AngelScript and realizing that Lua 'meta programming' code would not really make things easier to learn at all for scripters (or me)..I never even bothered compiling Lua.) All I'm really messing with is how to make a scripting engine as a whole easier to use, ...basically the complicated things become easy. (I have some ideas but I'd like to mess with them a little first.)

There isn't much preventing us from implementing multiple scripting languages. The top choice would be to use Lua as the frontend for its speed and simplicity, (including VM warmup) and offer a retooled ZScript/Gleeok and Python via a translator to Lua. Three fairly simple languages merged together into a good scripting engine.

How in the HELL do you intend to fit bytecode from AS and Python into Lua which from what I understand has a very small and specialized bytcode and VM!?

Edited by Gleeok, 27 June 2010 - 09:14 PM.

[Beefster]

Uhh. Not the bytecode. The source. Python and Lua have pretty similar syntax and have most of the same features.

[Gleeok]

That sounds like a big mess to me. Can't we just pick one?

[Beefster]

I'd like to clarify that the engine would only run one scripting language, but you could use others by using specialized translators.

I'm personally a fan of Python, but Lua is faster and actually more popular for making games (not by much). Some users coming from ZC will want a language similar to ZScript- like AS. Yes, it adds another layer for mistakes and bugs with a translator, but it's WAAY faster than running three separate VMs.

We could always make an external translator. It loosens up that layer if you can fix the kinks.

[Koh]

Maybe it would be easier to just pick one based on popular vote.

[lonegraywolf]

If anyone feels like trying to map out the relations between each individual thing that would need to be coded for Zelda Modern, I have a Google Wave set up. I just added a few things to at least get things started, but more assistance would be appreciated.

[Beefster]

Lua would probably be the better option for speed, size, and ease of embedding.

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.
I propose that each screen could have a "secrets chain" to make tiered secrets simpler and more straightforward to use.
The trigger flags, pushblock flags, enemy flags, and trap flags could seamlessly be implemented via an event/entity system.
There are only a handful of flags that would actually need to be kept- No Enemies, No Link, Weapon Type Blocking, Raft Paths (Probably would just be a general-purpose flag), and a whole bunch of general purpose flags. These could easily be maintained on bits on integers- that way you can freely mix-and-match.
Inherent flags would also be available- the inherent flagset from a combo will simply be OR'd with the non-inherent flags it corresponds to when it loads.

The current system for layers is silly and archaic. Every screen should have its layers already built-in and you shouldn't have to reference other screens on other maps to work. I suggest a layer structure in which each scene layer can have any number of sublayers. From top to bottom:

• HUD layer- Above EVERYTHING and never moves with the map. EVER. Good for subscreens.
• Pf (Parallax-Foreground) layers- Can be shared across multiple screens and can be larger than the combined screens. They scroll faster than the rest of the world.
• S# (Scene) layers. There are multiple scene layers as well as the sublayers within them. Collisions for entities are only checked for the layer immediately below them. Entities cannot be between sublayers.
• Pb (Parallax-Background) layers- Can be shared across multiple screens and can be smaller than the combined screens. They scroll slower than the rest of the world.

When editing maps, you will be given full access to the scene and parallax layers. Inactive sublayers above your current layer will be half translucent and dimmed. Sublayers below the current will only be dimmed.
Entities/events can be placed above or below any scene layer (as well as between two scene layers).