Making big games on C2

Discussion and feedback on Construct 2

Post » Fri Feb 20, 2015 12:55 am

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.
B
18
S
7
G
1
Posts: 783
Reputation: 4,247

Post » Fri Feb 20, 2015 1:47 am

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.
B
81
S
30
G
35
Posts: 340
Reputation: 23,046

Post » Fri Feb 20, 2015 2:02 am

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.
Image ImageImage
B
171
S
50
G
180
Posts: 8,396
Reputation: 113,986

Post » Fri Feb 20, 2015 2:07 pm

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...
Scirra Founder
B
400
S
236
G
89
Posts: 24,546
Reputation: 195,471

Post » Fri Feb 20, 2015 2:13 pm

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.
Construct Classic - Examples Kit Dropbox is a pile of trash and if you need my old files PM me! :)
B
125
S
43
G
17
Posts: 2,231
Reputation: 20,024

Post » Fri Feb 20, 2015 2:34 pm

Dont forget the final layer Jayjay, the app creator.
Image ImageImage
B
171
S
50
G
180
Posts: 8,396
Reputation: 113,986

Post » Fri Feb 20, 2015 2:37 pm

@Newt Well yes but you can only optimize after each of the layers below have taken their toll, and also there have indeed been big games in C2 like the ones on Steam that are listed earlier in this thread.
Construct Classic - Examples Kit Dropbox is a pile of trash and if you need my old files PM me! :)
B
125
S
43
G
17
Posts: 2,231
Reputation: 20,024

Post » Fri Feb 20, 2015 3:19 pm

Not that there aren't sub-layers to that.
Publishing, promotion, etc.
All kinds of third party support.
Image ImageImage
B
171
S
50
G
180
Posts: 8,396
Reputation: 113,986

Post » Fri Feb 20, 2015 3:42 pm

@JayJay
I just want to add something to your list. It's good in the order, but I want add this because a lot of people tend to gravitate using Unity or GameMaker as C2 optional alternative.

Unity
Exported Game
OpenGL/DX
Unity libraries that don't always meet C# standards(we have had basic classes of C# not work on mobile)
Unity Player
OS
Drivers
Hardware

unity Player is I found anywhere from 5mb to 15mb in size. It's packaged with all Unity games. Unity does not seem to output a pure game code system.
B
90
S
18
G
9
Posts: 2,455
Reputation: 15,038

Post » Fri Feb 20, 2015 4:42 pm

Ashley wrote: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?
B
21
S
7
G
4
Posts: 233
Reputation: 3,474

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 15 guests