| RTCM: |
James Tan, Could you please tell me the name of your final demo and why it has been called the final demo? |
| JT: | Ok ready. ( Finally my first interview! )
The name of the final demo was labeled Brute Force: Alaskan Dawn.
The reason why it was the "Final" Demo was that it was the last demo that was
going to be released.
No more demos would have been released before the actual total conversion.
There fore I called it the final one. |
| RTCM: | ya ya, besides that. Why the switch to Metal Gear? |
| JT: | Well, people have been e-mailing me saying these:
I) Metal Gear had this ... will you?
ii) Metal Gear got this ... put it in!!?
ii) Are you just ripping of Metal Gear??
And with alot more, I just decided to give it a go at recreating a living legend -- Solid
Snake. |
| RTCM: | Well that makes total sense for the switch. Back to the Brute Force Demo.
Which version of duke is required to run it? |
| JT: | The version required is 1.4 and upwards.
It was originally built on version 1.4, and never was built on any lower versions.
So versions 1.4 and upwards, 1.5, 1.6 or whatever will work... in theory.
|
| RTCM: | Well nice of you to throw in those obscured versions to mess with
newbies... Should we now take a look at your packaging of Brute Force. Its fairly straight
forward and simple. Most Conversions tend to add a huge front-end, instead you choose the
.grp file format and a simple batch file. Pure and simple.. why this route? |
| JT: | Simple is always better.
I mean, when you have to load up a huge front end to go through all the rubbish now ...
people just say .... what is this the game?
Plus, I already felt the download was huge enough, so why bog it down with a big
front-end?
|
| RTCM: | That's the way I like it! Lets take alook at your Dynamic lighting
effects. Could you explain to me how this works? |
| JT: | Basically, now I feel this idea has been distributed quite unfairly.
Everyone claims they did it, no one in particular, but never proved it.... but anyhow.
Basically I calculated the distance from the lens flare actor to the player.
Then in the version I had it would get smaller when you went close, and bigger if you were
further away.
The ifpdistl command did this. Then after getting the light size, we could just use
platform * * * * to provide the effect of looking into the light beam it self.
And basically that was all there was to it, I could have made it more complex, but this
simple thing did the trick, and that was all I really wanted to do.
|
| RTCM: | Well I'm unaware of the author's "rights" and such or what not.
That usually doesn't matter other than reference. But the Lighting was most effective in
the Brute Force Demo. The second thing I noticed was the .Wav music, and its response to
the players health level. It was a bit to loud to enjoy the rest of the sounds... are
there any plans on adding control to .wav music in the Eduke version of Metal Gear, the
sequel to Brute Force? |
| JT: | In Metal Gear it has been controlled and done for Event based music.
So if you are caught or sighted by the enemy it will play the very popular
"Encounter" music, which loops and is exactly the same as the PSX version.
Other music will also play and they are all event based. Pre-loading is essential now,
because you don't want to be facing a group of terrorists and them shooting you while you
are waiting for it to load!
Preloading means it will load the required music at the start, and then it will be stored
in the memory, and then played when it is needed.
The best advantage of it is, is that the mapper of the map gets to decide what music will
be in the map. It is efficient and a very cool feature to have.
I am sure it will provide mappers more power in creating a better sense of atmosphere
within their maps. |
| RTCM: | Yes I noticed the CD type delay when the .wav music would play... Glad to
know you improved it. How about the accuracy shots... At one time I was aware of a hit
location that can be added to actors... is this the same or something different? |
| JT: | Well the accuracy thing in Brute Force was rubbish. I just made it up to
give players a bit of fun.
Accuracy is more seriously dealt with, now that I have Eduke. I am planning to do
locational hits, but if the idea slows the game play down I will cancel it.
The thing with locational hits is that each and every actor has to spawn several other
actors, to identify the certain points, so they can react to it.
With this many actors around it would most certainly slow the game down, but as I do tend
to have better creation of levels and less enemies it maybe possible to do it much better.
I haven't started the coding, but it is darn easy to do.
|
| RTCM: | Would it be possible to use visibility range to increase frame rate, or is
this something the Build game doesn't tailor to, less rendering of distant objects? |
| JT: | I am not sure if Build has the same technology as Quake, in which it uses
mip-maps to use less memory, but fiddling with the visibility range isn't to good a idea.
It is in some cases but since it can never be changed once the game starts (as far as I
know), it is better to leave it alone.
But all in all, it maybe possible.
But Metal Gear runs very smoothly so far on my test bed, which is rather slow.
|
| RTCM: | Okay, now the art work... it appears that it has been given a mosque
effect , it actually appears to be less pixeled than most conversions. What's the secret
here? scale? |
| JT: | Yes less pixeled, true in the Brute Force demo. The thing I think is that it
looks better that way. The reason is that everything fitted into each other. Imagine 1 art
with alot of detail sitting next to 1 without so much pixels. It looks horrible and gives
a horrible edge.
I simply loaded up Adobe PhotoShop and did a blur effect. I didn't apply to much but it
achieved a fake hard ware rendered mode.
|
| RTCM: | that is the impression I got instantly. The enemy actors seemed smooth and
life like, including the die animation. The overall scale you used on your demo map seemed
to be a bit to large compared to dukes actual height, Was this something to do with the
use of the art or size of the artwork? |
| JT: | Yes the artwork for the enemy was pain staking. hours and hours...
The original heights for the enemies were giants.
But in the game, they would be sized down, by using the sizeat command. The reason why I
did this was that I hated the fact that the enemies in Duke the original got chunky when
we got real close to them.
But in my TC they don't get so chunky, and that is good since we wanted to crack their
necks :)
But they were probably a little larger than Duke ... I think that the Duke art is too
small compared to what he sees in 1st person view.
|
| RTCM: | I see, larger artwork presented a less pixeled close view of the enemy.
Neck snapping, you have to love it. Activated by sneaking up on them and hitting the use
key. Why is it possible to sneak up on them? |
| JT: | Because I developed, and was the first to actually prove it, that the
enemies had a field of vision.
I mean aliens ... ok they would be able to sense you with whatever they got. But us humans
have only got 2 eyes for vision, and we can't exactly see what's going on behind us.
So this had to be developed for realism.
|
| RTCM: | The doors , I noticed too types.. one activated by approach, the other
appeared to have switches on the doors themselves. The second door was most interesting,
and seemed like a great demonstration of a Blast door. What was your reasoning for
creating such a door? |
| JT: | It was cool and the basic fact no one else did it before. I like creating
new things and displaying them.
No one had done it, and it was quite easy to do it, so why not? Plus it looked good and
created a more technical world.
It also displayed the power of con programming. Which was one of the best parts of the
demo. |
| RTCM: | Since Brute force is a technical marvel as far as new and interesting
effects, the way they should be done... do you care to offer details of your Blast Door
coding? |
| JT: | not a problem. The original idea was to make a sprite with an animation and
then close.
I saw this in Descent, hence the graphics.
Basically I made the sprite blockable and hitable when it was closed. When the player shot
it, or approached or activated it, it would open. When it was open I turned off the
blocking and shooting factors.
After a while (ifcount) would close and return to its previous state.
|
| RTCM: | Don't feel as though I'm nit picking here, since I'm aware of limitations
with the Build game. I noticed invisible walls above the dead enemies that are only
blocked for bullets. Will this be improved in Metal Gear so the players shots can
"travel" over a dead body, or is this something that can't be prevented? |
| JT: | Yes this is indeed a problem and I am addressing to that. I am sure it can
be prevented.
I noticed that and it was annoying, but one way to do it now is to simple pick up the body
and drag away ... as since in Metal Gear your enemies will be alerted if they spot a dead
terrorist lying around. |
| RTCM: | How much improvement will be on the A.I. overall.. The Brute force Demo
demonstrates the needed A.I. functions effectivaltly. How much more A.I. coding will there
be, and will they respond to sound or shots fired? |
| JT: | The AI is extremely smart ... and in some ways stupid.
-The enemies will respond to sound and go searching for it.
-The enemies will demonstrate attack in groups and ordered precision.
-I am also developing shadow detection's.
-Weapon selections is also an improvement.
-If you are in a vent they will (joyfully) through a few grenades in to spice things up
inside.
-A lot of AI will be added, and most of the time it won't be ordered.
Things happen differently and the player learns how to attack differently, so shouldn't
equally the enemy learn too?
Lets say you started to strafe alot ... so why not give them the power to predict where
they will shoot to get an accurate hit?
Or instead of just following you they could take another route and meet you face up?
|
| RTCM: | Yes I agree, but we shouldn't confuse the learning process of the A.I.
will something that will learn and grow over a period of time... this would require some
variables saved and accessed overtime. But during the course of the game I'm sure this is
highly possible. Your zoom effect is slightly different than what I have normally seen...
and slides right into view. any plans on using step zooms, perhaps 50% and 100%? |
| JT: | Yes.
That is all possible now.
But zoom is limited, as if you shoot when you are that big the angles get weird.
|
| RTCM: | Well I found it best to include a second crosshair point for shots at
zoom, it works. How about your Gas tunnels and Gas mask. I assume you used a bit of
lighting or platform effects for this aswell. What else went into it? |
| JT: | Not much really, since it was a very basic effects.
Nothing else was added, except the detection of gas is slightly better.
|
| RTCM: | Are there any other effects you would like to mention and detail here now
that will be used in the Metal Gear conversion? |
| JT: |
-Weather is an interesting one.
I realize it's old and was done a long time ago, but it never really took off.
Only this time I made it, and it looks great. Works wonders for maps and atmospheres.
And most importantly it runs FAST.
-Transparent water is 100% complete and works better than the one shown in the Eduke
patch.
-mmm ... I have a true physics engine now, which is actually separate from the coding and
is constructed by tables and state sections...
-What I can say is that the Duke Build no longer functions like it did. It works more like
the Shadow Warrior engine in which I have based my ideas on.
Hi tags and lotags for sectors are used alot, so expect a full documentation on all the
functions.
|
| RTCM: | Finally a separate engine for effects.. will the physics engine be
adjustable from the user con?
The reason I ask is that in the past there where a few minor 'coded engines' that where
adjustable. |
| JT: | Yes and no ...
Basically some mass(s) are already predetermined and some acceleration forces are
predetermined.
Such as the fact gravity is 10 meter's/s always.
So messing around too much can cause problems as the physics engine does all physics in
the game, that aren't hard coded of course.
But a new file called PHYSIC.CON is the coding for the physics engine.
UI.CON has been created in place of User.CON which allows people to adjust almost
everything in the game.
SO basically the engine I create is quite user friendly and I do encourage people to edit
it ... once it is released of course.
Full documentation is provided, and the source is an open source code. None of the
compiled con stuff.
|
| RTCM: | Not only will Metal Gear be something to really wait for.. your adding
documentation that most conversion lack and I'm assuming only your FINAL Metal Gear
release will be uncompiled... I see to many conversions compiling there code with
intentions of never releasing the cons, this greatly loses value in the mod, not only in
popularity, but respect.. since where all suppose to be on the same side. What should
dukers that are waiting for Metal Gear know before they check it out? |
| JT: | The download for MGS will be unfortunately very large.
Quite a reasonable PC will be needed. My test bed is a Pentium I 133 Mhz , 16 MB Ram. So
as long as anything higher than that things shall be ok.
You will absolutely need Eduke to play MGS.
Anything lower Eduke version 2.00 will not work for MGS unfortunately, as the physics
engine cannot be reduplicated on 1.4 cons.
So if you have Eduke, a reasonably fast PC and got a fast modem, all you have to do is
wait!
The waiting part is unknown. I have no idea when this will be done, but I hope soon.
The FINAL version of Metal Gear will be uncompiled, the CON files split up for your
convenience.
FULL documentation and everything, e-mail support as well. I want people to enjoy creating
a MGS experience themselves.
Not everyone can edit Duke, but with help everyone can become good at it.
|