Making big games on C2

What should I take in consideration while making a large desktop game? Right now I'm working on something heavily inspired by the Valiant Hearts game, which is rather simple game gameplay-wise but has lots of animations, sound, music, scenes, events etc. Is such a game possible in C2's current state? How well does C2 support large desktop games and how optimized is it to handle large amounts of animations and events and such? And also is Web-Nodekit the best choice for a project like this?

I'm basically asking this because all I see are rather small arcade-y games coming from C2. Games that recycle lots of content and are very tight packages unlike any larger indie games made on custom engines.

looks like memory usage would be your key concern. If you're focusing on desktop only and plan on never ever releasing a console port, go with C2. If you're even slightly interested in taking your game to consoles when it is complete, I recommend not going with C2 as it stands right now. NO consoles have good HTML5 support for larger games / games with a higher memory requirement at the moment. Unfortunately I feel this is true even for the Wii U.

Well, it's all speculation at this point, but if Xbox universal apps ends up using a framework compatible with C2, I'd say you shouldn't have too much trouble with memory on that platform.

Thanks for the replies. I'm not going for consoles nor handheld devices, just PC and maybe iOS if the moons align correctly.

How does C2 handle memory usage? Does it load all the layouts simultaneously? I have one layout where I put all the objects that need specific default settings and variables and it has become quite a mess. Is this a good way of handling stuff like this or should I set all those things at the moment of spawning objects? Also do I need to hide objects that aren't on screen seperately to save memory?

Sorry for the tidal waves of questions. I'm just an artist so I don't know much about how game engines work.

How does C2 handle memory usage? Does it load all the layouts simultaneously? I have one layout where I put all the objects that need specific default settings and variables and it has become quite a mess. Is this a good way of handling stuff like this or should I set all those things at the moment of spawning objects? Also do I need to hide objects that aren't on screen seperately to save memory

If I remember right, Construct 2 has some built-in recycling to prevent as much jitter/jank as possible when Javascript does its garbage cleaning, it's handled internally so you wouldn't need to worry about it.

As long as those objects are just editor-side that layout shouldn't cause any troubles for you, I think it will be the default values if they're the only instance of them/set before copies are made in other layouts.

Construct 2 also handles the rendering on/off screen stuff itself internally in a manner that will probably be more efficient than events, but you can do extra things like making sure WebGL FX are applied to whole layers instead of multiple individual objects that are supposed to have it.

However, as for making big games in general, I would say give these a read:

native-desktop-exporter-for-construct-3_p879348?#p879348

native-desktop-exporter-for-construct-3_p879661?#p879661

Those are posts from developers of two of the three big "dream" game examples on the scirra homepage ( http://www.scirra.com/ ), and I too have a game on Steam with a friend I met on the forums here ( http://store.steampowered.com/app/334190/ ), and loading time can be quite a while for large games exported to EXE with Node-Webkit, we also had troubles with updates to C2 and updates to Node-Webkit (but this part should be better now that you can downgrade any time at: https://www.scirra.com/nwjs , we are currently using 0.10.5 for the best experience but 0.12.x is looking promising).

Even so, it should be possible to make a game like the one you referenced above, not sure how it would run in anything other than Node-Webkit though.

*technically*, Chrome/NW is fast enough to run a relatively intensive game on a large number of machines.

In reality, you may find yourself running into a lot of small (or not-so-small) issues that are *completely outside your control* to fix. Maybe these issues will all be gone in 1-2 years, maybe not.

The key issue is that there's literally nothing you can do about these issues when they come up, apart from filing a bug report to Chrome/NW and hoping they get to it.

You have to weigh the awesomeness of the editor against the risk of reliance on third parties who don't place games as their first priority. If you're relying on hitting a firm release date or getting income in time, proceed with caution.

I've had to push back my release date significantly because my game is literally unplayable below 60fps due to shocking input lag and jank. And I don't even know if Chrome knows about the issue yet, because I have to wait on Ashley to put together a js repro for them as they won't touch generated C2 code.

I'm working on a decently large game myself so I won't know that answer until I'm closer to finishing. But so far so good. In any game development project there are limitations. But I find those limitations help me be creative and I always manage to relay whatever I need to the player. Bottom line is you can make a great game with any tool. You just have to be somewhat familiar with what C2 can do well and try to keep with it's strengths.

I wish I produced a bunch of small games (with finishing touches) before I tackled this larger project I am currently working on. Seeing a game all the way through definitely teaches you something special, and can really help.

For example, those scenes in Valiant Hearts would take some serious setup time in C2. Not impossible, but tricky with all the timings. You're going to need to do a lot of "camera work" using tweening.. lerp or cosp. You might be able to come up with a good system on how to do it, but I'd try it first. Try to do like 15 seconds of one scene, and embed it in a one of the example games and you'll immediately see what your limitations and hurdles are...

For desktops, the major issue with C2 is that gameplay is very erratic when its below 60 fps as that is what the engine is designed to operate at. As long as you know the limits and optimize your game properly, it won't be a problem.

Thanks again for the replies. Things are becoming clearer now. So basically all I need to keep in mind is that optimization is number one priority. I'm well in the know about C2's limitations and have already cut some elements of my game according to them without hurting the final product. Performance-wise it's good to have a strong graphical style in mind and knowledge of how to keep it as light for the engine as possible. That's something I've finally begun to grasp. I don't even use that many WebGL effects anymore because most of those effects could be done in the graphics themselves.

But without rambling too much, all I can say is that I'm finally beginning to understand what to keep in mind while working on my project. Thanks guys!

I wish I produced a bunch of small games (with finishing touches) before I tackled this larger project I am currently working on. Seeing a game all the way through definitely teaches you something special, and can really help.

It's always best to star with small projects, but finishing them is not always necessary. I've done lots and lots of different test projects over the few years in C2 and learned much about streamlining things and how to make the project easier to control in the grand scale. Making beat em ups and a turn based RPG battle system is a good way to learn C2.

best to star with small projects, but finishing them is not always necessary. I've done lots and lots of different test projects over the few years in C2 and learned much about streamlining things and how to make the project easier to control in the grand scale.

yes I understand but that's not what I mean. When you actually finish a game -- completely finish and put those finishing touches on it. That's when a lot of stuff you never knew about comes out to play. When your core gameplay is complete and you get into the overarching gameplay, level design and "packaging" of your game, there's a whole new level of development that needs to happen.

Like sqiddster was saying about performance issues when you put the whole polished game to the test on multiple machines (playtesting). And other things that come out like, "The Next Penelope" not being able to stream on Twitch and some other issues with captures because of HTML5 etc... or Save Game data, or Leaderboards or Greenworks etc... it's definitely not easy!

you can make great game with Construct 2 but you have 0% guarantee that it will work well on any platform;

and 99% issues are because web browsers are not created for playing advanced games. That's why we have situations like jittering Chromium (and then Node-Webkit and Crosswalk). That's why C2 games usually use only 1 CPU core.

And if you will have any problems - just can just report the bug to some 3rd party company and wait for their mercy. And loose a few months waiting for bug fixing.

That's why Construct 2 is a wonderful toy, but it's not a professional game development tool.

The more I hear about big games and how they are in C2, the less I want to use it. If it weren't for the awesome editor, I would have moved on. I work on RPGs and RTS games, so I'm afraid to use any engine that I can't figure out since I have so much stuff to program. I'm an artist not a programmer. I hope to get one of my games out this year, but reading things like this make me worried.

I'm going to have a bunch of prerendered 3d animations, and the games are isometric. I'm keeping the map size small the amount of units small though. My RPG prototype stayed mostly under 10 cpu usage in 10.5 node webkit, with occasional jumps up but still under 15 most of the time. I'm using that same prototype for my RTS. At least with these types of games I don't have to worry about framerate as much since they are still playable if it goes down (albeit they will look jittery). I still try to keep everything at 60fps.

As usual a lot of speculation.

Your options are learn to code, or use C2.

Thats about a simple as it gets for now, as nobody has made a "big" game with it.

That is to say nobody was able, or willing, to work within its specific limitations.

Not that you won't suffer just as many, if not more on any other platform, engine, codebase, etc.

The C2 engine is designed to scale well with large games. Collision cells in particular help large layouts with a lot of activity keep running fast. There's more information in the blog post about render cells on how to design large layouts that still run well. 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.

Browser vendors are far more receptive to bug reports than driver vendors BTW, so if you're worried about problems caused by third parties, driver bugs are a far worse and far more significant problem with native engines! I'll take the browser vendors any day...

The layers of a native engine:

Your exported game

DirectX/OpenGL engine (partially third party, but a lot of control is still there)

Your OS*

Your drivers (driver vendor issues)*

Your hardware*

The layers in a Node-Webkit desktop game:

Your exported game

HTML5 + WebGL "engine"

Node-webkit *

Chromium (browser vendor)*

Your OS*

Your drivers (driver vendor issues)*

Your hardware*

* = third party

I don't see how adding the extra layers that a third party controls will make it less likely for a game to run into issues that only a third party can solve.

Eg: If NVIDIA has an issue rendering OpenGL/WebGL, then I still have a driver vendor issue on top of whatever browser vendor issues I have. Sure, maybe it takes the "contacting driver vendors" part away on this end, but that just adds it to the browser vendor's side, which just feels like even less control over the situation no matter how big the browser vendor is.