gamedevlists-general — List for discussing general game development issues

Re: [GD-General] Online collaboration site?

[Brian H. <ho...@py...>]

We're doing distributed development, and so far it works=
 extremely 
well.

For source management we're using CVS -- it works with Windows,=
 Linux 
and OS X, so we're covered there.

For asset management we use Unison, which is like rsync but with=
 
bidirectional capability.  I can't say enough good things about=
 it.  
It's also free, which is a good thing I should mention.

For communication, we use ICQ + e-mail + phone.

For copying specific files around where unifying assets is=
 overkill 
and simple SCP works.  For common files, I write Bash scripts and=
 
just have my artist click on a desktop icon -- the Bash script 
changes directory, scp's a zipped file down, unzips it, then=
 exits.  
That's how she gets the latest executable.

For hardcore collaboration and/or debugging on a remote system, I=
 use 
GoToMyPC.com, which lets me take over selected systems to see=
 what 
crashed and why.  I can also install and update scripts, tools,=
 etc. 
without forcing the artist to deal with the gory details of=
 Cygwin or 
what have you.

So far it's working fantastically great.  We still need to find a=
 
good virtual whiteboard so visual things can be shared a bit=
 better.

Brian

Re: [GD-General] Online collaboration site?

[<mi...@ub...>]

there are many 'Content Management Systems' if you search freshmeat.net - they are varying in quality and useability, but most will serve the basic purpose.

i am currently using a little opensource project called 'phprojekt' for my team's online collaboration. it provides real-time chat, forums, contact manager, content manager (for documents, etc, with ratings, comments, etc), web publisher (for publishing content onto a website viewable by the public), file manager (with basic version control), project manager, timecard manager (for billable hours per project), and best of all - a helpdesk for logging support bugs and other 'technical support' issues.  

it also has integrated imap mail for checking pop3, etc from a web-based interface. i use it for all my email currently, have for a few weeks now.

funny you asked, as i was just discussing with my hosting partner the possibility of setting up a service for providing 'hosted' versions of the software for small businesses - licensed on a per-user basis, per-month, much like similar online 'hosted' CRM packages such as salesforce.com and others...

anyways, the project site is at www.phprojekt.com.

cheers

mike w
www.uber-geek.ca 







>I'm working on a little game with a few other people 
>who are not in my town, and I'm wondering if there 
>are any web sites that would assist in remote 
>artist/developer collaboration, and storage of game 
>assets.
>
>I'm thinking it would need to have remote storage 
>(hard drive space), some sort of rudimentary source 
>control system, and document tracking features. 
>Basically, a central point that would serve as a hub 
>to store design docs, code files, art assests, 
>schedules, etc.
>
>It seems like there's got to be something out there, 
>but I haven't had any luck finding it after quite a 
>bit of searching. Any ideas?
>
>- Jason Bay

Re: [GD-General] Online collaboration site?

[Thatcher U. <tu...@tu...>]

On Fri, 28 Mar 2003, Jason Bay wrote:
>
> I'm working on a little game with a few other people who are not in
> my town, and I'm wondering if there are any web sites that would
> assist in remote artist/developer collaboration, and storage of game
> assets.
>
> I'm thinking it would need to have remote storage (hard drive
> space), some sort of rudimentary source control system, and document
> tracking features. Basically, a central point that would serve as a
> hub to store design docs, code files, art assests, schedules, etc.
>
> It seems like there's got to be something out there, but I haven't
> had any luck finding it after quite a bit of searching. Any ideas?

Sounds like you're describing SourceForge (http://www.sourceforge.net).

Maybe you're not making an open-source game though.  You could always
pay sourceforge to host your closed source project, although I suspect
that's not very cheap.

What I've done in the past is set up CVS and some simple web-based
file-sharing on a web-hosting account, or even a home server.

I think sourceforge is by far the easiest of the above options though.
Server administration is a PITA on the 'net; you have to stay on your
toes to keep on top of security.

-T

Re: [GD-General] Online collaboration site?

[Jeremy N. <jj...@kr...>]

We use a mixture of CVS and a Wiki for collaboration, in addition to
IM clients and a MUX we chat on.

Works pretty well, and easily hosted off a cable modem or dsl line, though
we've just moved to a server from johncompanies.com

On Fri, 28 Mar 2003, Jason Bay wrote:

>
> I'm working on a little game with a few other people who are not in my
> town, and I'm wondering if there are any web sites that would assist in
> remote artist/developer collaboration, and storage of game assets.
>
> I'm thinking it would need to have remote storage (hard drive space),
> some sort of rudimentary source control system, and document tracking
> features. Basically, a central point that would serve as a hub to
> store design docs, code files, art assests, schedules, etc.
>
> It seems like there's got to be something out there, but I haven't had
> any luck finding it after quite a bit of searching. Any ideas?
>
> - Jason Bay
>
>
> ________________________________________________________________________________
> The new MSN 8: smart spam protection and 2 months FREE*
> ------------------------------------------------------- This SF.net email
> is sponsored by: The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> _______________________________________________ Gamedevlists-general
> mailing list Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=557
>

[GD-General] Online collaboration site?

[Jason B. <bay...@ho...>]

<html><div style='background-color:'><DIV>
<P>I'm working on a little game with a few other people who are not in my town, and I'm wondering if there are any web sites that would assist in remote artist/developer collaboration, and storage of game assets.</P>
<P>I'm thinking it would need to have remote storage (hard drive space), some sort of rudimentary source control system, and document tracking features. Basically, a central point that would serve as a hub to store&nbsp;design docs, code files, art assests, schedules, etc.</P>
<P>It seems like there's got to be something out there, but I haven't had any luck finding it after quite a bit of searching. Any ideas?<BR><BR>- Jason Bay<BR></P></DIV></div><br clear=all><hr>The new <a href="http://g.msn.com/8HMVENUS/2737">MSN 8:</a> smart spam protection and 2 months FREE* </html>

RE: [GD-General] FreeType

[Jamie F. <ja...@qu...>]

We use it in our engine, although we render the font to a texture and then
use the texture.

Googling for free fonts brings up quite a few hits, although it can be hard
finding something free which has the style and quality you want.

Jamie


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Brian Hook
Sent: 27 March 2003 20:25
To: gam...@li...
Subject: [GD-General] FreeType


Any opinions on using FreeType for in-game fonts?  This would seem
(in theory) to be one way to handle part of the problems with
interfaces and screen resolution.

I've looked over the docs and API, and so far it looks pretty solid.
The hardest problem is finding a font you can redistribute, but there
are lots of places that will license decent fonts for a fairly small
amount of money ($30).

This just seems much easier than forcing artists to make new fonts
from scratch for every game and/or screen resolution.

Brian




-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_idU7

Re: [GD-General] FreeType

[<cas...@ya...>]

Tom Spilman wrote:
>     We we're using it at one point in a racing game, but i scrapped it as
> our implementation with it was slow and at the time there was a patent
issue
> with FreeType's hinter.  We ended up replacing the entire system with a
> simple bitmap font solution.  At the time we we're using FreeType2 and we
> did have several memory leaks that we believe we're internal to it.  My
> understanding is that all these issues have been corrected now.  If i
we're
> to do it again i would consider using FreeType to build the bitmap fonts
at
> startup, but allow for overloading that behavior if the bitmap already
> exists in the game data.

I've written a simple font engine based on FreeType2 recently, and I've
never had any problem with the FreeType2 library. The latest FreeType's
autohinter is as good as the patented one. I generate a bitmap font for each
page of unicode on request, and I use a font size that depends on the screen
resolution, it works fine, and I'm quite happy with it. The only problem so
far is that the generation of the font bitmaps is a bit slow, and if the
bitmap is generated on runtime it produces a small hiccup, but I'm planning
to cache on disk the fonts that have been generated recently to avoid that.


Ignacio Castaño
cas...@ya...

Re: [GD-General] FreeType

[Brian H. <ho...@py...>]

>The big problem is that
>Truetype fonts are outline fonts, so while they scale nicely,=
 it
>isn't as easy to get nice colors, textures, and shading on the=
 fonts
>as you can with a bitmapped font.

That's a good point, but "easy" really depends on who you're=
 talking 
to.  Generating those effects programmatically would be fairly=
 easy 
to do, albeit not quite as nicely as an artist could do, but at=
 the 
same time artists aren't bogged down with hand drawn fonts at 
multiple resolutions with different effects, etc.

Brian

Re: [GD-General] FreeType

[Tom S. <to...@pi...>]

> Any opinions on using FreeType for in-game fonts?  This would
> seem (in theory) to be one way to handle part of the problems
> with interfaces and screen resolution.

    We we're using it at one point in a racing game, but i scrapped it as
our implementation with it was slow and at the time there was a patent issue
with FreeType's hinter.  We ended up replacing the entire system with a
simple bitmap font solution.  At the time we we're using FreeType2 and we
did have several memory leaks that we believe we're internal to it.  My
understanding is that all these issues have been corrected now.  If i we're
to do it again i would consider using FreeType to build the bitmap fonts at
startup, but allow for overloading that behavior if the bitmap already
exists in the game data.

    Tom

----- Original Message -----
From: "Brian Hook" <ho...@py...>
To: <gam...@li...>
Sent: Thursday, March 27, 2003 2:24 PM
Subject: [GD-General] FreeType


Any opinions on using FreeType for in-game fonts?  This would seem
(in theory) to be one way to handle part of the problems with
interfaces and screen resolution.

I've looked over the docs and API, and so far it looks pretty solid.
The hardest problem is finding a font you can redistribute, but there
are lots of places that will license decent fonts for a fairly small
amount of money ($30).

This just seems much easier than forcing artists to make new fonts
from scratch for every game and/or screen resolution.

Brian




-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_idU7

Re: [GD-General] FreeType

[Tom H. <to...@3d...>]

At 12:24 PM 3/27/2003, you wrote:
>Any opinions on using FreeType for in-game fonts?  This would seem
>(in theory) to be one way to handle part of the problems with
>interfaces and screen resolution.

If you can represent the fonts you want with TrueType, then something like 
FreeType would probably work nicely for generating res specific font 
textures or geometry. The big problem is that Truetype fonts are outline 
fonts, so while they scale nicely, it isn't as easy to get nice colors, 
textures, and shading on the fonts as you can with a bitmapped font. Also, 
doing glows and such become more work as well.

Tom

[GD-General] FreeType

[Brian H. <ho...@py...>]

Any opinions on using FreeType for in-game fonts?  This would=
 seem 
(in theory) to be one way to handle part of the problems with 
interfaces and screen resolution.

I've looked over the docs and API, and so far it looks pretty=
 solid.  
The hardest problem is finding a font you can redistribute, but=
 there 
are lots of places that will license decent fonts for a fairly=
 small 
amount of money ($30).

This just seems much easier than forcing artists to make new=
 fonts 
from scratch for every game and/or screen resolution.

Brian

[GD-General] RE: Gamedevlists-general digest, Vol 1 #200 - 9 msgs

[Jeff L. <je...@SP...>]

> From: Tom Hubina <to...@3d...>
> There's a reason it's called DLL hell.

I have to respond to this one. For our non-game app, which is designed to be
extensible by customers, DLL's are an absolutely superb solution, and we
have never had a problem with them.  People wanting to add functionality to
our system just write a DLL, drop it into our "plugin" directory, and their
functions are wired into the system completely transparently.

People getting all frothy about "DLL Hell" typically are complaining about
"the Windows PATH" with all its insanities, inconsistencies, and windows
registry secrets.

Or the disgusting mess that is COM class registration.

Or badly versioned runtime dlls. (MSVCRT/VBRUN*)

Put your DLL's into your own directory (or subdirectory), load them
yourself, and you never have problems (at least in my experience).

Any application, of *any* ilk that says "to make this run, you need to
change your PATH" should be jettisoned into space without a helmet, in my
opinion.

[GD-General] RE: Gamedevlists-general digest, Vol 1 #200 - 9 msgs

[Jeff L. <je...@SP...>]

> From: Jeff Laing <je...@SP...>
> >You need to work *hard* to get C++ exceptions to work across DLL
> >boundaries.
> 
> From: Brian Hook <bri...@py...>
> Don't use them

Sure, *you* don't.  But what about that groovy 3rd party SDK ?

And, for that matter, what happens when you do a "new" in your DLL and its
out of memory?  When I was a boy, it threw an exception, rather than
returning NULL like good old reliable malloc.

And remembering to put try/catch around every new (especially those implicit
calls to copy constructors the compiler adds for you!!!) takes quite some
discipline.

Again, I'm not trying to convince you, just repeat the folklore for the
youngsters.  There's wolves in them thar dlls.

;-)

Jeff Laing <je...@sp...>
-----------------------------------------------------------------
I'll do anything for you.  Anything that you want me to.
It's just gonna take ... a little more money.
                                              -- The Refreshments 

RE: [GD-General] DLLs for game objects

[Brian H. <ho...@py...>]

On Tue, 25 Mar 2003 19:12:44 -0800, Tom Hubina wrote:
>At 05:40 PM 3/25/2003, you wrote:
>I think that pretty much the same could be said for C#, and I=
 happen
>to like the syntax better ;) Objective-C, Java, and C# are all=
 good
>dynamic languages that have their own individual problems.

<insert religious reasons why I hate C#>

>C++ is definitely a problem with DLLs ... but even straight C=
 has
>problems when you're passing around dynamically allocated=
 memory
>between DLL and EXE, or multiple DLLs. 

There will ALWAYS be problems when you have undisciplined or=
 sloppy 
programmers.  The important thing is finding the right balance 
between the two.  Laying down a real concrete policy up front is=
 the 
first step to avoiding any problems.

In fact, if you don't have a concrete policy on all memory 
management, you're probably pretty much asking for a world of=
 pain no 
matter what language or operating system you're running on.

>I don't think your Quake example applicable to this discussion=
 given
>the very limited interactions you describe between components=
 that

That's my point -- because Quake defined very limited=
 interactions, 
it's completely feasible.  If your interactions are encapsulated=
 into 
a pair of import and export callback tables, you greatly minimize=
 the 
chance of things exploding.

Since the returned values from the DLLs should be opaque pointers=
 or, 
at the worst, pointers to common headers, then the ONLY place=
 you'd 
have to really worry about things is freeing the actual object 
returned from the DLL.  That's it, and I think that's completely=
 
manageable.

>This works as long as each monster is entirely self-contained.=
 You
>run into issues when monsters inherit from other monster files,=
 or
>if you have "sub monsters" ... ie ... a dog monster with a bunch=
 of
>flee monsters attached to it.

This is definitely true.  Sub-classing with a DLL mechanism could=
 be 
tricky.

>If a monster is 100% self-contained, without dependances on=
 other
>dynamically loaded entities (and nothing depends on it) ...=
 then
>something like this could be possible without too much=
 headache.

My instinct is that this is pretty much a given in order to be 
workable.

>You're trying to replicate the dynamic language features of=
 Obj-C,
>Java, and C# in C. While you can do much of this, it's a heck of=
 a
>lot of work and I doubt you'll be able to get is as clean and=
 fast
>as what you can do with one of the other languages.

Possibly.  Except A.) I don't really like Java and C# that much,=
 and 
their run-times are exorbitantly expensive and B.) Obj-C is=
 really 
only usable on OS X.  So you can hack something using DLLs, and I=
 
think it's still workable.

>If you're stuck with C only, then I think something like this=
 sounds
>like something to really look into for dealing with dynamic=
 objects,
>especially if your goal is to be able to change things around at=
 run
>time.

Right.  I'm not saying it's perfect, but I do think it's an 
interesting approach.  You would have to establish some pretty 
serious ground rules up front, but it's very manageable and I=
 think 
it would probably be pretty effective for a limited subset of 
functionality.

Brian

RE: [GD-General] DLLs for game objects

[Tom H. <to...@3d...>]

At 05:40 PM 3/25/2003, you wrote:
>Actually, I think the best language for this is easily Obj-C, since
>it was pretty much designed with this in mind.  I would LOVE to use
>Obj-C for something like this.

I think that pretty much the same could be said for C#, and I happen to 
like the syntax better ;) Objective-C, Java, and C# are all good dynamic 
languages that have their own individual problems.

(Skipping ahead, I think it could be tricky in all of these languages to 
unload a loaded type to load in an updated version from disk .. but I 
haven't looked that heavily into it).

>Going to C++ is when you start introducing a lot of the confusion and
>problems that have arisen, since C++ really isn't what I consider a
>proper OOP language.  Types that are not first class objects pretty
>much blows chunks for anything really dynamic (note: that's just my
>opinion, no need to flame).

C++ is definitely a problem with DLLs ... but even straight C has problems 
when you're passing around dynamically allocated memory between DLL and 
EXE, or multiple DLLs. There are solutions, as have been mentioned ... it's 
just something you always have to worry about, and it's easy for new 
programmers to your team to screw this up in painful, and possibly 
non-obvious to find, ways.

I don't think your Quake example applicable to this discussion given the 
very limited interactions you describe between components that kept these 
kind of issues at bay. I think if you start putting individual monsters 
into their own DLLs, you're going to find your passing structures and 
strings around all the time, and it will be far more easy to make a mistake 
or paint yourself into the "Oh hell, how do I free this thing cleanly" corner.

>The rough gist is that at game startup, you could search all DLLs and
>search for valid "monster files".  If GetProcAddress( "Spawn" )
>succeeds, it's a valid monster file.  Then you call the Spawn
>function, it fills in a standardized struct, you pass it an exported
>interface from the engine, and you're good to go.

This works as long as each monster is entirely self-contained. You run into 
issues when monsters inherit from other monster files, or if you have "sub 
monsters" ... ie ... a dog monster with a bunch of flee monsters attached 
to it.

These things are workable to varying degrees.

>Then you can dynamically load and unload monsters while a server is
>running 24/7, assuming there are no interface changes (note: and if
>there are, you're going to have bring down the server no matter how
>you implement this).

If a monster is 100% self-contained, without dependances on other 
dynamically loaded entities (and nothing depends on it) ... then something 
like this could be possible without too much headache.

>So I thought that would be interesting, but not necessarily good, so
>I decided to post to see what other people have done.  Quake is
>obviously much coarser (game DLL only), but I think it could have
>benefited from a slightly finer grain dynamic game mechanism since a
>lot of what's in the game code can easily be shared across a large
>number of mods but right now code has to be duplicated as a result.

You're trying to replicate the dynamic language features of Obj-C, Java, 
and C# in C. While you can do much of this, it's a heck of a lot of work 
and I doubt you'll be able to get is as clean and fast as what you can do 
with one of the other languages.

>I'm not sold on the idea, mind you, so I'm not saying I advocate
>this, I'm just throwing it out there as food for discussion.

If you're stuck with C only, then I think something like this sounds like 
something to really look into for dealing with dynamic objects, especially 
if your goal is to be able to change things around at run time.

Tom

RE: [GD-General] DLLs for game objects

[Brian H. <ho...@py...>]

>Basically, anything is better than DLLs in my book ... There's=
 a
>reason it's called DLL hell.

Actually, I think the best language for this is easily Obj-C,=
 since 
it was pretty much designed with this in mind.  I would LOVE to=
 use 
Obj-C for something like this.

"DLL hell" is a blanket statement that isn't really valid. =
 Quake2 
used DLLs for game APIs, and without that it wouldn't have been=
 as 
easy to mod (well, there's always QuakeC as a counterpoint, but=
 it 
had its own set of problems).

If you're aware of the problems that DLLs present, then I don't=
 think 
you'll encounter many problems at all.  Just using the Quake 2=
 source 
code as an example:

- well defined import (from engine) and export (from DLL)
- API versioning to prevent problems

In the case of Quake 2, each DLL (ref and game) has exactly ONE 
function that is exported.  It can export anything it wants as=
 long 
as it adheres to the specified API in the import/export=
 structures.

Going to C++ is when you start introducing a lot of the confusion=
 and 
problems that have arisen, since C++ really isn't what I consider=
 a 
proper OOP language.  Types that are not first class objects=
 pretty 
much blows chunks for anything really dynamic (note: that's just=
 my 
opinion, no need to flame).

The reason I bring this up is that looking at each of the various=
 
"monster" files in Quake 2, it's apparent that there was a heavy=
 
Obj-C influence at work.  Each monster file had the required=
 "think" 
functions in it, then local functions accessible only by that 
monster, and "class variables" were statics.  With this in mind,=
 I 
realized that it would be trivial to convert each monster into a=
 
separate DLL.  

The rough gist is that at game startup, you could search all DLLs=
 and 
search for valid "monster files".  If GetProcAddress( "Spawn" ) 
succeeds, it's a valid monster file.  Then you call the Spawn 
function, it fills in a standardized struct, you pass it an=
 exported 
interface from the engine, and you're good to go.

Then you can dynamically load and unload monsters while a server=
 is 
running 24/7, assuming there are no interface changes (note: and=
 if 
there are, you're going to have bring down the server no matter=
 how 
you implement this).

So I thought that would be interesting, but not necessarily good,=
 so 
I decided to post to see what other people have done.  Quake is 
obviously much coarser (game DLL only), but I think it could have=
 
benefited from a slightly finer grain dynamic game mechanism=
 since a 
lot of what's in the game code can easily be shared across a=
 large 
number of mods but right now code has to be duplicated as a=
 result.

I'm not sold on the idea, mind you, so I'm not saying I advocate=
 
this, I'm just throwing it out there as food for discussion.

Brian

Re: Re: RE: [GD-General] DLLs for game objects

[<mi...@ub...>]

>>this still sounds extremely clunky compared to a
>scripting language
>>that requires zero compilation time and can be
>comprehended by most
>>level designers - not just c++ programmers...
>
>I think you're making some blanket assumptions
>here.  
>
>1.) Scripting languages are not necessarily more
>comprehensible than 
>compiled languages.  They CAN be, but not always. 

yes i'll agree that i'm making some assumptions based on the particular scripting language that i happen to be using - simkin.

>2.) Scripting languages still need to be
>processed.  They can either be byte compiled -- 
>which is a compilation phase -- or they might 
>break during interpretation, which is harder to
>find than a compile time error.

i guess this depends on what kind of debug info you provide with the integration - we have a 'debuginfo' output that we can send to the screen, console or logfile, so even if your script barfs on interpretation, the log files will report as such - the goal i guess is to provide enough debug info so that the designers/scriptors can debug properly - the right tools for the job so to speak.

>3.) the entity DLLs don't have to contain all the
>relevant aspects of 
>the entity.  As mentioned elsewhere, the DLLs can
>contain the more 
>low level functionality and you can data drive the
>other aspects 
>using something a lot friendlier than a scripting
>language (cf. the 
>prior discussions on property based systems).

again, i'm biased from my particular experiences with our engine, but we actually combine both scripting languages AND property-based systems (editable properties for entities in the editor) - certain features use only scripting, others only properties, some both.

we actually USED to have two project files for the engine, one dll-based, one static, but the dll-version has basically been dropped - not for any specific technical reason, but all new development moved to the static version, and the dll project and workspace has fallen into 'disrepair' as it were.

getting down to a 'dll for every entity' seems a bit extremely however.  for projects that can do a complete rebuild in less than a few minutes, the argument for 'ease of recompile' doesn't seem to hold up...

anyways

mike w
www.uber-geek.ca
mike

RE: [GD-General] DLLs for game objects

[Tom H. <to...@3d...>]

At 02:38 PM 3/25/2003, you wrote:
> >One thing that bears consideration is what you allow those external
> >DLL's to do.
>
>Well, I'm thinking of this from a server side type of thing (a la
>MUDs), which I should have been more explicit about.

Personally, I can't stand DLLs. There's simply far too many problems with 
them and things you have to watch out for. For anything complex you 
invariably you end up painting yourself into a design corner when something 
comes up you didn't anticipate and you end up having to hack your way out 
in one way or another.

If I was interested in doing something like this (server side only makes 
this reasonable .. wouldn't suggest this for clients yet), with the goal of 
having lots of small dynamic "pieces" that could be fitted together at 
run-time in some form of OOP manner I'd be looking at C# and .NET as a 
solution. From what I've seen the stuff is built from the ground up to 
cleanly operate with a C/C++ engine, and C# "scripts".

If I using *nix as my platform, then I would look into the C# stuff that's 
being done there (I think it's called Mono), and if that didn't work, then 
I'd seriously consider going through the (relative) hell of JNI and using Java.

Failing that, I'd look at scripting languages like Lua, or just say to hell 
with it and do it all statically linked to a single executable.

Basically, anything is better than DLLs in my book ... There's a reason 
it's called DLL hell.

Tom

Re: [GD-General] DLLs for game objects

[<cas...@ya...>]

Brian Hook wrote:
> Thoughts and comments?

I think that a DLL for each entity would be to heavy, but allowing plugable
libraries of entities would be cool. And it would be even better if those
libraries could overwrite the existing entities. You could keep your
monolithic fixed set of default entities, and later add newer ones, by
writting libraries. You could have a library with a single entity, but in
general they could have any number of them.


Ignacio Castaño
cas...@ya...

RE: [GD-General] DLLs for game objects

[Brian H. <bri...@py...>]

>One thing that bears consideration is what you allow those=
 external
>DLL's to do.

Well, I'm thinking of this from a server side type of thing (a la=
 
MUDs), which I should have been more explicit about.

>You need to work *hard* to get C++ inheritance to work across=
 DLL
>boundaries.  (Consider your vorpal_sword : sword example)

Yes, agreed.

>You need to work *hard* to get C++ exceptions to work across=
 DLL
>boundaries.

Don't use them =3D)

>At least, in all previous attempts that we've made (in a=
 non-game
>environment), we had so much woe that we fell back on insisting=
 that
>you only have C interfaces, that return status values, rather=
 than
>throw exceptions.

Using straight up C has so many advantages that it's not funny,=
 that 
much I agree with.  Little things like transmitting networked=
 entity 
state just come off much more naturally using C than it does=
 trying 
to incorporate all the extra goodness that C++ theoretically 
supplies.

Sometimes monolithic is good.

Brian

RE: [GD-General] DLLs for game objects

[Jeff L. <je...@SP...>]

> From:     Brian Hook <bri...@py...>
> Subject: [GD-General] DLLs for game objects

One thing that bears consideration is what you allow those external DLL's to
do.

Its gotta be cool to be able to wire in an external (3rd party) AI engine,
that would not be available from your scripting language.

And it certainly lends itself to user developed MODs.

The downside, from my opinion, tends to be at the mechanical level inside
the cross-DLL boundary.

You need to work *hard* to get C++ inheritance to work across DLL
boundaries.  (Consider your vorpal_sword : sword example)

You need to work *hard* to get C++ exceptions to work across DLL boundaries.

At least, in all previous attempts that we've made (in a non-game
environment), we had so much woe that we fell back on insisting that you
only have C interfaces, that return status values, rather than throw
exceptions.

Oh, and watch out for malloc'ing in one DLL, and free'ing in another - you
need a lot of discipline to ensure that all your DLL's - remember those
customer MODs - use a single, consistent, dynamic memory manager.

That'll be 2 cents please.

Jeff Laing <je...@sp...>
-----------------------------------------------------------------
"When your hammer is C++, everything begins to look like a thumb."
   - Steven Haflich, Franz, Inc.

Re: [GD-General] DLLs for game objects

[Colin F. <cp...@ea...>]

>>>The downside is primarily complexity, in that you have hundreds or 
>>>maybe even thousands of DLLs for every entity, e.g. sword.dll and 
>>>orc.dll or what have you.

I am fascinated by the insane image of having "thousands of
tiny DLLs in applications across the country!"  (Homage to
Don Lapre)  Of course you would have to write those DLLs
in a tiny, one-bedroom apartment to make your rags to
effortless riches story complete.

--- Colin

cp...@ea...

Re: RE: [GD-General] DLLs for game objects

[Brian H. <bri...@py...>]

>this still sounds extremely clunky compared to a scripting=
 language
>that requires zero compilation time and can be comprehended by=
 most
>level designers - not just c++ programmers...

I think you're making some blanket assumptions here.  

1.) Scripting languages are not necessarily more comprehensible=
 than 
compiled languages.  They CAN be, but not always.  

2.) Scripting languages still need to be processed.  They can=
 either 
be byte compiled -- which is a compilation phase -- or they might=
 
break during interpretation, which is harder to find than a=
 compile 
time error.

3.) the entity DLLs don't have to contain all the relevant=
 aspects of 
the entity.  As mentioned elsewhere, the DLLs can contain the=
 more 
low level functionality and you can data drive the other aspects=
 
using something a lot friendlier than a scripting language (cf.=
 the 
prior discussions on property based systems).

Brian

RE: RE: [GD-General] DLLs for game objects

[Jamie F. <ja...@qu...>]

There's nothing to stop the entity behaviour being controlled from
scripting, but obviously some things need to be done in C++ for performance
reasons, etc. The scripting also integrates seamlessly, so there's no
problem. Any change in parameters would not result in a DLL rebuild. But new
complex behaviours likely would, and i don't see a problem with that.

Jamie


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
mi...@ub...
Sent: 25 March 2003 11:34
To: gam...@li...
Subject: Re: RE: [GD-General] DLLs for game objects


this still sounds extremely clunky compared to a scripting language that
requires zero compilation time and can be comprehended by most level
designers - not just c++ programmers...

the idea of recompiling to change entity variables, NPC behaviors, etc
sounds like a nightmare for the design team.

we do have certain aspects of the engine split into seperate dll libraries,
but the main gameplay behavior is rapidly moving towards almost entirelyi
scripting - including things like the terrain engine, curved surface
definition and more...

cheers

Mike W
Reality Factory Open Source Project
http://rfactory.uber-geek.ca

>We're heading toward a DLL for entities at some
>point, mostly so we can talk
>to our editor nicely, but i'm not envisaging doing
>a DLL per entity :) But
>it hasn't happened yet.
>
>Jamie
>
>
>-----Original Message-----
>From:
>gam...@li...
>[mailto:gam...@li...]On
>Behalf Of
>Brian Hook
>Sent: 25 March 2003 05:16
>To: gam...@li...;
>gam...@li...
>Subject: [GD-General] DLLs for game objects
>
>
>Relating to a thread on the gamedevlists-windows
>list, I thought I'd
>just toss this out for discussion.
>
>One of the reasons often touted for using a
>scripting language is
>that you can easily modify the behaviour of game
>objects without
>recompiling your main source base.  This is
>definitely an advantage.
>
>The way you'd achieve the same effect using
>compiled code is via
>DLLs.  At a coarser level, the Quakes did this
>with QuakeC (Q1),
>server-side DLLs (Quake 2), and server + client
>side DLLs (Q3), but
>each entity itself was not a separate DLL.
>
>So let's take that to an extreme, where every
>object is generated by
>a factory method within a specific DLL.  You get
>the advantage that
>your "game kernel" does not have to be recompiled
>on the fly to
>change behaviour, along with the advantages of
>debugger compatibility
>and compiled code.
>
>The downside is primarily complexity, in that you
>have hundreds or
>maybe even thousands of DLLs for every entity,
>e.g. sword.dll and
>orc.dll or what have you.  Not to mention that you
>could conceivably
>run into a problem with DLL dependencies (what if
>vorpal_sword.dll is
>dependent on sword.dll?).
>
>None of these problems are benefits are
>particularly mind blowing,
>but I haven't seen it done in practice so I was
>curious what others
>might think of it.
>
>I personally still prefer monolithic, statically
>linked stuff because
>the practical advantages typically outweigh the
>theoretical benefits.
>
>Thoughts and comments?
>
>-Hook


-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=557

Re: RE: [GD-General] DLLs for game objects

[<mi...@ub...>]

this still sounds extremely clunky compared to a scripting language that requires zero compilation time and can be comprehended by most level designers - not just c++ programmers...

the idea of recompiling to change entity variables, NPC behaviors, etc sounds like a nightmare for the design team.

we do have certain aspects of the engine split into seperate dll libraries, but the main gameplay behavior is rapidly moving towards almost entirelyi scripting - including things like the terrain engine, curved surface definition and more...

cheers

Mike W
Reality Factory Open Source Project
http://rfactory.uber-geek.ca 

>We're heading toward a DLL for entities at some
>point, mostly so we can talk
>to our editor nicely, but i'm not envisaging doing
>a DLL per entity :) But
>it hasn't happened yet.
>
>Jamie
>
>
>-----Original Message-----
>From:
>gam...@li...
>[mailto:gam...@li...]On
>Behalf Of
>Brian Hook
>Sent: 25 March 2003 05:16
>To: gam...@li...;
>gam...@li...
>Subject: [GD-General] DLLs for game objects
>
>
>Relating to a thread on the gamedevlists-windows
>list, I thought I'd
>just toss this out for discussion.
>
>One of the reasons often touted for using a
>scripting language is
>that you can easily modify the behaviour of game
>objects without
>recompiling your main source base.  This is
>definitely an advantage.
>
>The way you'd achieve the same effect using
>compiled code is via
>DLLs.  At a coarser level, the Quakes did this
>with QuakeC (Q1),
>server-side DLLs (Quake 2), and server + client
>side DLLs (Q3), but
>each entity itself was not a separate DLL.
>
>So let's take that to an extreme, where every
>object is generated by
>a factory method within a specific DLL.  You get
>the advantage that
>your "game kernel" does not have to be recompiled
>on the fly to
>change behaviour, along with the advantages of
>debugger compatibility
>and compiled code.
>
>The downside is primarily complexity, in that you
>have hundreds or
>maybe even thousands of DLLs for every entity,
>e.g. sword.dll and
>orc.dll or what have you.  Not to mention that you
>could conceivably
>run into a problem with DLL dependencies (what if
>vorpal_sword.dll is
>dependent on sword.dll?).
>
>None of these problems are benefits are
>particularly mind blowing,
>but I haven't seen it done in practice so I was
>curious what others
>might think of it.
>
>I personally still prefer monolithic, statically
>linked stuff because
>the practical advantages typically outweigh the
>theoretical benefits.
>
>Thoughts and comments?
>
>-Hook