gamedevlists-general Mailing List for gamedev (Page 53)
Brought to you by:
vexxed72
You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
(28) |
Nov
(13) |
Dec
(168) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(51) |
Feb
(16) |
Mar
(29) |
Apr
(3) |
May
(24) |
Jun
(25) |
Jul
(43) |
Aug
(18) |
Sep
(41) |
Oct
(16) |
Nov
(37) |
Dec
(208) |
2003 |
Jan
(82) |
Feb
(89) |
Mar
(54) |
Apr
(75) |
May
(78) |
Jun
(141) |
Jul
(47) |
Aug
(7) |
Sep
(3) |
Oct
(16) |
Nov
(50) |
Dec
(213) |
2004 |
Jan
(76) |
Feb
(76) |
Mar
(23) |
Apr
(30) |
May
(14) |
Jun
(37) |
Jul
(64) |
Aug
(29) |
Sep
(25) |
Oct
(26) |
Nov
(1) |
Dec
(10) |
2005 |
Jan
(9) |
Feb
(3) |
Mar
|
Apr
|
May
(11) |
Jun
|
Jul
(39) |
Aug
(1) |
Sep
(1) |
Oct
(4) |
Nov
|
Dec
|
2006 |
Jan
(24) |
Feb
(18) |
Mar
(9) |
Apr
|
May
|
Jun
|
Jul
(14) |
Aug
(29) |
Sep
(2) |
Oct
(5) |
Nov
(4) |
Dec
|
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(11) |
Sep
(9) |
Oct
(5) |
Nov
(4) |
Dec
|
2008 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(34) |
Jun
|
Jul
(9) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(4) |
2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Brian H. <ho...@py...> - 2003-03-28 22:44:18
|
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 |
From: <mi...@ub...> - 2003-03-28 22:16:19
|
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 |
From: Thatcher U. <tu...@tu...> - 2003-03-28 22:14:04
|
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 |
From: Jeremy N. <jj...@kr...> - 2003-03-28 22:09:35
|
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 > |
From: Jason B. <bay...@ho...> - 2003-03-28 21:23:59
|
<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 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> |
From: Jamie F. <ja...@qu...> - 2003-03-28 10:28:37
|
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 |
From: <cas...@ya...> - 2003-03-28 00:56:34
|
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... |
From: Brian H. <ho...@py...> - 2003-03-27 21:50:15
|
>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 |
From: Tom S. <to...@pi...> - 2003-03-27 21:33:39
|
> 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 |
From: Tom H. <to...@3d...> - 2003-03-27 21:15:18
|
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 |
From: Brian H. <ho...@py...> - 2003-03-27 20:24:52
|
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 |
From: Jeff L. <je...@SP...> - 2003-03-26 22:49:17
|
> 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. |
From: Jeff L. <je...@SP...> - 2003-03-26 22:42:16
|
> 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 |
From: Brian H. <ho...@py...> - 2003-03-26 03:37:10
|
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 |
From: Tom H. <to...@3d...> - 2003-03-26 03:11:24
|
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 |
From: Brian H. <ho...@py...> - 2003-03-26 01:40:23
|
>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 |
From: <mi...@ub...> - 2003-03-26 01:10:38
|
>>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 |
From: Tom H. <to...@3d...> - 2003-03-26 01:07:59
|
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 |
From: <cas...@ya...> - 2003-03-25 23:42:00
|
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... |
From: Brian H. <bri...@py...> - 2003-03-25 22:38:35
|
>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 |
From: Jeff L. <je...@SP...> - 2003-03-25 22:20:42
|
> 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. |
From: Colin F. <cp...@ea...> - 2003-03-25 22:16:54
|
>>>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... |
From: Brian H. <bri...@py...> - 2003-03-25 19:21:06
|
>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 |
From: Jamie F. <ja...@qu...> - 2003-03-25 11:55:46
|
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 |
From: <mi...@ub...> - 2003-03-25 11:33:46
|
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 |