• Game Data
• News Archive
• Contact Us

• Screenshots
• Archive 1
• Archive 2
• Concept Artwork
• Other Images

• Music
• Video
• Other

• Previews
• Interviews
• Community

Modification Project Talkabout

Welcome to the third mod project massive-interview-style features. The goal of this new regular column? To hopefully spread some ideas regarding mod design, as well as get more projects involved in sharing their opinions, ideas, and finer points of design concept. The questions asked from week to week will be varied. Today's question happens to be:

What are your feelings on the "open source" approach, where teams would share elements to speed up work, such as pieces of maps, snippets of code for customization abilities, etc.?

So, without further delay, here come the answers. Are you a project who would like to be involved? We probably just missed you by accident (though we did try to contact at least one rep from each team). Get ahold of us here.

Participating projects this round:

-DX Vampire
-Redsun 2020
-The Co-Op Project
-The Cabal of Technophiles
The Answers

 Personally I have always been in favour of an open source approach, but we need to be careful how far we go. Sharing resources is a good way to hasten the development of mods and to help each other learn new techniques and concepts. This is all great, but we need to make sure we don't share too much. We don't want mods to all use the same ideas and the same techniques. The other issue faced is that if you share too much then you could end up giving away what will make your mod unique. We at Vampire are aiming for a very unique mod that hopefully will stand out from the rest as something different. If we share too much of our work, we run the risk of giving away our identity.

 My personal belief is that we shouldn't so much share actual work, but instead share people. Many of the Vampire team, myself included, help out on other projects here and there. Until Edge of Dark closed it's doors, myself and Shade01 (EOD leader) had a good relationship working with a good coding for models trade going. This allows each mod to keep their identity while gaining experienced people in the areas their team lacks most.

-Damocles, Vampire

I think the idea is good but it needs to be very organized and a director to manage it. One idea, is to create a site for example and call it "DX-OPEN SOURCE". At the site, it should have a list of categories where people can easily upload and download stuff. For example; Prefabs, Textures, sounds, music, voices, models, untextured maps, scripts, custom menu, skins, etc. We already have technical support forums but it would be great to have something like this as a compliment as well. This way we have a central site for mod people to go and visit to talk, upload, download stuff and forums to get support and express ideas. Even a opensource mailing list for members to keep everyone up-to-date on what new stuff came in that week. :D This way, no-one really needs to invade someone mod to exchange things. Also, I think new mod startups can get going quicky by accessing this open source site.

There is one issue I will mention. I have lots of prefabs I created but I am not sure I want to share them until my mod is completely finished. I want to keep my look and feel FRESH. The only problem I can see with open source is a generic look. If everyone is using the same textures, models and prefabs, the unique style is not quite there. People may not want to download a mod if they know they completely depended on OPEN SOURCE material. However my suggestion would be to use some stuff from OPEN SOURCE but use it creatively and add your own stuff as well. I would only use OPEN-SOURCE stuff when it is revelent to the theme and level that I am designing. If it is not there, I create it.

So, is someone going to create this great DX-OPEN SOURCE site for me? Hehehe!

Odaiba, Redsun2020

Here are the responses from the core members of the Cabal of Technophiles:

TechImmortal: Generally, I like the idea of sharing meshes, sounds, weapons, and even maps if they fit a mod's plans and if credit is given to the creators of the shared material. We ourselves will no doubt release assorted goodies for general use by the mod community, and will probably use at least some meshes generated by others.

The only way open sharing would not be good is if code and maps are completely open before a mod ships (or formally shuts down), since this can give away all the story and map surprises. In the interest of preventing spoilers, secrecy about the core mod is good.

Bogeyman: Personally I like the idea of sharing material, so long as credit is properly given. Not much else to say really, save to point out one advantage apart from the obvious one of preventing duplication of effort: I think sharing materials can be a great way to keep the mod community harmonious, which is a good thing for everybody. No doubt most creators like to see their material used by as many players as possible and the mods and mod teams benefit from each others' talents.

Scarab: Sharing resources is a good idea, although it can lead to a certain amount of "sameness" if you take it too far. Prefabs are pretty useful for sharing, as are chunks of script - especially since code is pretty easy to customize for a specific purpose (well if you're a coder it is lol!).

As always, as long as credit is given to the original creator there shouldn't be an issue.

TechImmortal and team, The Cabal of Technophiles

"Open source" approach is in my opinion a very good thing, especially for smaller mods which lack in certain areas but might be very good in some other ones.

For example a good coder could code a certain piece of code for a few models or maps for example. And coders from 2 different mods could save time by sharing pieces of code both mods might be using, this will keep everyone happy and will speed up the process. This might be one of the reasons Deus ex mods arent doing so well propably, there are way too many of them and the talents are scattered between mods, one has a good coder, one has a good modeler and the 3rd one has a good mapper. The result is none will get finished because they might lack in other areas, and when the team falls appart the "talent" in it might go away completely.

What would be useful is that these different people could share things with each other and mods could help each other out in areas they are strong in and get help in areas they aren't very good at.

Raptor, Warzone http://www.planetdeusex.com/warzone/

The open source approach to development can be an excellent way to help speed up the overall development time. Software developers have been enjoying the benefits of code reuse for many years; why re-invent the wheel? If Project A has written a piece of code or a model, lets call it AB, and Project B needs to implement exactly the same thing, what do you think is better:

1) Write the code from scratch
2) Reuse existing code

Option 1 would give the project the benefit of knowing exactly how AB is implemented, but option 2 gives other benefits, such as knowing that AB has been "tried and tested", meaning that there is no need to go through lines of code debugging problems already found and fixed. Of course, a major advantage of reuse is often seen in a reduction of the overall development time.

So, code and models (mini-mods, perhaps?) are an ideal candidate for the open source approach, but I’m not sure how far this could be implemented for maps. Each project is individual; it goes without saying that its maps are going to be pretty customised, or specific, for a certain modification. I believe that every mapper has his or her own style, it can be very daunting and confusing when looking at other people’s work in the editor. One could say that the benefits of an "open source" approach would not be as prominent here as it would be in areas such as code and model sharing. That’s not to say that it couldn’t work, though. I would suggest that it is dependent on the complexity of the map to the shared and the way in which it was developed.

I would imagine that there would be little problem with different people developing maps started by other people of the same project, where following a strict development policy. However, I would say that care needs to be taken when sharing a map between two different people who are on different teams or projects, especially with regards to the style of implementation.

There are certain parts of the Disclosure Project that would be suitable for open-source sharing, including elements of the code and even the installer, it’s certainly something that I will be looking closely at making available in the future. Ultimately, if the original author is happy for another project to make use of their work, and the other project is happy to credit the work fully, I don’t see any problem with taking advantage of what’s already available if that is what the project wants to do.

Face, Disclosure

(Post article note: being a programmer, I’ve afraid it has gotten a little programming-orientated in parts -- no code or anything you non-programmers, I just talk single-mindedly. Sorry for this, but the points still do apply to everyone.)

To sum it up, open source is a ‘good thing’. Why? It gives us:
- Lower development times (and costs),
- Can help educate others (as they look at your code),
- And the ability to see how someone else has done something.

For true open-sourcing to happen, I feel that the following must exist in the workgroup/community: willingness to share, maturity and confidence. These require a little explaining.
Of course, central to sharing your code is the willingness to do so. Reasons why people might not like this could be because of Intellectual Property (IP) issues -- more on this later; also, a level of maturity must exist in the sharer and the community -- the sharer must ensure that the element that they are preparing to release is well-documented (to levels appropriate for the particular element) and well-organised, for reasons such as the ease-of-use for any other developers that might work with/take a look at your ‘element’. It would be essential for them to understand exactly how it works; i.e. I could release the code to a 3d-engine I cooked up one afternoon, but if I do not documentate(please correct spelling) it and ensure that it is laid out in a logical manner, Bob The Programmer, when looking at the code, might have no idea what it does or how it does it -- they would spend as much time as they would working with the actual code just figuring out what it does.

Maturity is always a big issue in the communities of game modifications, and we’ve all fallen victim to it at one time or another. To clarify, ‘maturity’ means the ability to take feedback from other people looking at your work -- be it good, bad or indifferent. You need to be able to ‘take’ people insulted your product, praising it and asking questions as to why you did this here. In my experience, I find that taking praise for something that I have released is a lot easier than reading an email that is insulting the code that I spent the last four months on; to become a true ‘Open-Sourcer’, you must be able to read an email saying something similar to the example that follows, and you must (*MUST*) thank the person who sent it to you for their feedback -- then of course, you must actually do something about the criticism that they sent you.

An example criticism email:

"Hello there,

 you fool! Why did you use a bool array, when clearly such no thing exists, and you should have used a byte array! Then changing the Xyz32 variable to a 32-bit number would have allowed you to process..."

This person above could be talking (rubbish), or he could have a valid point -- and just angry about something else. You’ve got to send a "thank you" note to them, and then look at their point, at your element (code in this example) and see whether the person has a valid point. If they do, would your element be better off changed?
One important thing: angry end-users = bad. If you do use an idea or a suggestions from someone else, be sure to credit them -- especially good to remember when dealing with large, multinational corporate companies who can/and probably would take legal action against you, without the blink of an eye.

Confidence walks very close to maturity -- are you brave enough to see your ‘element’ (that you have spent the last six months working on) sent all over the World Wide Web, and smashed by a million virtual users against the rocky coasts of Cyberspace? If you do not think your element is particularly special or that it proves useful/interesting to your respective audiences, then don’t release it! Like anything in this world, here are a couple of exceptions to this rule:
-  New gaming communities
-  And personal websites.

Releasing potentially ‘stupid’ or ‘obvious’ points in your field to a community is not always as sucidistic(this a word? Else use ‘suicidal) as it may at first seen -- since this community is only new, people will not have had much experience with it yet, so you are all still "newbies", and only the worst hypocrite will give negative feedback in this situation.
Employers (*shudder*) - you can’t work with them, can’t work without them. Especially true in the videogame entertainment world, professional games/product development is a very (*very*) difficult field to break to (and no, I have not yet managed this). Let me take a closer look at would-be professional programmers from the viewpoint of a ‘well-known’ employer, Mr. B. Higglesbottom.

Higglesbottom: (thinking to himself) hmm, I have three prospective employees here. Let’s see - oh, one without a Computer Sciences degree - he’s out straight away. What about these other two? Hmm...

(Higglesbottom decides to take a ‘quick’ break from looking at these CVs; the next day...)

Higglesbottom: Well Simon, two potential candidates here -- they both eat, sleep and dream C++, Assembler, DirectX, OpenGL and at least three proprietary console development languages. Shall we just flip a coin?

Simon: No no no, what are you thinking? See, like you said both candidates know virtually everything there is to know, but this is all on paper. If you look here, Candidate B (unlike Candidate A) says she has a website with examples of her programming on -- let’s take a look, eh?

Higglesbottom: No harm in it, I suppose...

(The two ‘busy’ executives ‘surf’ to Candidate B’s website. In the five years that Candidate B has been trying to break into the professional software development circuit, every time she released something decent, she updated her CV online at her (very simply designed, text-only) website saying what she has done, and where you can download a copy from. Not only once helping members of whatever community she was in find out where to download her work, she has made herself infinitely more attractive to her potential employer.)

(Two stunned executives lean over a terminal, their mouths wide open. One has a pool of drool near his feet.) Simon: Oh my...

Higglesbottom: "God " this woman has single-handedly programmed a 3d-engine to rival the latest Quake VI stuff -- quick, give here the job now before someone else finds her out!

You might think that all the money in Quake 2 was to be made in commercial sales, in shops and the like. Richard Darling, of Code masters (‘Rights and Wrongs’, Develop, March 2002) would agree with you:

"There is no inherent value in a game. It is not a commodity or a limited resource." (Quoted by Scott Miller.)
Now imagine that the game (as in the levels, bad guys, sounds, graphics engine, textures etc) was decided by ID Software to be called something other than ‘Quake 2’ -- say ‘Wor (fact fans: yes, the original name for Quake 2 was to be ‘Wor’ -- this only got changed due to ‘tricky licensing issues’). Would ‘Wor’ have sold as many copies, and been as supported as ‘Quake 2’ was? Of course it wouldn’t -- but it would have been one great ‘sleeper’ hit’. A better example of ‘real world’ IP is Coca Cola (the company). Owning a few hundred gallons of the stuff would be a laugh, and you’d make a bit of money. The real money is in the IP, as Scott Miller of 3Drealms notes (‘Protect Your Property", Develop, March 2002):
"If given the opportunity to own the Coke trademark or all of Coke’s billions of dollars of tangible assets, like warehouses and offices, I’d take the trademark and start a new company, and I’d soon be able to buy those assets back!"
On the flipside, as shown even in the Deus Ex engine, yes you can recompile every package and make the game your own, but you cannot rebuild the C++ .dll’s and other native files -- the Unreal engine is not true open source; developers like to keep their low-level secrets exactly that -- secret. In their defensive, is there a need to have access to the source for applications such as sound card drivers? With the possible exception of other sound card manufacturers, who cares?

To summarise: -  Open-source software development is a good thing, and helps everyone from the development team to the end users.
-  You can keep the inner secrets of your product secret, but only to stop someone releasing a clone of your game for free (using the same library files) -- try to give end users as much unhindered access to your product as possible; who knows, one may go on to create an amazing modification or level for it -- they may be the next big thing.

DJPaul, The Co-op Project


And there you have it. Tune in in a few more weeks for the next installment. Got a certain question you think would be a fantastic prompt? Feel free to suggest those as well.

Travel to: Go Back / DEx-m.com (home) / TTLG