Making big games on C2

I totally get what you're saying — Doing games like beat em ups on the scale I planned them quickly became confusing piles of stuff that was really hard to follow, especially after a week or two without touching the project. This is why I'm going for such a technically simple game right now.

I too am an artist, so the "big game" I'm talking about is just big on the graphical scale and lengthwise. Lots of animations and characters, large pieces that I use to build the scenes, GL effects, you name it. Technically the game is probably going to be puzzles in form of minigames and physics puzzles. Outside the puzzles it's just a side scroller with a dialogue system and bunch of events to control the characters movement and animations in and out of cutscenes. I even made it so I can use a single object for all the characters to lessen the amount of events, hassling with families and all that could just bloat up the events. After reading the replies on this thread I've come to a conclusion that the game I've planned is possible to do in C2. Maybe after I either finish or scrap this project I'll look into Unity or Unreal 4, or even coding. Right now I have a good grasp of programming logic that I've learned from C2 and hope that it could be of some use in learning programming in the future.

newt Yeah, that's true, same for every game though generally

jayderyu Well yeah, but Unity has a lot of first-party control over their own layers, although my layer list was actually based on exported games from Construct Classic Also, Node-Webkit is quite a bit bigger in size than 15mb but for large games it's probably the least of our concerns.

Ruskul Definitely to everything you said, also how some things that should work don't always work (eg: nested sub-events and loops, families, picking, collision, etc) and get really strange when framerate drops below target.

Good luck on your game Hasuak!

Jayjay, thanks! I'll do my best! To be honest I've never before felt this happy to make a game. The aim for as simple events as possible must be the reason. Every time I tried to make my game work it'd just become such a mess that working on it felt more like a chore than a worthwhile activity. On this project I can focus on writing and visuals much more than before. You might just find it in the WIP forums sometime soon

I'm still very very satisfied by how well a C2 game can run, even on old hardware.

My game runs very smoothly even on crappy laptops now, I'm impressed.

You definitely can push hard on C2, and have tons of ressources with no problem. It does a superb job at managing/optimizing the memory for you.

As jobel mentioned it, I had some problems with people wanting to stream some Penelope footage.

Half of these problems were only because of me (you would want to have a look at "delta time" management way more closely than I did) as I didn't test enough my game in extreme conditions (under 15fps or at more than 100fps on top end monitors).

The other half is how the frameskip is handled in C2. 40fps doesn't look like 40fps but sometimes feel more like 20, and when people stream the game in bad conditions (play+local record+ online stream on poor setup) it shoes. For normal use, aka only play the game at 60fps on many many machines, you can be sure it will compare very well with games made using Unity or GM. Again, even 2 years later, I'm still happily surprised by the C2 perfs.

Honestly, if you're not interested in consoles (<be really sure of this, all consoles), I don't see why you shouldn't pick C2 for your game. No engine is perfect, and this one is very good, very fast, very cheap and have a GUI designed by a brilliant mind. Wish you the best with your game!

Coming from Aurel, this is all you guys need regarding C2 and "Big Games" for PCs.

In my limited experience, it works just fine baring some fixable issues (Node Webkit relying on Chromium which Google messed up for a few versions). But these are fixable issues, yes, it requires a bit of troubleshooting.

ps. C2 for PC/MAC has excellent memory handling of large amounts of sprite & art assets.

>

> > The key is to avoid per-instance work for every instance in the layout, and to narrow the scope only to the active/visible area of the layout.

> >

>

> What exactly does per-instance work mean?

>

Ashley

I'm also interested into some more details on this one.

If you are scaling a layout to thousands or tens of thousands of objects, then you basically don't want to do any work for each instance ("per-instance"), because even a small amount of work x10,000 = lots of work!

The blog post I linked to covers how to make sure neither you nor the C2 engine has to do per-instance work, so you can get to tens of thousands of objects without severe impact to CPU time.

Everade

What exactly does per-instance work mean?

An instance means 1 copy of an object.

Say if you have a bunch of enemies (copies of 1 object you created) in your game called "Enemy" and there have been many created, some not even being visible in the "view" but they are there in the game. He's saying try not to continually reference those objects that the player can't even see.

i.e. a collision event trigger

Enemy On collision with Rock ---- DO THIS

instead only do this code for when the player is seeing it. That way you avoid doing all this processing while no one is even seeing it.

(Or you can make the object Collisions DISABLED, unless they are on the screen.)

so instead:

Enemy On collision with Rock

AND Enemy is OnScreen --- DO THIS

Honestly, if you're not interested in consoles (<be really sure of this, all consoles), I don't see why you shouldn't pick C2 for your game. No engine is perfect, and this one is very good, very fast, very cheap and have a GUI designed by a brilliant mind. Wish you the best with your game!

this pretty much sums it up...^^

We're developing a rather large scale game (check my signature for info) with a huge map where thousand instances interact (plants, animals, objects). C2 allows that, you can be sure of this, it heavily depends on your skills.

>Enemy On collision with Rock

AND Enemy is OnScreen --- DO THIS

As far as I know, the engine works in a way that it checks collisions for every object every tick.

The "Enemy On collision with Rock AND Enemy is OnScreen" event will only trigger when an enemy is collided with a rock and it happened on screen. The engine still checks for collisions for every object (not sure for the objects off-screen), but you can turn off this by setting the "Collisions" setting to "Disabled" in the object's properties.

>

> >Enemy On collision with Rock

> AND Enemy is OnScreen --- DO THIS

>

As far as I know, the engine works in a way that it checks collisions for every object every tick.

The "Enemy On collision with Rock AND Enemy is OnScreen" event will only trigger when an enemy is collided with a rock and it happened on screen. The engine still checks for collisions for every object (not sure for the objects off-screen), but you can turn off this by setting the "Collisions" setting to "Disabled" in the object's properties.

it checks every tick only if you tell the engine to do collision checks every tick, or if a behavior does so, in that case though, there is indeed a sort of conflict: either first picking the on screen ones (which will reduce the number of collisions to check on medium and small games), or do it by checking the collision first, then seeing if the ennemies are on screen to pull of the actions (in large scaled games, this has a big benefit due to the existence of collisions cells to skip some, which can reduce by a lot the collisions depending on the type of game).

>

> >Enemy On collision with Rock

> AND Enemy is OnScreen --- DO THIS

>

As far as I know, the engine works in a way that it checks collisions for every object every tick.

The "Enemy On collision with Rock AND Enemy is OnScreen" event will only trigger when an enemy is collided with a rock and it happened on screen. The engine still checks for collisions for every object (not sure for the objects off-screen), but you can turn off this by setting the "Collisions" setting to "Disabled" in the object's properties.

Yes exactly, shutting off collisions when not on the screen will definitely improve performance. There's a good tutorial on that. I just was trying to explain it in simple terms don't process objects that are not on the screen. Better to get the UID of the specific object you want or only deal with the ones the player can see. The question was "what is dealing with per-instance objects?".

Making large games: those lengthy, or full of features or both, is absolutely doable as long as you understand how C2 works, what does work best and what the limitations are. Plus you need a lot time and grit. I've made some insanely complicated state machines in the past, that worked 100% and along side each other. And hope to finish those currently alpha programs, but with time I've learned that keeping it simple is healthier for your project and your sanity.

In terms of optimization, if your game is very dynamic, ( and I wander what you guys think about my way ), I'd personally would rather go with:

Every X seconds

For each object:

-distance() <= xxx

-- Set collisions ON

-- Turn movement behaviors On

-- set FX On

Etc

-Else

-distance() >= xxx

--Trigger once

-- Turn movement behaviors Off

-- Set collisions Off

-- set FX Off

The reason I went with Distance instead of Is on screen, is because I'd rather have the moving objects doing their thing before I see them to avoid awkward moments where you can see static object for a moment "turning itself" On.

The reason I went with Distance instead of Is on screen, is because I'd rather have the moving objects doing their thing before I see them to avoid awkward moments where you can see static object for a moment "turning itself" On.

sure for movement stuff that makes sense... but other AI behavior that is less visible OnScreen works.

I mean, it all depends on the game and what your objects are doing when not in the players viewport.

Every X seconds

For each object:

-distance() <= xxx

-- Set collisions ON

-- Turn movement behaviors On

-- set FX On

Etc

-Else

-distance() >= xxx

--Trigger once

-- Turn movement behaviors Off

-- Set collisions Off

-- set FX Off

Hey thanks! This is very nice. I might even add some physics settings in there too, changing the stepping/performance to lower depending on the object's speed and disable them when the object has stopped. I've been planning on having some physics objects on the background that would shake and fall if you ran past them, jumped, etc.

Every X seconds

For each object:

-distance() <= xxx

-- Set collisions ON

-- Turn movement behaviors On

-- set FX On

Etc

-Else

-distance() >= xxx

--Trigger once

-- Turn movement behaviors Off

-- Set collisions Off

-- set FX Off

Is there much of an optimization difference between turning movement, collisions, etc off rather than just setting the object's timescale to 0?

I'm currently using using timescale myself, and figured if the object was essentially paused it wouldn't take up any cpu overhead, but am unsure if that is the case.