16 Responses

Page 1 of 1
  1. Twi
    Twi July 10, 2010 at 5:14 pm |

    Save games, yaaaaaaaaay!

  2. Kamron3
    Kamron3 July 10, 2010 at 7:27 pm |

    Just save the packets destination, rather than both location and destination. So whenever they load the game, the game will immediately remember the locations where packets need to go and will send them out normally.

  3. Danielm
    Danielm July 10, 2010 at 10:52 pm |

    The ability to save games would make those long levels just that little bit easier 🙂

    What do you mean by a ‘gray’ market?

  4. Where can i get a 55% complete GTA IV save game file? | games answers

    […] Save Games […]

  5. UpperKEES
    UpperKEES July 17, 2010 at 7:32 pm |

    Great! It will definitely increase the replayability when you can skip the energy generation part the second time and concentrate on fighting the creeper to improve your score. 🙂

    Regarding the implementation: I’m not sure why you call assigning the references in a later stage ‘lazy’. This practice is very common when you for instance read many related objects from a database (which is no different than from a file). Just cycle through them after loading the basic info of all objects and assign the pointers/references by using the related UIDs. A good (indexed) Find-function will speed up this process a lot, so I hope your data structure provides something like that.

    Of course a recursive method (and order of saving your objects) looks kind of neat, but you start getting into trouble when an object is referenced multiple times (one-to-many relationships, not to speak of many-to-many relationships). I would certainly avoid the potential problems this could introduce. Doing that second step will also allow you to make sure all objects are there and every reference is valid. Another advantage will be that all objects will be grouped nicely together in the data file. When you have all your dependencies straightened out (a DB design tool might help here), the save/load order will be evident.

    Good luck solving your puzzle!

  6. jstudio
    jstudio July 18, 2010 at 5:52 am |

    This is the best idea for long maps.

  7. Matthew
    Matthew July 20, 2010 at 10:29 pm |

    Thanks for these blog posts! I (and apatently many others) enjoy nerding out by reading them! I find these posts very interesting! Thanks again!

    AKA: Katanna

  8. Jimmy
    Jimmy November 8, 2010 at 6:02 pm |

    UID’s are necessary in saving a game where targets need to be persistent, but there shouldn’t be a reason you can’t easily resolve a circular reference.

    You just need to maintain a list of items which have unloaded references, then each time you load an item, check the unloaded references for its UID, and fill it in. By the time you load the last item, all the references will be available(assuming the save file is valid), and the last of the missing references will be filled.

    The other option, which would require a more complicated save method, would be to store all the target references in a separate section and apply them after the objects are loaded.

    I would be more inclined to take that approach, since I would also want to separate sections for common data, such as positioning, hp, etc., from unit specific data such as special emitter speed. That way the loading process is organized by property type, instead of whole objects

  9. Alex
    Alex December 29, 2010 at 7:24 pm |

    Why don’t you make it so that after you load a saved game the saved game gets destroyed?

Comments are closed.