Another question about Construct

Ok, the way game maker (the program i used to use for making games) is done is the coding in your game has to be turned into a different scripting language, then another, and finally it gets read by the computer. it is obviously slow, not just because of that, but slow in general.

i was wondering how construct is done? how much can i push this program before it lags and stuff? in game maker, for example, my AI script lagged my comptuer when 3 AI's where on the screen at once..considering it is a 2d game, and very basic, it is not very desirable to have that happen. Also, i see this has a bit of 3d functions too, which game maker also supports, but being such a small program, the creator is restricted to models with low pollies/quality and what not.

so, summing up:

how much can this program handle? 2d, and 3'd wise (whats the highest quality game i am expecting to make, etc)

Please remember, i am a user of programs such as this, i don't develop them, so my understanding in these areas is rather low.

I've worked hard to optimise Construct so it runs as fast as possible. Firstly there's the parallel drawing and event processing: the game code is run by the CPU while the screen is drawn by the GPU, so the framerate is determined by whichever takes longest (which is 99% of the time, the drawing). Essentially this means 99% of the time the game code has no effect on performance.

I don't have up-to-date figures on Construct's event performance, but my last test showed a simple event could run in 201 cycles, which very roughly approximates to running that event 15,000,000 times per second on 3ghz processors. In practice it will be less because you'll use more complex events, but it shows you can run millions of events per second. It's fast.

And as for the display performance, it's basically defined by your graphics card. My card (Radeon 9800 Pro) is several years old now and not a patch on today's technology, but it can crank out around 5,000 on-screen linearly filtered continuously rotating sprites at V-sync rate, which I don't think is too bad <img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" /> Not many games will reach 5000 sprites, let alone 5000 sprites on screen at once, so I doubt that'll be a problem!

If you use pixel shaders, they are the most GPU intensive of all, especially intensive effects like blur, and these will usually be what slows down your game. You can always turn off some effects or use 'cheaper' versions (eg. additive blend instead of screen). However how fast shaders run is just how fast your graphics card is, Construct doesn't intervene other than to issue the command "draw this shader".

Essentially if your game ever runs slow, you're probably peaking the performance of your hardware, and you'll probably be doing that with pixel shaders. Still, if your game runs slow and you don't know why, gimme a shout and I'll see if I can help you <img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" />

Ok, thanks. When i mentioned my game running slow, it was when using the game maker program. At most, 3 of my NPC's had at -most- 1000 events running at the same time, and it lagged my system:

AMD athlon 64 X2 Dual

Core Processor 4800+

2.50 GHZ, 2.00 GB of ram,

so i truly doubt i was 'over doing' my computer <img src="{SMILIES_PATH}/icon_lol.gif" alt=":lol:" title="Laughing" />

i shall see how i go with construct once i learn how to get started :p

When i mentioned my game running slow, it was when using the game maker program. At most, 3 of my NPC's had at -most- 1000 events running at the same time, and it lagged my system:

One thing you should know before using Construct: it is very different from Game Maker.

Instead of defining every action and event on a per-object basis, there is an "even sheet" that is separate from your objects. This means that instead of putting, say, control actions in your player object, you tell the event list to get the input, and then tell the event list how to move your player sprite. And instead of 1000 events per NPC object (for 3000 events total), you would just have to put that 1000 events in your event list one time, and each NPC would use that single list. All higher quality game dev programs use this method, from Construct to Torque to MMF, etc.

Game Maker by comparison is a clunky, inefficient piece of junk. For instance, the "Your First Game: Catch the Clown" tutorial is almost two and a half megabytes when it's compiled, and that's just for a single sprite that bounces around the screen for you to click on. And when you run that program, GM is so choked up that that single sprite is jittery and blurry.

I made a platformer demo from scratch in Construct in under a day, which has twenty-seven 3D objects, a player sprite with animation, and a tiled, parallax scrolling background. The .exe it exported is only one megabyte, and... get this... there are only 15 events in the whole program. Eight of those are events that manually make one of the 3D objects do something that it's not designed to do automatically. And it runs as smooth as silk on my crappy-ass computer.

So yeah, it's fast. And it's efficient. And even though it's just in beta right now, and still has a few buggy problems, it's a damned sight better than GM. I've read that Yoyo Games is re-writing GM from scratch in C++ so version 8.0 should be a bit faster, maybe even "twice as fast." Construct by comparison is already hundreds of times faster.

Also, Construct will probably be a little confusing at first if you're used to GM. After using it a while, though, I think you'll see how it's more logically organized and ultimately easier to use. GM is just so backwards it boggles my mind.

Hehe, thats good to hear. I am making a game with game maker as you know now, which i stopped because of lag problems. i figured if it was going to lag so bad with such basic stuff i shouldnt waste my time with it, and im not.i will begin to learn construct.

Out of curiosity, did you ever make maps for Age Of Empires II?

That had an event system which works the same way as Construct.

The basic gist is thus:

Selection Conditions

Construct has a list of conditions and actions (the event sheet editor). It scans this list from top to bottom, then scans it again, then again, and again, every time a new frame is drawn. The most basic condition is:

Always

This condition will trigger on EVERY pass of the events. So if we drew 100 boxes and did this:

Always

---Set X position of BOX to box.xpos + 1

...It would move the boxes to the right by 1 pixel on every frame.

In addition, Construct assumes by default that you mean ALL the boxes. So EVERY box will move.

If we want to set specific boxes to move, we have to narrow Construct's 'object focus' down using other conditions.

So we could do this:

X position of BOX > 320

---Set X position of BOX to box.xpos + 1

The condition basically says 'Is X position of BOX greater than 320 pixels?'

It scans EVERY box, literally asking it 'where are you?' and then it strikes off the list all boxes that don't match the criteria you gave it.

So when it comes to process the action, only the objects with an X position of 320px or more will move. You'll basically see the objects on the right-hand-side of the screen move, and the left will stay where they are.

You can enhance this further with more conditions:

X position of BOX > 320

Private Variable 'Health' > 20

---Set X position of BOX to box.xpos + 1

This narrows its selection down, first selecting only those on the right-hand side of the screen.

Then, OF THOSE OBJECTS STILL SELECTED, it checks whether their health is greater than 20.

So now when it processes the action, it only moves the ones on the right that have a health value of 20 or more. Weaker boxes, even though they're on the right, will not move.

This concept is ultimately like using a database. I don't know if you've used databases much, but it's a bit like having a list of names and saying

"Select all names, where county is 'Surrey', town is 'Caterham', 'Street' is 'Beggars Green'"

It's that kind of thing, but with objects.

This way, you can decide whether your code will apply to just one of many objects, or to a group of objects, or to all objects.

Trigger Conditions

These conditions are a teensy bit different. Normally, Construct just processes the event list from top to bottom, then does it again, then again, then again.

However, some conditions can be Triggered. These include:

'On Function' and 'On Start of Layout'

We can have an event like this:

On Function 'Move'

X position of BOX > 320

Private Variable 'Health' > 20

---Set X position of BOX to box.xpos + 1

And it will normally be skipped by Construct as it scans the list (because 'On Function "Move"' has not been triggered).

However, we can trigger it from inside another event by doing this action:

Run Function 'Move'

Then suddenly, it pauses everything and looks for all the events that start with 'On Function "Move"'. It will process them all, in the order they appear in the event list.

When it's done 'em all, Construct goes back to where it was and continues as normal.

So this way, you can run loops and functions and stuff from within other events, and they will be processed instantly.

That's basically how it all works. You use Trigger Conditions, to make sure something is only tested when you want it to be. And you use Selection conditions to narrow down which objects will be affected by this event. Then you define actions that will happen.

Wow, I'm impressed, this should be adapted in to some kind of article <img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" /> When I open the Learn section of the site an article on how conditions works like this would be good.

Also the explaination of the collisions on the 3D box object was very good.. why to not open an official wiki for putting togeter all the knowledge base about Construct?

Everybody could contribute and it would be perfectly in line with the open-source spirit of the project.

That's a great idea. I'll see about putting one together.