Performance penalty when running game in a game using iFrame

Hi Ashley, all,

If i were to run one or many C2 games within a Game using the iFrame plugin, would this cause significant performance degradation?

Why yes: because C2 runtime, runs two or many times in parallel, creating both memory usage and processing overhead

Why no: because in the end all C2 game instances run on the same processor, and hence processing is time shared overhead is similar to running all games within one C2 game.

Which argument is correct?

If there is significant overhead could in principle the code be optimized to recognize multiple instances of C2 being loaded in a browser?

thank you,

Dan

C2 doesn't load in the browser, it is a desktop app... Your games(canvases) load in the browser. if you run multiple games via iFrame you are getting the overhead from all of them (unless they unfocused iframes pause themselves).

I have found very few cases where it is the CPU that is the bottleneck so the timesharing is less important than video memory unless all your games are physics games.

Hi BluePhaze,

(I just posted a reply but it seems to have gotten lost), so here again:

Indeed, my question was about performance of exported games. I am wondering if there is a difference in performance if "games inside games" are run within one exported C2 game or whether each run in an iFrame.

Daniel

p.s. I would need to check the non-focus item you mentioned. I would want the game inside the iFrame be responsive at all time, not only when it has focus.

It would probably be very slow, not because there's anything particularly inefficient about iframes, but just from the fact a typical game will use up a fair bit of CPU/GPU/memory, and running several at once will use a multiple of the system resources. Desktops might get by but I'd imagine it'd choke mobile devices.

What are you trying to do? Why are you asking the question? If you want to make a menu in an iframe, it's a very inefficient way to go about it since you get the overhead of an entire game engine just for the menu by itself. It'd be better just to design it in-game itself. However if you're making some kind of arcade, it would of course be better just to run one game at a time!

Thank you Ashley,

What i am trying to do is to break down my quiz game into game "components" with which to construct quiz screens. A component would be in part layout elements and in part associated events.

For example, I designed a visual keyboard (going from "A" to "Z", working in English and Hebrew), and want to include the keyboard in various quiz screens -- those for which an entry is required.

So, instead of replicating the keyboard layout elements and event sheet across all screens, I want to include a keyboard component only, as a whole, in a new quiz screen.

Using iFrame and HTML5 Messaging as implemented by the postMessage plugin seems to enable doing that. But, the overhead this would create may in the end be a bottleneck.

Dan

Btw, I understand that I can include events, and I am indeed making extensive use of "includes", for example, to "automatically" internationalize all Quiz screens. But, sometimes I need to include both layout elements and associated events, and C2 currently does not support such kind of combined reusable "components" "out of the box".

Do not use an iframe for that. What's stopping you designing it in one project only?

HI Ashley,

Thank you for your prompt response.

I can of course replicate the keyboard and other design elements across quiz layouts.

But, I am going to include the keyboard in, say, 15-20 screens, and duplicate other kinds of design elements across various screens, and as requirements change, and they will change, since we are doing participatory design -- I have to redo all screens, one at a time -- all layout elements that can not be reused. Its tedious and error prone.

It would have been nice if there is one location where I make the change and the change propagates across all layouts. Perhaps such modularity is not a strong requirements in game design, and my quiz game is unusual that it reuses design components across screens.

Dan

p.s. Also, i want to avoid parameterizing screens, and events, to facilitate reuse, since it reduces the readability of the event code, and there are always exceptions you need to deal with, which make things even more complex.

EDIT: Also, i think the simplicity of C2 event coding, which I appreicate a lot, is lost to a greater extend when I parameterize for reuse. I've tried it, and then i found myself spending time debugging reuse code rather than improve the games themselves.

Hi,

would it not be better to spawn the UI elements at the start of each layout. This way you just have one set of elements to change.

Thank you spongehammer.

The problem with Spawning is that they obscure the actual visual layout by pushing the layout elements into code. A key strength of C2 in my mind is that its visual programming which makes it easier to understand, program, maintain and change. This means that if you want to do reuse you have to move away from this paradigm.

BTW, the keyboard is mostly spawned from one letter, but there are still layout specific design elements included.

Dan

It would probably be very slow, not because there's anything particularly inefficient about iframes, but just from the fact a typical game will use up a fair bit of CPU/GPU/memory, and running several at once will use a multiple of the system resources. Desktops might get by but I'd imagine it'd choke mobile devices.

What are you trying to do? Why are you asking the question? If you want to make a menu in an iframe, it's a very inefficient way to go about it since you get the overhead of an entire game engine just for the menu by itself. It'd be better just to design it in-game itself. However if you're making some kind of arcade, it would of course be better just to run one game at a time!

I have an use-case for you: I'm designing a space game which has two "views": in the first, you control a character and can move around in a tile-based world. In the second, you control a ship in a arcade shooter style. You can freely switch between modes, since you can (and should) walk around in your ship during combat. However, both modes are so dissimilar that programming them is making my layout be a bit of a mess. Separating them in different layouts would be better, but switching between them during the gameplay causes noticeable delays. Also, both "modes" must run at the same time (since they must be kept in sync), even if only one is visible at a time.

Currently my approach is to code two engines and keep them in sync via shared variables, hiding one game and showing the other when appropriate. Is there a better way?

Keep in mind this is a desktop-only thing.

Designing it all in the same project would be better. Ideally we can improve the tools in the editor to make this more practical. I think the existing feature request for an "inheritence layer" would solve the keyboard issue. Not sure about the other case, but an in-game "sub-layout" view would be a lot more efficient than a whole new instance of the engine in an iframe. That could be quite a lot of work though, so I'm not sure we could do that soon...

I think an include layer would be indeed very good.

You mention inheritance -- do you actually mean inheritance in the Object Oriented sense?

I used to work (a long time ago) with a visual language (Digitalk Parts for Smalltalk), and visual components were in essence object instances (not unlike object type instances in C2), and you could freely subclass them, to add or customize specific behavior.

For example, consider having a named (layer/include event sheet pair), which you can include in another named (layer/include event sheet) to add additional objects types and events. Perhaps this makes sense too in C2.

Dan

Not sure about the other case, but an in-game "sub-layout" view would be a lot more efficient than a whole new instance of the engine in an iframe. That could be quite a lot of work though, so I'm not sure we could do that soon...

I'd love to see this, especially if it means we can code inventories/option menus and other complicated things in separate layouts. Would also help greatly with split-screen multiplayer (where most of the logic can be in the "main" frame, and the player's views can be kept in two sub-layouts).

I know you have a lot of stuff on your plate, but +1 to that feature

Also, i guess, a HUD would then go into an "inheritance layer" rather than replicate it across layouts.