How feasible is it to create a big game in one GIANT layout?

0 favourites
  • 10 posts
From the Asset Store
Fully commented source code/event sheet & sprites to create a space shooter game
  • I've always wondered this. If there were any limitations. Say you make a 16-bit zelda game and make the layout 160,000 x 160,000.

    Do you think there would be any problems? Or perhaps a really long initial load time?

    For PC/desktop not mobile

  • What do your initial tests reveal?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Thanks for responding. I realize I'm probably missing something really obvious but I searched and couldn't find anything.

    I spent a few moments made a big layout and got the character to walk. No loading times or slowdown. I'm just curious if anyone has tried it so I can commit to it without having to scrap a ton of work.

  • Its doable, but you have to balance everything.

    Tilemaps are ideal for this.

  • for an environnement that big, I would recommand indeed using tilemaps if possible to create the look of the environnement, it is less troublesome yet you will benefit from the fact they have "automatic render cells applied" (based on collisions cells technically, but that means that tilemaps can scale pretty well to very large sizes relative to the window size).

    in a zelda game, IIRC the ennemies are created when arriving to the screen, so you should not have many issues with them as they should be only present in the same part of the world as you, innfact, in most older games this "what is on screen exists, yet what is not doesn't" applies and that means that the system has much less things to handle.

    I would say very doable technically wise, of course demands works and efforts to be done correctly as most of the interactions are not handed to us with premade behaviors in that case, but if you know well zelda, you should be fine recreating how it works basically I would say.

  • It can be done but you have to design your game very carefully to avoid per-instance work. If you have instances across that entire layout, then presumably you will be dealing with tens of thousands of object instances, and any work that your events or the engine has to do for each of them will end up being slow - unless you limit the scope of the game to the currently active area. There's more information on designing scalable layouts in the blog post how render cells work.

    TBH it would probably be easier to just split up that size layout in to say 16000x16000 sections and jump between the layouts when you get to the edge.

  • in a zelda game, IIRC the ennemies are created when arriving to the screen, so you should not have many issues with them as they should be only present in the same part of the world as you,.

    That's great advice! I always find it fun to problem solve optimization issues.

    It can be done but you have to design your game very carefully to avoid per-instance work. If you have instances across that entire layout, then presumably you will be dealing with tens of thousands of object instances, and any work that your events or the engine has to do for each of them will end up being slow - unless you limit the scope of the game to the currently active area. There's more information on designing scalable layouts in the blog post scirra.com/blog/ashley/14/how-render-cells-work how render cells work.

    TBH it would probably be easier to just split up that size layout in to say 16000x16000 sections and jump between the layouts when you get to the edge.

    Thanks for your useful input and advice!

  • Yeah, I suppose it's possible, but I'm not sure what the real benefit would be. If you just want it to feel seamless, even using Ashley's suggestion of large layouts, just duplicate the edges of each layout, transfer at the edge, and if you line your camera and objects up properly, it'll look like nothing more than a brief stutter (unless you do something more elegant). I don't think map transfers really bother anyone, though...

  • Tottaly feasible! Using tile maps will be ideal and also know that you dont have to even have all the map loaded at once. you dont even really need instanced layouts that you jump back and forth. you could just be able to establish chunks in a manner similar to minecraft. In a 2d game draw distance is not really a issue that the player would notice given that they cant see the landscape popping into existence as they near.

    I would not know but likely you could just have a array with all the tiles planed out and tell the game to render them when you get within a x distance from the edge. Actually you then would not need a large layout as your player could remain within the center area and every 300 tiles just pop him back to the center with all the tiles moving with him. A "If Mohammad wont go to the mountain, the mountain will go to him" kind of thing. But I dont know what kind of load that would lay on the game. Id say go with it, it looks worth investigating and you can then let us know how that turns out.

  • This is just an idea... it might help blend with what you have in mind and with what Ashley and C-7 said, but if you load a giant layout as you have in mind, you might want to keep track of starting positions of objects by way of variables and then, when either 1) enter a certain region or 2) come within a certain proximity to where those objects would be, tell C2 actually create those objects and have them follow their normal behaviors. That way you're only loading objects in the immediate vicinity.

    This may or may not actually work, but may you could adapt it if it's somehow viable.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)