Ora invece vi posto il loro Blog!
http://forumtgmonline.futuregamer.it...on_biggrin.gif Immagine cliccosa
http://forumtgmonline.futuregamer.it.../icon_wink.gif
<a href="http://imageshack.us" target="_blank">http://img91.imageshack.us/img91/2821/immagine2cx2.jpg</a>
l'ultima notizia sul blog è la seguete:
8.12.2006
Justin Fitzsimmons - Coder
I've been a member of Ground Zero for quite a while now, but my personal life has been getting in the way of putting a good chunk of time into Ground Zero. Rectently some time freed up, and I threw a hefty chunk of it at the project, so I'm writing a blog entry to introduce myself and what I've been working on for the past week or so. I'm working as a C++ coder, and my first assignment is the backend of the inventory system.
It just so happens that my first project working with the doom3 SDK was to write a more advanced inventory - so it was pretty natural to be assigned such such a similar task for Ground Zero. Unfortunately, the code that I had already laid down with my inventory isn't exactly what Ground Zero was looking for, so I had to re-implement everything from scratch; but the experiences with the SDK and how to represent inventory items in memory are things that carried over from the last project and significantly streamlined the process the second time around.
As it stands, I've finished the preliminary development for the inventory backend. Paul and I discussed how to engineer the inventory, based on a rough specification he had done. The spec saw a lot of change, removing elements that were unnecessary and adding elements that we deemed important. The end result is an inventory system which is still similar to the original concept, but with a modified and streamlined implementation.
For example, the original spec called for items to have a category and hardpoints to have a type, in addition to attach points and in the case of hardpoints, a name. The idea was that an item could attach to the hardpoint if the hardpoint's name was in the list of valid attachpoints for the item, and that the categories matched. Or something like that; I didn't totally understand the meaning of it all, nor did I understand the justification for it. So now, that sort of type checking is handled with names alone.
Another change that resulted from this was increased flexibility for items. Since they don't need to fit into distinct categories anymore, any item can be a container. That is to say, the definition system for items is flexible enough to optionally make anything a container without extra overhead in the code; not that all items are containers. This is neat because (as an example, which may or may not be used in the game), jeans are an article of clothing, but hey, jeans also happen to have pockets! The artist creating the item can easily set the regular properties that are needed for any sort of article of clothing, such as the clothing attach points ("clothing_legs"), the model, textures, etc.; and then a gameplay designer can come back to the same def file and give the jeans additional container properties: "storage_volume" "0.2" and "max_unit_volume" "0.2" - values suitable for storing a wallet, or maybe a handful of bullets.
Any item may also have hardpoints, which makes for quickly adding cool things to other items. An example: adding a flashlight to your gun. We also tossed around the idea of making magazines containers, which would be mounted onto a certain hardpoint of a firearm, which would unload the top cartridge from the magazine and mount it into the firearm's "chamber" hardpoint, assuming the calibre was compatible. This has even more interesting implications, because it could allow the player to order their bullets in their magazine: 3FMJ, 1 Tracer, repeating, for example. None of this is finalized yet, and needs some more thought put into it, especially considering that there would be a lot of memory wasted if every individual bullet in the game was represented as a discrete item. My preliminary thoughts are to make bullets a sort of "singleton" item which only exist in memory once, and are merely pointed to many times. Nothing's final right now, but you'll probably be hearing from one of the team when we do have something hammered out.
Finally, the original spec didn't have any way to keep track of an item's weight. We decided this was fairly shortsighted, and required, despite the increased complexity of having two metrics to take care of when managing one's inventory. Originally, with only volume-based inventory restrictions, a puny 80-year-old scientist would be able to carry as much as a 20-year-old massive ogre-man who makes holes in walls with his fists; assuming that they had comparable storage equipment. So, I added support so that every item now has a weight field, and the inventory tracks the total and disallows adding more items if it would go over the weight restriction, just like many inventory systems currently found in RPGs.
I do admit that I am somewhat nervous about the frontend implementation of the inventory, since doom3's guis aren't the prettiest things to work with behind the scenes (despite their delicious vector graphics on the front). Jon and Paul are quick to remind me that I am not to trouble myself with these sorts of things until they actually become relevant. I understand their reservations, and have focused on the task that has been assigned to me. With that said, I doubt this will be the last you hear from me on the subject.
This week and probably parts of next week will involve heavy testing and debugging of the code I've written, after which I hope to be assigned my next task.