Solomon - Cool cool, I'll let you know when I get it posted. Oh I see, this is where you saw slopes mentioned. On the other post we are talking on I didn't realize yet you had read this one.

Solomon -

"Regarding the objects and instance variables, do you use empty sprites or just rectangles? Do the additional sprites not weigh more than global varaibles in the event sheets?"

What do you mean by weigh more? Are we talking performance or just in terms of finding them in the expressions list? In many cases I actually waste the time to make nice graphics for my variable objects. The player never sees them, but a meaningful image helps me see whats going on when I look at the event sheet. Like I have a little world icon for my global variables object and a picture of a generic level for my level object, a controler for my input object and so on. The pictures next to the object in the event sheet are one of the biggest reason I love using construct lol.

CMV stands for comma exasperated values. I think it was Colludiom, or R0j0hound that got me using those. They can be quite useful if you have a very data heavy game. You have to use ajax and read in the files but you can use it to change the game parameters in an excel spread sheet and can be handier than working with constructs variables. You still have to have the variables but when you create an enemy "troll" you could just set the common enemy variblels to teh trollLv 1 cmv and presto, less work on your end for the same effect as setting it all up manually in construct. If that makes sense.

---

As for slopes in my game, did I mention that? Or is that from a different post lol. Slopes are a royal pain lol.

Solomon - I don't mind at all!

1.) Behaviors...

I use javascript to create behaviors. If I do something, like math, or really any set of isolated events I often create a small behavior that does the same thing. It helps keep my event sheet clean and tidy. The downside is that creating a behavior takes alot longer than creating events because you have to connect it all up so you have conditions, actions, etc. If you want the behavior to save its state then there is all that work too.

Here is a case example: In my game I have a boomerang. The math that controls the boomerang is the same every tick (if a boomerang exists) so instead of using events to control it I created a small behavior that has 2 actions: "SetTarget", and "Update". If you hard code the constants, writing the bahvior is quick and easy, but if you think you will need it again for other things its best to expose those constants as variable parameters exposed to construct. In general, if I spend an hour prototyping an event based behavior, I can get it set up as a behavior in 10-20 minutes depending.

If the behavior is more of a object relationship behavior, things get a little more difficult, but in the sdk you can have two behaviors talk to each other... The problem is that they become dependent and only work if you have both behaviors. Typically I don't let behaviors do anything without me telling them to do so via an action. I even have split out the everytick auto update that occurs in platformer and created an action "Update". In this way I can control when an object gets updated, if at all.

Events that are purely math or similar are most like you said, "an external function". I would do this for things like quadratic lerp, Threshold translations, and other things. If a function made via events does not refer to specific objects, I most definitely add it to a custom plugin that houses all my functions for a particular game. This ties in a bit with what I mentioned about event functions which I'll get to in a moment.

I hope this all makes sense!

2.) functions.

I keep my event functions to a minimum for a few reasons, though in the past I used hundreds of dynamic functions. I would have functions calling functions and objects updating by calling a function name that was stored in a variable. There is neat stuff you can do around that kind of orginization but there are some problems with that in construct.

Firstly, there is an overhead performance hit to every condition and action you do. If you make an event sheet to do the same thing a behavior does, the behavior will run much much faster. For some games this is irrelevant, but for others it can be important. If you create a nested loop in construct that doesn't do anything (100 x 100) it will make a noticeable hit on your performance. (basically thats 10000 conditions, or however you want to think about it). If you do the same thing in a javascript behavior you will hardly notice it running (assuming its doing nothing as well). The result of the putting that in a behavior is that the event sheet only does 1 thing and thats call the "update" action on the behavior, then the behavior does the rest at a much better performance. The event sheet is great, but it is also incorporates a super powerful object picking system that has its costs.

Function within construct make that system do more work. The time it take to call a function is 5 times what it takes to perform a simple variable = x action or condition. If you function has many actions then it is probably worth it... but if you call a function to only do 1 or 2 things and then that calls another function to do a few things and then this function needs a parameter passed to it with an object uid and then you have to pick that object again... This can all add up if you are doing this 1000 times a tick.

Functions are only for the benefit of the programmer. A computer is so fast that it makes sense to use them. But in the case of construct 2 you are using a virtual function system that is built ontop of javascript. The performance loss here is not trivial if you have many objects. There is a forum post that I started a month or so ago where ashley talks about this. In most cases you needn't worry about using functions, but in my case, and in my particular game, I was using functions like I would be if I were writing in c++ creating a very object oriented dynamic event system. This was okay until I wanted 100 baddies on screen at once. My performance bottleneck was function calling. Even in c++ there is a performance hit for using functions, its just much more trivial. But when you use a function in construct you are basically emulating a function. Its a very high level language, so to speak, built on a high language.

This is true for any export platform. For my game, I basically stripped out the functions and put them in behaviors. It allowed me to up my object count and still stay within a performance goal.

....

I'm going to go ahaead and post this and then answer the rest of your questions in another post. 1 sec

Solomon - I create objects solely to house certain variables. I'll use local variables if need be, but generally I orginize according to purpose and name the objects so that it makes sense. For example, I always have an object called level. When I want to know something about the current level, I just say level.something = whatever. I follow this format for all my global variables. In this way I find that, though I do forget their names, they are not cluttering up my expressions list and whatnot. I can't stand trying to find a variable because I don't know its name and having to sift through hundreds of others. So long as I remember what the variable is used for (which hopefully I do as I am about to use it) I can then locate the object that it is tied to.

Common objects I use to house variables : CharacterLaws, CharacterAttributes, Level, Global, Input, and so on. Sometimes I use cmv and read those for attributes and laws(or constants as most call them - Constants that govern my game universe I usually call laws)

As far as functions go I usually don't overuse them. I like dynamic systems but it really eats at performance in a big game unfortunately. Instead, I like to script recuring events out into behaviors. I then gain a performance boost by bypassing the event sheet which has its own overhead. In the end I can have a complex set of scripts and only a hundred or so actions tying them all together. They are not usually versatile, but thats not the point lol.

At the end of the day I would love to use gloabl variables... but they need to be able to be organized and accessed via name.name.

As it is I even name every variable in the game, local or otherwise, vSomething that way I can always find them in one spot in the expressions when they come up. You just type v and then you can see all the variables.

That and an option to filter variables by event sheet while picking them, sort of a folder category.

So if you have 3 event sheets with variables, and they are to run together, when picking variables you can toggle tick which to view.

That would help with searching through the gazillon variables.

I'd get behind this too.

Its because of this I don't use global variables. at all. I use some local variables but mostly I create objects with variables on them. I've even considered making an empty plugin except for variable stuff.

I messed a little bit with it a year ago or so. I even messed around with shaders too. I remember my conclusion but not the specifics that led me there. I would suggest using unity, udk, or other engine that has this sort of thing built in. Unity with 2d toolkit was my favorite.

If I recall I didn't 1.) like the way the bump mapping worked, 2.) I didn't like the work flow in construct for adding the effect, 3.) the results weren't good compared to a 3d engine, 4.) You could only have 1 light source I think.

All in all construct 2 is a great tool, but bump mapping sort of is beyond what it was made for currently. Maybe in the future we can get a good lighting system going on. I think it would be awesome to have a more sophisticated rendering system and what not, but hey this is a 2d engine, not 3d.

Zebbi I'll try to get something up that can be shared in the next day or two when I get a chance. I'll post it in tutorials or something, but I'll let you know.

chrisbrobs - thanks, I'll check it out when I get a chance!

> purplemonkey Nope. It's impossible to do without a custom or event-based behavior. I had one person who was interested in doing this but it was never finished.

>

Dang it, thanks for trying though! Ah well, I guess I have to implement some dank code instead..

Zebbi

I found a quick solution for disabling collisions on specific objects, etc. and would be willing to share it! Its a stupid trick but gets the job done.

I added prismatics and kinematics a while back. If thats useful, I can point you to where I discuss how to do it.

chrisbrobs hm - I'm not sure. Imagine laying out an rgb color space onto a 2d texture. it could represent 255*255*255 colors or 2*2*2. It really doesn't matter. Obviously the color space and the texture size go hand in hand.

In the original image you then use the rgb value to essentially get texture coordinates for the look up table/ texture. Red = x, green = y, x+= blue * 255. In this case the lookup table is a very wide image where blocks of red and green have been laid out with increasing blue value. Does that make sense? The lookup table can then be altered anyway you like. You could make it super small and force a limited palette, you could use photshop to alter the levels and so on. The advantage is that you can have mathematically complex color conversions, arbitrary filters, etc, all at a low cost. The downside is that you have to create the lookup tables ahead of time.

The end result is that you can get an incredible amount of diversity of assets without creating that many assets. It also makes it possible in 3d games to have a general lighting scheme and then use lookup filters to drastically alter the mood of the scene. It has some great uses. Essentially you could even use it as a shade, tint, etc tool. Or hsv. But it works more efficiently than actually mathematically calculating/converting from rgb -> hsv -> change values ->rgb. This is most pronounced when doing lab space color corrections.

If none of this makes sense, check out this link. It is for Unity's color lookup, but the same principle can be applied to c2!

http://docs.unity3d.com/Manual/script-C ... ookup.html

As is mentioned and worth noting again is the fact that you can use photoshop to generate the color transforms. Basically you could take a scene from the game and apply filters/levels/etc until you like the way it looks. You then do the same thing to the lookup texture. and poof! quality color correction <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile"> and at a very low cost.

R0J0hound - that makes sense. I'll have to check that out. I might have to mess with the way you said to do it... The problem that I can see though is that you couldn't apply it to a layer or layout, which is suboptimal, but hey it may work. It just seems like Construct 2 should have a place to put textures, that you could feed to your shaders.