ZGameEditor forum

Complimentary to the Roadmap Thread, a attempt to collect and prioritize "deal-breaking" shortcomings potentially causing developers to hold out on ZGE.

---

Top 10 Draft

01 : Raycast
02 : Z-Sorting
03 : Hierarchy
04 : Mesh Collision
05 : Animation
06 : Clone Access
07 : Priority
08 : Strings
09 : COLLADA
10 : Skin

---

3D / 2D / General

Description: Short description of the feature.
Dependencies: Missing "libraries" required for the feature.
Relevance: Elements to which the feature has relevance.
Script: When possible, explanation of a scripted solution.
Priority: Low - Medium - High - Critical

Alternative: Creative solution sidestepping the limitation.
Documentation: Hyperlinks to documentation on development of the feature.

: Easy
: Challenging
: Tedious
: Insane

---

Raycast Link

Description: Collection of ray-based intersection tests.
Dependencies: None
Relevance: Approximation, dynamic intersection checking, returning normals, etc.
Script: Requires all collision related data of Models to be stored in Arrays.
Priority: Critical

Alternative: Interaction based on screen-projected coordinate conversions.


Rez © Sega 2001

Documentation: Real-Time Rendering

---

Mesh Collision

Description: Collection of triangle-based intersection tests.
Dependencies: Matrix
Relevance: Collisions in modern Platform-, Fighting-, Racing-, Shooting-Games, etc.
Script: Requires all model & vertex data to be stored in Arrays and processed using Matrix calculations.
Priority: Critical

Alternative: Grid-, Spline-, AA-, and / or Primitive-based Collision only.


Fez © Polytron Corporation 2009

Documentation: Real-Time Rendering

---

Z-Sorting Link

Description: A process which sorts models and / or polygons in render order based on their depth.
Dependencies: Matrix
Relevance: Prevents unwanted buffer-overrides for transparant render operations.
Script: Requires all Render Components that make use of transparency to be called from a single OnRender event.
Priority: Critical

Alternative: Diffuse- and / or Wireframe-only art style.


Noby Noby Boy © Namco Bandai 2009

Documentation: Steve Baker

---

Culling Link

Description: Technique determining whether a render operation will be visible.
Dependencies: None
Relevance: Can be a significant performance boost for most games.
Script: Basic frustum culling is easy to replicate using Matrix calculations, obstruction not so much.
Priority: Low

Alternative: Full playfield in view at all times.


Wetrix © Ocean Software 1998

Documentation: Tomas Möller and Eric Haines

---

Skin

Description: Mesh transformation method supporting multiple "effectors" per vertex.
Dependencies: Matrix + Hierarchy
Relevance: Animate-able human / organic meshes.
Script: Requires all vertex weight data to be stored in Arrays and processed using Matrix calculations.
Priority: High

Alternative: Individual mesh per transformable body-part.


Virtua Fighter 2 © Sega 1994

---

Animation

Description: Collection of FCurves representing Object translations.
Dependencies: FCurve + Matrix + Hierarchy
Relevance: Character animation, RTM's, motion sequences, etc.
Script: Parse animation data, simulate FK using TransformGroup's.
Priority: High

Alternative: Procedurally generated animations.


Spore © Maxis 2008

---

Hierarchy

Description: Parent-Child relations between Object's transformations.
Dependencies: Matrix
Relevance: Bone structures, move-able parts, vehicles etc.
Script: Requires all Object transformation data to be stored in Arrays and processed using Matrix calculations.
Priority: Critical

Alternative: Single-body entities only.


Trash Panic © Sony 2009

---

COLLADA

Description: XML based 3D file-format.
Dependencies: FCurve + IK + Skin + Morph
Relevance: Importing hierarchy-, animation-, skin-data, etc.
Script: Probably impossible ( even using the File Component ).
Priority: High

---

Clone Access

Description: Accessibility to properties of Cloned Models.
Dependencies: None
Relevance: Interaction between clones.
Script: Simply a matter of assigning a unique key to a clone and storing values in a Array.
Priority: Medium

---

Priority

Description: Property determining the order in which Components are executed.
Dependencies: None
Relevance: Multi-step communication between clones.
Script: Requires all priority steps to be split over separate Models.
Priority: Medium

---

Strings

Description: A sequence of symbols or digits.
Dependencies: None
Relevance: Text that does not consist of small digits only.
Script: Requires all text to be stored in ASCII code in Arrays.
Priority: Medium

Alternative: Morse code, braille or sound only.

---

Proportional Fonts

Description: Per-letter attribute determining the width of a character.
Dependencies: None
Relevance: All non-monospaced fonts.
Script: Array containing width per character.
Priority: Low

Alternative: Monospaced fonts.


Shining Force © Sega 1992

---

Suggestions and / or comments to the structure of this list, critical features you want to see added / removed, and the priority / ratings of the listed features are more then welcome.

For any discussion on development of features, please revert to their individual threads.

Kjell,

This is an excellent write-up of what is missing in ZGE.

On the topic of "why not more developers are using ZGE" I would argue that an critical problem of the current version is that it is not very easy to use. I think that people download ZGE and then scratch their head and don't understand how to use it. Even if we implemented all 10 of your items I still think many developers would shy away from ZGE because they don't understand it. ZGE is about making fun games and ideally games should be fun to make too instead of getting frustrated trying to learn a tool. So "improved usability" would definitely be on my top-5 feature list of deal-breakers. Also improved documentation and tutorials.

COLLADA is something I've been thinking about but not really investigated yet. Perhaps it can be made incrementally so that the first version just imports static tri-meshes similar to what 3ds-import does. Then as we implement support for animation, hierarchy and skinning it can import that too.

Z-Sorting, it feels like we are close to trying that out using the solution we discuss in the thread.

For several of the items it feels like improved scripting is a requisite (unless they would be implemented as components) so I'm giving that high priority. In other words: enabling other advanced features through scripting.

To implement all 10 features I need lots of help. So maybe the highest priority of all would be "find more developers"? Not the easiest task, because it requires good pascal knowledge and an interest in developing resource-limited game engine technology.

Hej Ville,

I fully agree with you that "ease of use" and additional documentation / tutorials can definitely be deal-breakers for users at the moment as well. But for this particular list I wanted to keep the learning curve / usability out of the equation. Perhaps we could write-up a similar list for the Editor?

What you describe as a development path for COLLADA sounds like the way to go yes

For some of the listed features you'd need to pass types other then float / int to functions, so that would require some advanced scripting updates indeed. Personally I wouldn't mind if everything was Components only initially though.

Anyway, please attack this list! It can't be valid unless other users start pushing things around ( no 2D, Sound, Network deal-breakers ? ).

K

Priority: Dunno what I think about it ^^ I would love some kind of priority but as we already discussed I have no idea about how to implement it!
ZSorting: I agree, we should work it out, possibly before ZGE 2.0

COLLADA, skin: I actually don't even figure out how they could be used, so dunno about them ^^

Animation: we should go with some kind of procedural animation... or find something easy for the end user (sorry but IMHO we must avoid targetting a too high-level)

Clone access, Strings: IMO should be kept script only (and maybe it should be made easier for the end user to use it by scripts by adding some functionality to the scripting language)

RayCasting, MeshCollision: we should get them working someway. Maybe picking up some stuff by the Bero contribution. It's a shame he seems no more active on ZGE ^^ He could have been a really GREAT contributor!

What I would like:
-Ability to pass an Array to the scripted functions. I still need to understand how functions are used into the scripts before being able to code something :/ Even if I already used an "array access" in the creation of the "BitmapConvolution" component (sending a patch to Ville today)
-One of the dealbreakers for the editor might also be the absence of a button to reset all the variables that were modified during the preview (I mean, sometimes some variables are "straying bullets" because they were not initialized correctly, will post an example because I know I'm not so much clear! An example however could be the App.Time!)
-We need some docs too! The good news is we have the doc guy now! Thank you Y Off set!!!

EDIT: Hierarchy is actually useful, if it is what I have in my mind.

Hi Francesco,

Priority could probably be done in a pretty similar way as Z-Sorting ( you won't even need any calculations, just sort from high to low ).

Hierarchy is the same thing as when you use a stack of RenderTransformGroup Components in each other, but calculated by the Engine instead of "pushing" & "popping" the render matrix in OpenGL. The reason why you want to do this is because in the OGL route the transformations only happen in the render, they don't actually physically "exists" in your game. So you wouldn't for example be able to use correct mesh collision.

Additionally you'd want to be able to do this dynamically, so that for example when a character walks into a elevator, you can then parent it to the elevator so the movement of the elevator is followed ( which is a much easier / light-weight alternative to using physics on everything ).

Skin is the industry standard for creating "organic" animate-able meshes. In the heydays of 3D separate meshes for each individual body part where used, as in Virtua Fighter. But nowadays a character can be just one mesh using skin, as in Virtua Fighter 3.

Procedural animations are far more advanced and difficult to create then traditional FCurve based animations. Even Spore actually isn't a solid example of that route, since they used traditional animations as a basis for their "procedural" system as well. Problem is, as far as I know there aren't any games out there yet that contain fully procedurally animated characters ( apart from Sumotori maybe .. but that's physics driven ).

Creating skinned meshes and FCurve animations are what 3D Applications such as Maya / Softimage / Blender are for. Procedurally generating that kind of data is insanity in most cases. And you don't want to exclude 3D games that contain animated human-like characters from ZGE either.

The "revert to initial condition" idea is pretty interesting. Virtools actually has such feature ( although I never use it ), but there are benefits to writing your own "Reset" ZExpressions to be used OnStart / OnSpawn as well.

+ Here's a short video illustrating the basic use of a Hierarchy ( or so called Forward Kinetics ) in Softimage .. but it's the same in any other 3D software. Couldn't find a microphone to narrate you through, but should be pretty straight forward. The main thing is that transformations from the parent are "handed-down" to the child.

K

Yes, this is a quite interesting list, another fine contribution from Kj! I find insperation from the ideas and the pics,. thinking of games using these or ways to implement "cheat" alternatives in the current engine.

Sure I would like to see all that stuff,. (skining and COLLADA being the lowest priorety for me,. sorry Kj, I know you got some modeling chops, [and I would lov to see some samples!!] but I am happy with abstract shapes and robotic animations, that said when these are added I will happily use them ) my personal needs would follow what it sound like Ville is focussed on, namely improving the scripting so some of these can more simply be added throught carefull planing and design. (the things I fail at most offten )

As far as attracting new users (and developers),. I have had the idea of some 'basic getting started' tutorials (including a 'for GM users' one!) and I will try harder to actually write some. As well, I will post some basic .zgeproj files for some of the common game types,. as I know for me it is most often easier to play a few simple samples, and then start hacking away on the one that takes my fancy,. so some open source projects should help.

For what to add/subtract from this list,. I see no reason to remove anything, although some are major efforts and likely long term goals,. I could add some suggested improvments but nothing Dealbreaker as the thread indicates; some simple improvments to the sound engine,. better sample support, as that seems to be the prefired method for most ppl,. (simpler looping, loading .wav, ogg, ect. in the editor, some presets for the synth (actually I am just haveing an idea to add a functionality like DrPetter's sfxr focussed randomiser/mutator to the editor for ppl to just press a few buttons like Laser, Explosion, Coin/Get etc. and have semi-randomized presets generated! I will run some tests.) a few more oscilators would be nice, Sin, more Noise types, Saw forward/back, Hex, etc.

Network support would be an attraction to many, even for turn based gameplay and net based file upload/download,. for content on a server (for registered users, i.e. pirate resistant game sales!),. but that would require run time model/sample/bitmap/ect. loading,. so really the posibilities are limitless,. and you only need focuss on the next implementation and ZGE keeps improving all the time anyhow!

Hey jph,

Don't worry, your opinion is just as valid as anyone else's I'll push down skin and COLLADA on the list.

And something that might be worth mentioning, the 3ds format does actually support hierarchy and keyframe animation data ( not sure what type of curves though ).

*Never mind on .3ds animations, it does work .. but all animation data gets sampled upon export ( one keyframe on position.x = 0 at time = 0 and another on position.x = 1 at time = 100 become a hundred keyframes without any tangents ), which is not ideal to say the least.

K

As a semi-noob who now has an idea how things work together, I think a modular approach with...

1) a tutorial on how to make an animated model
2) a tutorial on how to make a 3D scene (ground, skybox, light(sun)).
3) a tutorial on how to make simple buildings
4) a tutorial on how to put them together and interact

would be the way to create interest.

The current tutorials do an excellent tech procedure, but they fail on setting good creation procedure habits that make it easy to remember how six months from now.

I am at ease, now, with working on the tree, but in the beginning it's very confusing, so I want to work in that direction.

Hmm,

The topics you refer to are quite broad and require different techniques depending on your creative and technical needs. Let me try to break it down.

1) How to make a animated model? What kind of model, a human, robot, dolphin, car, spaceship, windmill ... Plus you'll always have the choice to create the 3D meshes in external software or procedurally generate it inside of ZGE.

2) How to make a 3D Scene? Same thing, floors can be done externally or procedurally. Skybox can be physical mesh or a shader, light is either fixed or again .. shaders.

3) How to make simple buildings? Choice between external or procedural again.

4) How to interact? Now comes the hard part, as mentioned in the dealbreakers list, there is no build-in way to interact with meshes at this time. You're restricted to the primitive collision styles ( or have to do all the math yourself in libraries ). Now .. this is not the end of the world, since you can take limitations into consideration when developing mechanics, meshes etc. But it is something you need to be aware of.

Are there any specific ( famous ) games that you where thinking of, or would like tutorials to tap into?

K

Well, we're looking at this from two different directions. You, from the inside out; me, from the outside in.

I've probably looked at 60 different game makers in the last couple of years. Not that I have any game inside me just bustin' to get out. I just find the the whole process cool. A couple of things have occurred to me.

1) Trying to be all things to all people will make an enormous, complex application that only a few dedicated people will actually use at the end of the day.
2) The closer you try to imitate real life will result closer to 1).

Now, if this is just an intellectual pass time then please continue.

Of all I looked at, only one stood out as easy to make effective 3D levels with, and as a result, I became quite adept at. That was XOPS (Assembly, DirectX, no source). Now, I know the list of its shortcomings is long, but to this day almost 20 years later, there is still a vibrant Japanese community making and modding it.
After I tested its limits, I went looking for something better. I found the Retribution Engine (3D - OpenGL - C++ - no source) easy to work with and spent time there. Unfortunately, it suffers from bloat and apparently abandonment.
Just the other day I discovered NovaShell, which looks to be the 2D ace, at least according to my priorities. And of course, there is the ZGameEditor, which shows great promise in letting me tweak right to the source.

If you've followed this discourse, I think you'll agree I fit the profile of an end user rather than App creator, but then again, why are you making this? Anyway, my point is, if it isn't a K.I.S.S. app, then people like me lose interest.

The previous post, how the heck do I know? Internally, your app balloons in size. Externally, you're forever playing catch up with on going changes by someone else.

Whatever you decide, you need someone like me to write the tutorials in plain speak.

Hi,

Actually, it's the other way around.. if you procedurally generate everything within ZGE you'll most likely end up with a much smaller .exe then when you create textures in Photoshop and models in Maya.

Anyway, I beg to differ that I look at ZGE from inside out. First of all, I'm not a programmer ( I do however try to contribute in that area as well ), and second of all .. although I don't think I'll get to 60, I'm a avid Virtools user ( Schematic ), know Game Maker ( Drag N Drop ) by heart, started playing with Unity ( C# ) since it first came out .. you catch my drift.

If there is anything I care about it is simplicity & usability.

Coming back to your tutorial requests, let me re-phrase .. when you're using XOPS or NovaShell, do you create your graphics by code, create them in external applications ( such as Photoshop / 3ds Max / Blender ), or use sprites / 3d models that are provided by the software? Since for each of those, the tutorials would look quite different.

Just trying to help

K

Ah, then we do see thing more or less the same.
GameMaker is good - didn't feel like learning another language.
Got familiar with C# looking at NeoAxis. Same for Pascal looking at Lazarus. Decided Quark/Quake getting too complex for what they are (2.5D).

XOPS uses cube mesh with each vertex movable via point&click - texturing with exterior multiFormat texs. done in this simple 4 view editor - result file accessed by charCommand waypoints P&C simple 4 editor - both files accessed by simple headerType file maker which adds skybox and dialogs - main app runs 3 files thru header. User can skin characters - change arms/legs - body/animations hard coded - mod sounds, weapons.

NovaShell - everything is a sprite on a sprite - exterior .png cut up into tiles - P&C collision - Lua scripting - exterior sounds - xml sprite animation.

I use GIMP, Irfanview, Fragmotion, Audacity, whatever.

You'll make more than 60 if you dedicate 2 hours out of 48 for vigorous workout.

Hello,

Judging from your description of the XOPS Editor ( and mentioning Fragmotion ) you're at least familiar with traditional 3d content creation ( 4-view-3d-editors ). ZGE however doesn't have such a thing build-in, neither would it be very easy to set up yourself inside of ZGE ( no vertex access by index, no raycasting etc. ). So if you want to use that kind of 3d content creation, Fragmotion is probably the way to go.

You're in the same boat as me when it comes to importing 3d data into ZGE though Fragmotion ( just like Softimage, which is the software I use ) doesn't support exporting to .3ds. Fortunately there are plenty of tools that can convert data created in Fragmotion to the .3ds format, for example Wings3D.

I'll take some time this weekend to put together a simple ( video ) tutorial that covers a part of what you've mentioned.

K

I have Wings and have used it a little. That's good to know. Have SoftImage also, but never really got very far in it.

In my wanderings I read a thread about Collada files being imported into a rendering app. Apparently, there is no Collada standards being followed by the major modeling apps and they are all exporting slightly different formats. This render app was trying to decide what to do.

Just thought I'd brighten your day a little.