Dualoping our Mod

It was not long ago when I read about pair programming. The idea is that two programmers sit tandem in front of one computer and one drives (types the code) and the other navigates (fixes, supervises, guides). Basically, the idea behind this concept is that two heads are better than one, and alot more can be brainstormed with two programmers working on the same code than a single one.

We accidentally tested this method, one day, with our mod development (hence dual development or dualoping - har har). I was struggling to program, when my brother decided to come watch me code (if you can call it that). First he sat there looking at the lines of code on the screen, not really knowing what they all mean. Then, slowly, he began to ask questions about certain lines of code. When I started to answer him, I realized that he was indirectly helping me to see the big picture and some of the mistakes that I had made. Unknowingly, he had become my navigator as I drove drunkly down coding lane in my C++ Lada.

The next time he was modeling, I sat down with him, and I started to observe quietly at first then little by little I gave him some ideas and my opinions on what he was doing. Soon, we were modeling together, asking each other how this would look, how that would look. We also textured the models together and it did not even take us that long to finish our model. Thus we see that the pair programming idea

We would like to also extend this idea to level designing too, and see how that will affect our creations.

To sum up, we extended the concept of pair programming to almost every facet of our mod development, and noticed an increase in the productivity (we were encouraging each other also) and the overall quality of what we were doing. Of course, this is possible if two members live in close proximity, something that does not always apply to every mod team. However, this could perhaps be applied to game developers, who house mostly everyone in the same work place.

On the bright side, if things start to get awry during development, you can always blame the person next to you...

Alive and Fragging

It has been a long February for us the mod team, but we're back on track with the development of the mod! Admissions, exams and all that stuff sidetracked us, but now we're free to work on the mod again. Updates will be coming soon!

The Evolution of the Assimilators

As most of you who have been watching this mods progress, you probable noticed the constant changing of the Combine Assimilator.

When this project began, the idea of an assimilator was that it would be a mechanical machinary that would intake diverse "loots" and output a new, per-say, "gift" to its owners. Since my first modeling experience started because of Unreal Tournament 2004, where the environment usually has a mechanical feel to it, of course I'm talking about some indoor maps and not outdoor maps... Although still being a total "n00b" at this, but having the will to become better, i decided to make it, instead of giving up and getting lazy on my couch and feast upon fattening gourmets all day and crying to all-so boring soap opera stories, no offense folks... Well enough of my blabbering and back to business.

So the first model i came up with was a mechanical monstrosity, also known has "Hog-your-pc-resources-to-render-me-since-i-have-alot-of-polygons". It was basically a sphere with a input, output and legs to support it from the sides. Fortunately that was just an early version created with 3D Studio Max 7.0 which means, no images where taken for it.

The second model was roughly the same principal but then again, its was just too ugly and again too much polygons...

For the third model, since i was initially starting with the Rebel Assimilator, i decided to make something created with other objects. Let me explain. Since the Rebels don't have alot of raw materials and time to make something new, they would rather recycle old parts to create something new. Hence i came up with the idea of having different pieces of everyday objects we see in our lives.


But yet again the polygon count was just too much for a simple object in the game. Just the Green Generator had the same amount of polygons as the others combined together. You might see the generator as a loot though, a stripped down version of course.

At this point, I was starting to become hopeless, I just couldn't understand how to model something nice looking to incorporate within our mod. To relieve some stress, i decided to take it out on the poor Striders who got caught in my way in Half Life 2. Then it hit me. Why not create something that isn't mechanical... sort of, but biological. And after a few clicks here a few clicks there and the concept of the Biological Combine Assimilator emerged.

By using Softimage XSi 4.2 Mod Tool, for the first time, i came up with this hideous monster following this paragraph.


But as you can see, its uglier than anything I've seen till today, aside from the Orca girl or thing who lives next door (shivers)...

After working hard on this concept, I finally came up with this one, which isn't the best thing you veteran gamers have seen, but its actually a big accomplishment for me.


The final model is actually a bit modified than this one, but it mostly resembles it. For the beta release, it will not be animated, since I suck at animating... (that was pretty straight forward there). But I promise till the final release of the mod, which will hopefully be on schedule during Spring 2007, the Combine Assimilator will be fully animated with sounds.

Till then, we thank you guys for the support...

Code and Coder...

We've been working hard on getting the code up first. We basically classed our code development in several stages:

• Assimilator code - we're coding it as a model entity, and we're going to work with the two attachment defined by my brother on the model. The first attachment called "input", is where the Loot is brought back to. I will code a Traceline that is generated from the attachment and when it crosses path with the Loot it will trigger the necessary events, which leads up to the "upchucking" of the reward from the other attachment called "output". Obviously the Assimilator has to run a few more lines of code, where it checks to see if the Loot is in fact on the list, and if yes, tell the list to cross out the Loot from the Scavenger List. Finally, it should chose the reward according to some guidelines as well as give the player points.
  
• Scavenger List- not yet started, this will be also generated at the start of each round and contain a list of Loot that the players need to search for. It would need to search for every Loot in the level, and report the model back to the list. We have to also build a Scavenger List VGUI that can be called up by the player anytime during the game.
• Team Menu - Already up and running, needs to be beautified a little more, as well as fix the Auto Join Crash.
• Round and Timer -The timer needs to be built also, which will be displayed on the HUD on the top center or top right of the screen. It will countdown, from 2 minutes indicating seconds as well. When the counter reaches zero, the round ends. This triggers the round resetting tool to reset the Loot, but keep certain entities in place.

Easier said, than done, but this entry was to show how we divided up our coding tasks into smaller manageable groups.

2007 - Year of the ScRaT

We would like to first wish everyone a Happy New Year. We've been relaxing this past few weeks, but now are back on track with the mod!

Coding wise, the random loot works great now, albeit can be optimized a bit more. Right now, I am working on making the round and round timer work. After which I will shift my attention to working on the code for the assimilators.

The models for the two assimilators are almost complete, they are missing the attachments as well as the final touch ups of the texture. The model will have at least two attachments for the moment. The first will be for the input of returned loots. The second will be the reward generator (output).

For the assimilators, I believe the best route will be to make them into model entities and to define functions for the two attachments. The input attachment will use a UTIL_traceline to determine if a loot has collided with the traceline, then check to see if the loot was on the list and if the player belongs to the right team; if yes, then it will remove the entity from the world. Then it will trigger the other attachment to produce the reward, probably using a pointer to that attachment and spawning a random reward. Next, it will increment the frag count. Finally, it will reset itself for the next incoming loot.

Possible future upgrades to this code would be to sort out different items based on their rarity and then assign different rewards as well as more points.