Re: [GD-Windows] Process communication

[Kent Q. <ken...@co...>]

Seems to me you're confusing two problems here:

a) Keeping a centralized set of assets everyone can use for development
b) Building the asset set for the game use

A system that's tuned for use by the game is probably going to be a mess
trying to update it during development, and vice-versa.

I suggest you make two systems -- one that's easy to maintain, and one
that's fast and compact for the game. Make the game software capable of
using both.

What we did (using Quake I's rudimentary but adequate-at-the-time .pak
file format) was make our game read all pakfiles AND the local
filesystem for all assets. The most recent version of the asset found
was used. It meant you could replace an asset simply by dropping a copy
into the local filesystem.

In your case, you're looking to use a networked system. What I'd do is
have your server keep a master directory that contains pointers to the
most current version of stuff, some of which will be in the master
archive file. Every night when no one's around, rebuild the master
archive from the most current assets. During the day, when someone
updates an asset, you just change the pointer in the directory.

If you need to make a local copy of the archive, you either have to wait
for it to build you a complete local copy, or you replicate the
directory functionality on the local machine.

I hope I haven't misunderstood your problem.

	Kent


David Hunt wrote:
> 
> Thanks Jon (*2;-)
> 
>     I'll look at DCOM. I'm not so much interested in managing multiple
> resources or versioning, we find Sourcesafe adequate for that. I'm more
> interested in developing a single monolihic (.wad) style file format
> Gigabytes large containing all final/production binary assets of the game.
> 
>     In order to keep this database safe and allow timely shared access to it
> I want to route all access to it through a server application (rather than
> treating it as one big shared file on our network).
> 
>     I also need to understand the file format from within the game which
> WILL just treat it as a big file (the game won't be a client, it will use a
> local copy).
> 
>     This isn't a massive versioning exercise - all I want is a high capacity
> pipe between myself and another application on another machine on our
> intranet.
> 
> David Hunt
> 
> ----- Original Message -----
> From: "Jon Watte" <hp...@mi...>
> To: "David Hunt" <da...@em...>;
> <gam...@li...>
> Sent: Monday, March 04, 2002 5:50 PM
> Subject: RE: [GD-Windows] Process communication
> 
> >
> > The official solution is DCOM. Unfortunately, that's about as far
> > from designed-for-games as you can come. In games, the real-time
> > nature of a message ("I want it now") is much more important than
> > something like "reliable, in-sequence delivery". This means that
> > any RPC-like mechanism is doomed to failure, except for non-time-
> > critical operations. Of course, those, you'd like to take care of
> > before the game even starts, using some protocol like rsync.
> >
> > In your problem description, it was somewhat un-clear whether you
> > were looking for a workflow/verioning system for in-house
> > development and release management, or a run-time remote data
> > management system. If what you meant was the former, I would
> > suggest Perforce because of it's fast and flexible revision
> > management, or possibly CVS because it's reliable and cheap.
> >
> > Cheers,
> >
> > / h+
> >
> > >     What mechanisms should I be looking at in Windows for remote
> > > inter-object communication?
> >
> >
> >
> 
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555

-- 
-----------------------------------------------------------------------
Kent Quirk                   | MindRover: "Astonishingly creative."
Game Architect               | Check it out!
ken...@co...      | http://www.mindrover.com/
_____________________________|_________________________________________