ZGameEditor forum

Hi guys,

I'm thinking it would be nice to have some sort of long-time roadmap for the product. So I'm asking for your help to decide what should be included.

With "long-term" I'm thinking about the 2.0 version with a time estimate that it should be finished before the end of 2009. During the last year I've not spent any time on trying to market the product but with 2.0 we could do a relaunch with press releases etc. for reaching out to new users.

Here are some suggestions and ideas. Remember this is a very preliminary list, everything can change. And of course it always comes down to how much time me and other people contributing can spend on this project. You don't see your most wanted feature? Post a reply now!

Technical:

• Improved scripting with runtime library
  Import 3d-geometry with animations
  Music engine (replace midi)
  Improved support for texture generation
  Large built-in component library
  What else?

Documentation:

• Website overhaul with more professional looking layout
  New tutorials
  Translations
  More?

Community:

• This forum
  irc
  Community user pages where users can upload their games
  Other?

A related topic is our goals with ZGE. Which direction should we work towards now? What do you want ZGE to be? A general game engine, a 64kb game maker, a tool to prototype procedural techniques, an educational tool for game development. Or just a fun toy? Personally I would like ZGE to be able to run a more varied range of games while continuing to be small and efficient. It would also please me if it can be made so easy to use that it can be used by beginners in game development training courses.

Please share your thoughts in this thread.

Well first of the ZGE has become much more fully featured over the past year or so,. thanks for all your amazing work!

These all sound like great goals,.
for the 3d stuff I would add some mesh generation/manipulation components. I have been playing around with that TopMod mesh manipulator and the procedures that I find myself appliying to the meshes I can see should be done at run time (for procedual correctness i.e. data compresion/ result variation) a couple of subdivision techneques and some smooth/tighten,. and at least one of the styles of converting the edges into a 3d 'cage' type mesh,. as these used together are great for creating interesting complex structures from simple ideas/meshes. Of course most of this can probably be achived in scripts with the current system,. however as you know most people do not posses a Phd. in 3d maths. least of all me

The music engine is also a welcome idea,. my problem with the midi has always been the lack of a way to edit the tunes,. ZGE has a cool realtime sound engine so the best way to compose music with it would be to be in real time,. as music is more than just notes,. for dynamic music pans, filters, osc ect. should to be set per tick,. now that we have arrays I would say this is mostly solved,. I still would like the editor to provide a nice grid based interface to array data,. for me that would be quite usefull,. but again if I take the time to set up a system to load array data from a file I suppose I could edit in another data editor and it would work similarly to what I'm after.

Texture generation has improved greatly,. or my understanding of some of the mathemetical functions has,. and with Kattle's kind posting of scripts much can be done now,. that said Werkzeug3TE is still super 'productive' i.e. I can can just mess about with it and generate amazing textures in no time,. with ZGE it is still much more work (abstract math), and a tad hit and miss. remindes me I was going to post this,. http://www.apophysis.org/ is a cool opensource delphi fractal generation app. could use some functions in the texture gen. section

library yes! (I have some stuff to add)

for documentation,.
I can work up some basic tutorials perhaps. as we each have our own understandings and methods of design,. the more the better to attract various people,.

one simple thing you could easily add is to include the "Book of Words" or the Writing Expressions page on the pulldown help menu,. I have a very bad memory, (or poor recall) and often need the referace. The more that is added the more use that will be,. should be off-line in my opinion as well for ppl not logged on to the wwnet,.

as for what ZGE should be,. I just want to build games and other interactive art, it does these things well,. I love the principles it is based on, the size, the prodecural nature and the price is right Perhaps I would open it up to .dll integration a sorta modular upgrade path for people with specific needs,. physics, alternative sound/music, net integration, these things are availible throught this method,. . sure they are platform specific,. however, it is near to imposible to dev. for systems I don't have access to anyhow,. so crossplatform although very cool,. and I support it in concept, in practice it is difficult to utilise.

Whatever you add to ZGE I am sure it will be cool!

About scripting:
Neither I nor XProger not plan to use scripts (Lua, Python, PascalScript, etc.). I ( http://simsmen.livejournal.com/5184.html rus) want to work with dunamic dll (as in http://gurin.tomsknet.ru/dccusing.html rus, pas). XProger ( http://xproger.livejournal.com/26495.html rus) furthermore plans to cut the code from the dll, and only use it ( http://www.everfall.com/paste/id.php?6jaa6r6hihpl pas). This is a very compact form.

Sorry, google translate

Personal To-Dos list:
-Steal the texture generation GUI from the "void" engine (or equivalent) then I can help you translating that stuff in the ZGE tree-structure.
-Give me 10 days to finish my exams
-Some 3D texture smoothing might be great. I mean both subdivide and "reduce polycount" tecniques.
-Reverse engineer something like the "Normal" component in TG (I already did it but now I need to code it's functionality to a script or pascal, then fully understand how the "Light" component will work), and adding more components

As a bonus:
-If you want we can try to get this engine working with the Pandora console. I really don't know how much this will be hard.

Hi guys,

Good to see this thread appear.

*It took me some time to arrange my thoughts as there is no clear line between what has been set in stone and what is up for debate. Anyway, here's the least radical approach I could think of.

Ville's remark that he would like ZGE to cater for a wider range of games while remaining small & efficient, covers the direction I would like to see ZGE take best. This basically requires more low-level hard-coded components / functions like we've welcomed over the past year.

( One concern here is the devision between scripted functionality and components. I believe you should either go with one or the other, or have both do all like GM. )

On the other hand, making ZGE more accessible for migrating / newbie developers is complete different challenge. Or is it ..

One of the most used concepts in development is the black-box. Programmers, artists, designers, musicians .. everybody uses libraries, functions, buttons without having to know what actually goes on under the hood. If we could introduce a component that behaves like a function and only shows the properties that you need on the top level, we could make a clean & clear distinction between source-code development and scripted libraries.

For example, the MouseModelController component could be a Black-Box / Library component that only reveals a Inertia variable on the top level, while it actually also contains a ZExpression that contains the actual behavior.

( You could even take it one step further and enable dependancies of Black-Boxes on others, to encourage a modular approach. )

Obviously this will require some work on the Engine + Editor and is at the cost of some performance, but this could make working with and exchanging Libraries significantly easier.

Alright, I'll leave it at that for now ..

K

+ The Editor could use a overhaul, but Ville already knows this

humm that is an interesting idea. I do likes me some blackbox! often I really don't care how its done as long as there are some variable/settings for me to tweek to get the results I need,. and this way when something new is added the 'under to board wireing' is editable only if you need to,. so how much loss of speeds are we talking,. are uneditable components compiled in a way that makes them faster and these could not be? this is in some ways like the library and Zlibrary ideas,. but with a more component gui approach,. .

Hi jph,

The same speed loss that you already have right now when for example using RenderSetColor opposed to having a "static" Delphi compiled glColor3f().

This idea is very close to the current Library indeed ( I tried to suggest something that would be as little disruptive as possible ), but enables the creator to create a "wrapper" / interface for the component package that makes it easier to use for others. Obviously it would also help if importing / exporting these XML files will become easier then it is right now ( for example let the editor scan a dedicated folder for XML files ).

+ Once a Black-Box / Library is being used allot, you could always decide / request to hard-code it in order to get the performance boost.

K

About the blackbox concept: I would like to know what you think about this idea.

We might want to make the group component an "active" component. EG: if you select a component (maybe a new "BitmapGroup" component) the editor will show you a new window/something else in which you will be able to build a texture using some techniques similar let's say to TG or werkerzug (or whatever you write it! ). Anything you edit inside this window will be added as a component "inside" the group, in a trasparent way to the user. (let's say you have operator stacking, your operations would be translated into the relatives Components, you will not be able to expand the group, or you will be able to expand it but it will be read-only).
This can also be usefull for people trying to generate a fractal mesh: you are asked for some parameters, and the whole thing is translated so we do not need to add anything to the runtime, just to the editor (no exe-size limits there ) and also get sime kind of "blackbox" done.
Other easy stuff is: get a group that "contains" a component of a library (EG: the cone or cylinder mesh) and lets the user to modify the name of the contained mesh in the properties list of the group, so they DO NOT EVEN NEED to see that under that component we just have a sphere and a MeshExpression.

Last but not least, we should be able to "execute" the code contained inside a group, both from scripting and from another component. This should give a brand new usability for a already-well-known component.

Hi Francesco,

The "execute group of components" idea ( which you've mentioned before ) is a very good one and would like to see that appear as well.

Now about a Werkkzeug style schematic editor .. I think it would be bad to introduce yet another scripting interface next to the Component Tree and Scripting Language that ZGE already has ( don't get me wrong, i prefer such interface over anything else myself ). Even if you'd use it exclusively for texture generation.

K

Interesting ideas from everyone so far.

About blackbox:

We could have something similar to grouping in graphics software, so that you can group a set of components which will mean that they are locked and can be modified only as a whole. Then you can ungroup again if you need the details.

The "content"-components Mesh and Bitmap are natural candidates for this. So maybe we should try it with them first at see how well it works in practice. If we are successful we can extend the functionality to expressions and "logic-groups" with input and output.

I'm just thinking aloud here. It needs more planning before it can made in practice. However the Bitmap-stacking editor could possibly be reasonably realistic to implement soon. We can discuss that further in the Bitmap-stacking thread.

Kjell: the idea of this sort of gui is to make it easier to create bitmaps, in the same way that the sound-editor makes it easier to create sounds even though the same functionality is available in editing the properties directly. I like the idea of a mesh-editor too, that would generate meshproducers under the hood that also could be edited in the property-editor like today for fine-tuning. As always, we can discuss this further until we are all sure that it is a good idea that will be worth the effort.

VilleK wrote: Kjell: the idea of this sort of gui is to make it easier to create bitmaps, in the same way that the sound-editor makes it easier to create sounds even though the same functionality is available in editing the properties directly.

The only problem with the tree-structure in ZGE is that it is really usefull for "skilled" people since it's really near to a "program flow" chart, but EG for creating complex bitmaps you will need to think in reverse polish notation... I don't think so many users will be happy to need to understand why "6 3 2 + *" equals to 30 before start making their own texture

yes I like all these ideas as well,. operator stacking for bitmaps just makes sense to me as it is fast to work with and logical,. one function builds on the last and branches can be mearged easily,. Kj you are right it does add to the learning curve perhaps but the usability it would give to the dedicated seems well worth it, and if ppl just want to use impored textures they would never use it anyway,. although adding it would them require more operators to stack! although, with some form of black box, or basicly an expresion component that has n sliders that can be linked to variabels in the expresion ( something I do now by hacking a translation component and using scale.x as the variable I need to tweek in real time and see the results happening in the editor,. )
that would be the basic editable black box? just an expresion component with n sliders availible to link to,. then script away,. ppl can add them to the library,. .

Hi guys,

Operator stacking could also be done in the Tree View, or in Scripts .. but I understand where you guys are coming from. In fact, in my 3D weapon of choice the Render Tree has a similar interface.



But for example Virtools uses such interface for all of it's scripting, which works great actually ( unfortunately it's outside the price range of most people ).



Anyway, perhaps I just don't fit the general profile of a ZGE user that well ( I don't use allot of procedural techniques ) .. I guess my focus / feature requests generally lies elsewhere then "content creation" ( bitmaps / meshes / effects )

+ Sorry for the giant screenshots, just thought it would be useful if they where readable.

K

yes a network of nodes is a very usefull thing., lots of software uses this organisation/editing system,. I have spent a lot of time working with BUZZ;



and that setup is quite usefull for organising sound flow throught various sythesis mixing and processing cels,.

When I was working with Maya I found it is similar, and many others as well. One problem with nodes and wires is that things can get messy and dissorganized easily,. (true for code or anything really) the operator stacking interface seems limiting at first, but the lack of wireing and the logic of the stacking being visual and compact works very well for procedural textures, likely meshes too,. not sure how that would be for building gameplay/code structures??

With ZGE the tree system has quite grown on me,. it keeps things organised and the groups that can be collapsed and moved around make it quite easy to work with,. as well as the consistancy of place for the various elements,. I can see how a selected component in the tree could open a window in the right with stackable operators while retaining the tree for over all organisation,. . works fro me.

(One odd thing that comes to mind now though, is that local variables although they can not be accessed outside of their Model,. are limited to single use for the whole project? i.e power has to become power1 power2 etc. )

Hej jph,

The only difference between stacking / tree-view and graphs / schematics is that the latter give you the freedom ( or responsibility perhaps ) to organize your "network of components" yourself. And although I don't necessarily care for that freedom when a interface does a good enough job at that itself, I do enjoy finding my own personal approach in order to keep things organized when this is required ( yes .. I'm a neat freak ).

For example in Virtools I usually group everything ( in ZGE as well actually ) and only place related "components" horizontally from each other ( stacking everything vertically ) .. but I've seen other developers make a giant mess of it as well

K