Limits for a REALLY FREAKIN' HUGE game

Post reply
0 favourites
  • 15 posts
From the Asset Store
Huge Monster Sounds Pack
$10 USD
A terrifying package of 101 professional-quality sound effects for monsters, small beasts, huge behemoths, dragons and m
daydream_Sound's avatar
daydream_Sound

  • Gooood day, ladies and digital-men!

    I'm planning a game set in a large-scale "sandbox-style" city with roads and buildings and everything in-between (except the kitchen sink...that might break the game...all that plumbing...).

    There will be very little changing of layouts - ultimately, I want the game to take place in one giant city. (Although, literally as I was just typing that, an idea occurred to me on how I could change layouts and yet still keep the semblance of a large city...more on that later.)

    My #1 concern is CPU/GPU overhead. Obviously, the more the computer has to compute, the more bogged down it's going to potentially get. Ashley & Co have been working miracles and wonders to make everything work as efficiently as possible so my concerns may not be all that warranted as they might have been had I tried this game on, say, C2. Still, I think it's important for me to begin keeping this detail amongst the top of my priorities.

    Here are some things I know of or I think I know of that will help to keep CPU usage down...

    - Keep related objects in folders. Objects that are directly associated with each other (ie: containers, objects pinned to another, etc) should all go into a folder. For reasons I cannot articulate, this just makes it easier for the computer to reference, drawn, manipulate, whatever every tick.

    - When dealing with road objects, specifically long road sections, having the road pieces stretch via height or length will obviously reduce the number of objects needed to be drawn on-screen (and less to track overall). I am, however, unaware of the use of a 9patch vs sprite vs tiled background will be of any benefit in terms of CPU usage.

    - Effects, WebGL, particle objects, etc, tend to be a bit more demanding on CPU/GPU. I should use these sparingly, even with the improvements to C3 runtime. ...... At least, this is my understanding. I fully welcome correction.

    - Objects off-screen are not readily drawn. So I don't need to tell C3 to draw objects as invisible when off-screen because they're literally NOT drawn given that you can't even see them anyway.

    That's all that comes to mind at the moment.

    Any and all suggestions would be greatly appreciated.

    Also, please go easy on me on technical jargon. I've been using C3 for a while, but some of the terms and such for more "professional" level of game design is still rather foreign to me. I may need to ask questions for clarification in order to make sure I know I understand what you're explaining.

    Also, my friend, SycrosD4, is teaming up with me and is very new to C3. He'll be handling the art-side of things and I'm sure he'll appreciate the info, too.

    Thank you everyone for your help and input!

  • Thank you, plinkie! I'll review those later today.

  • Your question reminded me of a post someone made here about a year ago. He was asking for help with his project, he shared a capx which was ~1Gb in size, and all objects were named like Sprite157 and Text93.

    So yeah, don't be like that guy! Careful planning and good organization is crucial in a big project. But since you are asking these question, you know this already :)

    .

    Making objects invisible when they are off-screen is not a bad idea. I don't know if this has been optimized in C3, but in C2 this helped to improve FPS and CPU usage by about 20-30% in one of my projects. I should mention that there were lots of effects applied to those objects. Also, where possible, disable behaviors and collisions for objects that are off-screen.

    9patch has lots of limitations, I definitely prefer TiledBackground.

  • Oh yeah, I do turn off collisions when necessary. My projects haven't been yet so demanding that I've noticed any difference however.

  • You could ask me since I'm doing this storage.googleapis.com/strawberrypunchbenchmark/index.html and it spawns thousands of sprites with x, y and z values and acceleration and drag for 3D movement for every single individual character with a bunch of sprites layered on each character for character customization

    That is absolutely amazing!

  • As ever the best way to deal with performance questions is rapidly mock something up and take real measurements. This will help you identify what the real problems are rather than speculating.

    I think with a large open-world style game the main issue you will come across is managing GPU memory efficiently. It would be all too easy to just load in hundreds of megabytes of textures for all the content and end up with really high system requirements. You'll need to make careful use of C3's memory management actions. Splitting content across layouts is a good idea if you can, since the C3 engine will then handle per-layout memory management for you (and it will also tend towards having fewer objects).

    Other than that, make sure you enable "render cells" for efficient drawing on large layouts, especially on layers with mostly static instances. Then, providing most of the far-away content is static, the engine is highly scalable (i.e. more or less able to work in constant time regardless of how much more content there is in the layout). If you have far-away objects moving or having events tested on them, this will consume more CPU time, but then this is entirely within your control as a game design issue and not an engine issue.

    One useful performance approach for open-world style games is to use overlap conditions to reduce the set of objects to run events on. Suppose you have 5000 instances spread across a huge layout. Normally a single event on that object will have a high CPU overhead, since it must test all 5000 instances. However you can take advantage of the efficiency of collision cells to reduce this. If you make a large invisible rectangular sprite as large as the area you want to count as "nearby", and then pin this on the player, the condition "is overlapping NearbySprite" is very efficient since it uses collision cells to reduce the instances to check against. In other words it won't check all 5000 instances - it will only check against nearby instances and then filter those down to the ones overlapping NearbySprite. Then you can add more conditions to the event, and the rest of the event runs efficiently only taking in to account nearby instances, without ever having to iterate everything in the layout. (If you're worried about the performance of collision checks, they're pretty fast, and in this case the main point is to improve the algorithmic efficiency, i.e. reducing the number of instances processed.)

    You can then extend this to a single "X is overlapping NearbySprite" event and all the rest of your logic for X in subevents beneath that. Then you have an efficient way to only run events for objects that are nearby - the amount of CPU time won't increase no matter how many far-away instances are added.

    I don't think anything else will prove to be as significant as those points. In particular using folders has zero impact on CPU usage, and the GPU rendering performance only relates to what's on-screen, so is naturally scalable regardless of the size of the layout.

  • If your game is for PC platform, I do not think it has any problem, C3 has very good performance. If it is for phone you will have to be very careful with memory usage.

    Also remember that disabling events using groups releases a lot of CPU.

  • Ashley and Taximan - EXCELLENT info/reminders!! Thank you for that very much. I'll surely keep that in mind.

  • WHAT are you two going on about?

    Ashley sorry to ask, but can you assist, please?

  • Also, Kyatric

    I tried "Report" button, but it doesn't work.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • Also, Kyatric

    I tried "Report" button, but it doesn't work.

    I can definitely confirm there were reports made about the problematic posts and the situation was moderated and bans were handed.

    dop2000 Could you possibly fill a bug report in the website part of github so this can be prevented from happening again please ?

    github.com/Scirra/Construct.net-website-bugs

    Rhindon : The report button is there so you do not need to post or notify an admin to deal with the situation.

    Things are getting ironed up but will soon be working without an issue.

  • dop2000Don't worry, the report button does work - Tom's been busy sorting out our mod tools, and we can see things you guys report!

  • Ah, sorry. Don't know how I missed it but I had overlooked tht report button. I'll keep that in mind if there's a "next time". Thank you, all.

Post reply
  • 15 posts
Return to board index
Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)