Scripting enhancements
Posted: Wed Jul 07, 2010 10:55 am
Having played around with ZGameEditor for a few days, I must say I am very impressed. In my case, I needed a quick way to prototype some procedural generation ideas, and it definitely helped a lot.
In terms of feedback, I think the main thing I would like expanded is the scripting system. After looking at the forums a bit, I think a lot of the requests or problems people are having could be resolved with some extensions to scripting too.
Allow creating components through code.
Component chains can get pretty long and confusing if you are trying to do some complex logic. Having to jump from zexpression->component->zexpression->component can really break up the thinking when you are trying to look at what is happening.
Also, certain components would make a lot of sense just having them as functions, that you can put right into a zexpression - SpawnModel("ModelName", i, j, 0); etc.
Object / Component id data type
Referring to objects by name is not always possible or the most elegant solution. It would be great if we could efficiently loop through a certain set of models, push some into list A and the rest into list B, then do something with each list later etc. Also, following on from the previous point, functions such as SpawnModel could return these id's (which could map directly to pointers to the object internally).
Support a generic object type
Many scripting languages such as LUA are able to stay small and efficient (bloat free) by having a simplified, generic object (or table) type. At the moment, it is very 'hacky' to have to use globally defined arrays for everything (also many things are not possible with pure arrays).
If such a datatype is put in place, it can then be used for stacks, queues, hasmaps, sets, lists etc.
I know there are arguments against making the scripting language more complex, however I think it could push ZGameEditor to be used for much larger scale projects. Also, this could allow a lot of things to be achieved much more simply (less components, simpler logic) which means that executable sizes might not always be greater.
In terms of feedback, I think the main thing I would like expanded is the scripting system. After looking at the forums a bit, I think a lot of the requests or problems people are having could be resolved with some extensions to scripting too.
Allow creating components through code.
Component chains can get pretty long and confusing if you are trying to do some complex logic. Having to jump from zexpression->component->zexpression->component can really break up the thinking when you are trying to look at what is happening.
Also, certain components would make a lot of sense just having them as functions, that you can put right into a zexpression - SpawnModel("ModelName", i, j, 0); etc.
Object / Component id data type
Referring to objects by name is not always possible or the most elegant solution. It would be great if we could efficiently loop through a certain set of models, push some into list A and the rest into list B, then do something with each list later etc. Also, following on from the previous point, functions such as SpawnModel could return these id's (which could map directly to pointers to the object internally).
Support a generic object type
Many scripting languages such as LUA are able to stay small and efficient (bloat free) by having a simplified, generic object (or table) type. At the moment, it is very 'hacky' to have to use globally defined arrays for everything (also many things are not possible with pure arrays).
If such a datatype is put in place, it can then be used for stacks, queues, hasmaps, sets, lists etc.
I know there are arguments against making the scripting language more complex, however I think it could push ZGameEditor to be used for much larger scale projects. Also, this could allow a lot of things to be achieved much more simply (less components, simpler logic) which means that executable sizes might not always be greater.