Thread: RE: [GD-General] Re: [GD-Design] Indie - Publishing Services?
Brought to you by:
vexxed72
Menu
▾
▴
gamedevlists-general
|
From: Gareth L. <GL...@cl...> - 2003-02-26 10:11:48
|
Wow, this looks amazing. I know there are financial interests for doing this, but they can't be huge, which brings me to the conclusion that you really want to help the Indies out there. Thanks a lot sir. (I'm not an indie, but that's not the point). Assuming games are good, I will be supporting this when it goes live by purchasing whatever looks really good :) So keep us posted, _____________________ Regards, Gareth Lewin "Well yes, apart from a unified API to a wide range of PC hardware, a powerful operating system accessible to Joe Public, one of the most developer-friendly pieces of console hardware ever made and a rather promising new scripting language, what have Microsoft ever given us?" "A computer in every home?" "Oh shut up." (Thanks to Tom Forsyth for that) |
|
From: Mike W. <ge...@ub...> - 2003-02-26 21:49:12
|
dunno about amazing, but almost all of the pieces of the puzzle are in place already, and i'm putting the finishing touches on the content management system for the site - won't be too long before i have something online to show. i'll definitely keep everyone posted about any news (opening day, etc) on the publishing front. mike w www.uber-geek.ca Gareth Lewin wrote: >Wow, this looks amazing. I know there are financial interests for doing >this, but they can't be huge, which brings me to the conclusion that you >really want to help the Indies out there. > >Thanks a lot sir. (I'm not an indie, but that's not the point). > >Assuming games are good, I will be supporting this when it goes live by >purchasing whatever looks really good :) So keep us posted, > >_____________________ >Regards, Gareth Lewin > > |
|
From: Brian H. <bri...@py...> - 2003-03-25 05:15:45
|
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 |
|
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: <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 05:15:45
|
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 |
|
From: Ray <ra...@gu...> - 2003-03-25 06:51:08
|
I have thought about this for our game, and we already have factory functions for our classes so it would be trivial to move them into dlls. I've already done that for testing once, but as you said, the practicality outweighs the theoretically. But, I wouldn't have a different dll for each object type, instead a different dll for a set of objects or classstypes. Keeping the ability to move objects into their own dlls is good for general software engineering anyways and there's no reason not to design it that way, I think. Recompiling the game kernel if there's an object change shows poor relationship between the engine and the objects. Our game recompiles on my machine in under 5 minutes so there's no need to split the objects out anyways, and when an object behavior changes, there's only like 1-2 files that need recompiling too. All-in-all, it's good to have your engine and objects separate from a design standpoint, but there's not much of a reason to make them a separate dll unless you really want modularity for future mods. I'm tired, so I hope that's coherent enough for you. - Ray Brian Hook wrote: > 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 |
|
From: Jamie F. <ja...@qu...> - 2003-03-25 10:21:15
|
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_idU7 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X