January 2009
- [Design] on the game mechanics of open questing Siege)
- RANT: The Future of Quests Mike Rozak
- RANT: The Future of Quests Amanda Walker
- Players are shallow [was: The Future of Quests] cruise
- Players are shallow [was: The Future of Quests] Amanda Walker
- Players are shallow [was: The Future of Quests] Mike Sellers
- Players are shallow [was: The Future of Quests] John Buehler
- Players are shallow [was: The Future of Quests] cruise
- Players are shallow [was: The Future of Quests] John Buehler
- Wikia MUD project Raph Koster
- Wikia MUD project Nabil Maynard
- Wikia MUD project Raph Koster
- Wikia MUD project Peter Harkins
- Players are shallow [was: The Future of Quests] Mike Oxford
- Players are shallow [was: The Future of Quests] cruise
- Players are shallow [was: The Future of Quests] Damion Schubert
- Players are shallow [was: The Future of Quests] Threshold
- Players are shallow [was: The Future of Quests] John Buehler
- Players are shallow [was: The Future of Quests] Mike Sellers
- RANT: The Future of Quests Mike Sellers
- RANT: The Future of Quests Damion Schubert
- RANT: The Future of Quests Mike Rozak
- [DESIGN] How big is enough? Ian Hess
- [DESIGN] How big is enough? Mike Rozak
- [DESIGN] How big is enough? Mike Oxford
- [DESIGN] How big is enough? Vincent Archer
- [DESIGN] How big is enough? szii@sziisoft.com
- [DESIGN] How big is enough? Siege)
- [DESIGN] How big is enough? Threshold
- [DESIGN] How big is enough? David Johansson
- [DESIGN] How big is enough? Roger DuranĚona Vargas
- Persisting a MUD state with plain binary serialization Tiago
- Persisting a MUD state with plain binary serialization Jon Mayo
- Persisting a MUD state with plain binary serialization Jeffrey Kesselman
- Persisting a MUD state with plain binary serialization Chris White
- Persisting a MUD state with plain binary serialization Mike Oxford
- Persisting a MUD state with plain binary serialization Tiago
- Persisting a MUD state with plain binary serialization Jeffrey Kesselman
- Persisting a MUD state with plain binary serialization Mike Oxford
Jeffrey Kesselman wrote:
> On Thu, Feb 5, 2009 at 11:01 AM, Tiago <tiago.matias@gmail.com> wrote:
>
>>> Tiago wrote:
>>>
>>> Not sure what you mean by "binary serialization." Just copying out of
>>> memory won't work as I'm sure you're aware.
>>>
>>>
>> Well, by binary serialization, I was in fact refering to a facility
>> whithin.NET apps that simplify dumping an entire object graph do disk.
>> My biggestinterest in this was just the simplicity it offers. Just
>> callSerialize(World, filestream) and it's done.
>>
>> Problem is, like you might imagine, it's all or nothing. Anything
>> besidesthat very easily becomes a pain to implement. Another problem is
>> theversioning and upgrades (like you said). It effectively renders
>> datamigrations almost impossible.
>>
>> I'm considering manually serializing to XML some big game blocks like,
>> themap, the players, the mob's and the positions of these things in the
>> world.Then it would just be a matter of fixing the references as these
>> things aredeserialized back from the disk into memory
>>
>> The generated XML would obviously be human readable and writable and
>> wouldmake upgrading possible.
>>
>> Disadvantes: A lot more to code when what I would really want to be
>> doingwas programming MOB behaviour...
>>
>
>
> If you dont want to use a pre-built solution, have considered using a
> real RDBMS like mysql?
>
> Not that hard to use really (at least from Java thanks to JDBC) and very
> very flexible.
>
>
Along the same lines, it may be worth it to look at OODBMS as well.
Again, though, you have to
deal with the upgrade path yourself.
-mox - Persisting a MUD state with plain binary serialization Tiago.matias@gmail.com
- Persisting a MUD state with plain binary serialization Mike Oxford
- [DESIGN] Clojure? Matt Cruikshank
- [DESIGN] Clojure? Richard Tew
- [DESIGN] Clojure? Matt Cruikshank