Lazy load elements / Load scenario in realtime

0 favourites
  • 5 posts
From the Asset Store
This artwork is best to make a endless side scrolling games.
  • Hi everyone,

    I really dont know how to ask, but i'll try to explain. For my next project i'll make a top-view car game (like GTA I and II) based on Mad Max scenario.

    My first problem when I scretch the concept is the need of a huge map with many objects on it (Player can do a car travel through many cities without load screens).

    in my head, the solution is a lazy loader who create and destroy elements based on screenview edges. A database will be need for preserve the object state for a future need.

    This idea is the right way? There is some easy way to do that? Anyone already try it?

    Tks.

  • I am doing something similair.

    I do this lazy loading with dynamic objects which use behaviours for player interaction. Like enemies.

    I use a distance check on an object, which has lists of items to be spawned, and keeps track what gets killed.

    If you get out of range, the objects return to the spawn point and get destroyed there. As soon as all spawned options been spawned and enemies destroyed, the spawn point gets destoyed or gets a boolean to avoid avoid unneeded distance checks..

    Having distance checks might not be ideal .. but you can use all sorts of triggers ..

    for example, on an entrance to a big piece of the level, have some hidden image in the beginning, and on overlap, trigger events needed for spawning and creating objects.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Wow, nice solutions lennaert. Thanks.

    My great problem right now is how store this object states to return then later.

    To static objects (like buildings) it is easy. But to NPCs, that will be running through the map, it will be more difficult. In that cases, i can left the objects running and only destroy the sprites and effects. But I dont have experience in C2 to judge if this will worth the effort.

    I'm trying to avoid that annoying thing - normal in 8/16bit games - when you run back for something that you just pass by and it no more exists.

    But thanks for sharing your exp.

    :)

  • Wow, nice solutions lennaert. Thanks.

    My great problem right now is how store this object states to return then later.

    To static objects (like buildings) it is easy. But to NPCs, that will be running through the map, it will be more difficult. In that cases, i can left the objects running and only destroy the sprites and effects. But I dont have experience in C2 to judge if this will worth the effort.

    I'm trying to avoid that annoying thing - normal in 8/16bit games - when you run back for something that you just pass by and it no more exists.

    But thanks for sharing your exp.

    :)

    I overcome the problem with instance variable from objects which get created and destroyed ... smart implementation of game mechanics.

    If my object is dependanton a certain value, and it woulld be just 1 object, then I could either stuff the data in a var, or even an array ... but if you have to do this for all enemies .... it becomes a pain ...

    So ... what I did, is make sure each enemy doesnt have references that need to carry over some create -> destroy -> create

    Image something like an enemy picked something up ... and needs to have it after a new created ... I simply did not implement such a method, as its too much hassle.

    Like with enemy health, if an enemy gets destroyed and recreated, it gets its health back after a new create ... i just envision that as being logical, you shouldnt have run away lol

    for objects that need to be there when I return later, I simply do not remove them.   If they have some dynamic behaviour tied to variables .. then simply only disable the behaviour to save CPU and enable with some method when needed.

    A lot of good mechanics comes down to applying a minimilistic KISS appraoch.

    If you have something thats really important to have it remember state, and destroy and comeback, you can always store something in a variable or array and get that data when you need it.   I would see this as a workaround, and not apply too many of them.

  • If my object is dependanton a certain value, and it woulld be just 1 object, then I could either stuff the data in a var, or even an array ... but if you have to do this for all enemies .... it becomes a pain ...

    Yeah, that is my first concern. I wish to avoid all the work in save all state data from each "free-running enemy" in my map.

    Now i can see many problems and unecessary work in my idea. Better turn back to scratch and change things before start the programming.

    <img src="smileys/smiley32.gif" border="0" align="middle" />

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