Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
Guest PFCRon

Sounds impossible, but.......................

Recommended Posts

Guest PFCRon

Does this sound ludicrous? How about there being no difficulty levels in the game? Instead, how about the game never bein played the same twice? Like, say the first time you play it, there's, oh, maybe 1 or 2 monsters in the room you start and a shotgun or some other low-level weapon on the floor and maybe a blur artifact. Then the next time you play, you start in that same location, but now there's like 5 Imps on your ass and no weapons or power-ups on the floor! Makes it a little harder doesn't it? Get what I'm saying? Complete randomizaton! Nothing would play the same twice! The only thing that would stay the same would be the layout of the levels. Other than that, items in the level would change as well as the enemies. And starting the level over would change it all again! Somethin like this would make strategy guides useless. I like that, despite how much I use them AFTER I beat the games.

Share this post


Link to post

Thank God there´s a J/K on your sig. Seriously.

Anyway, a random entity placer could do disastrous things. First than all, you can´t ensure the game´s finisheable. The job to code a randomizer who does balancing by itself it´s hilarious. Ask any level designer out there.
The other problem are scripted sequences, they get screwed.
I can imagine thousands of bugs, armors over roofs, enemies under the water, objects blocking triggered events, etc...

Share this post


Link to post
Guest PFCRon

All the more reason to put it in. Makes more of a challenge. But, that's just me.

Share this post


Link to post
Zaldron said:

Thank God there´s a J/K on your sig. Seriously.

Anyway, a random entity placer could do disastrous things. First than all, you can´t ensure the game´s finisheable. The job to code a randomizer who does balancing by itself it´s hilarious. Ask any level designer out there.
The other problem are scripted sequences, they get screwed.
I can imagine thousands of bugs, armors over roofs, enemies under the water, objects blocking triggered events, etc...

My friend made up some randomization code and merged it with the quake 2 code.

The result?

Well initially, there were a few enemies swimming underwater (try gladiator, and big, big tank guys), and a few guns in lava, and an armor seeming floating in space, but not able to be had.

After a few kinks, he re-worked it so the makron didn't appear out in space anymore and such.

How did he do it?

Da hell if I know! I looked at the code, and its confusing as hell, but he said that he put in some checks so the comp would check a vector from point A, to point B (in three dimensions mind you).

So if it moves the entity from point A to point B, and figures out its getting close to a wall, or a floor, or somethign else, it will keep it where it is. If there is no conflict, it will be moved from point A, to point B.

Still, some poor jerks were placed in what would be mid-air if yo'ure standing on the ground.

The code was pretty cool, and it prevented alot of stupid stuff, but it managed, (somehow) mostly through the VERY GENEROUS, use of dynamic arrays of arrays, to eat up a (net change, not absolute value) 58% of my system resources (and the funny thing was I was running on my gaming machine: the damn thing has well over 300MB of ram!)...

Share this post


Link to post

WTF?

How refined was the space matrix? If you wanna do a super precise entity placer, then you have to store a big matrix in the RAM with the XYZ cube positions.
Imagine the problems, enemies over tables or even over stairs ledges. A volume checker to prevent clipping can be done, but a selective "realistic" object placer.. hell, I don´t know how to even imagine a brute force solution.

What was the B selection process? A brute force raycaster? I can easily imagine all that preconcept stuff piling up in the RAM.
Thrown the hard-to-do bezier patches / object clipping calcs and you are officially screwed.

No, I think there´s no good solution to the problem, at least good enough to pull out "32-bit seed" endeable GOOD SP experiences.

Share this post


Link to post

What effect would that have on demo recording?

What effect would that have on scripted events?

What effect would that have on gameplay balance?

Certain enemies will behave in certain ways. They will also have their own attributes: size, speed and mode of attack. It is these very attributes which determine the proper placement for good gameplay.

Share this post


Link to post
Zaldron said:

Thank God there´s a J/K on your sig. Seriously.

Anyway, a random entity placer could do disastrous things. First than all, you can´t ensure the game´s finisheable. The job to code a randomizer who does balancing by itself it´s hilarious. Ask any level designer out there.
The other problem are scripted sequences, they get screwed.
I can imagine thousands of bugs, armors over roofs, enemies under the water, objects blocking triggered events, etc...

Ok... What does J/K mean? I still have no idea....

Share this post


Link to post
Zaldron said:

a random entity placer could do disastrous things.

Not if they manipulate it. There could be an object that does something like "place 3 imps, 2 demons, 1 spectre and 1 lost soul, or 1 Revenant". So they wouldn't have to place random objects if they didn't want to, but random powerups and occasional random enemies of similar difficulty would be a good idea.

Share this post


Link to post

I think the only way to fix this is to forget completely about the random factor. Instead, make an AI powerful enough to make creatures "curious". So they´ll continually change their positions based on boredom/sounds/other creatures. That way you´ll never know where you´ll find them.

Share this post


Link to post

There is nothing wrong with randomization as long it's done with enemies and nothing else. I myself put a post up on this very same thing a couple moths ago in January and a lot people seemed to like the idea.

Share this post


Link to post
Zaldron said:

WTF?

How refined was the space matrix? If you wanna do a super precise entity placer, then you have to store a big matrix in the RAM with the XYZ cube positions.
Imagine the problems, enemies over tables or even over stairs ledges. A volume checker to prevent clipping can be done, but a selective "realistic" object placer.. hell, I don´t know how to even imagine a brute force solution.

What was the B selection process? A brute force raycaster? I can easily imagine all that preconcept stuff piling up in the RAM.
Thrown the hard-to-do bezier patches / object clipping calcs and you are officially screwed.

No, I think there´s no good solution to the problem, at least good enough to pull out "32-bit seed" endeable GOOD SP experiences.

I asked him again (and unfortunately i'm only a third year programmer so maybe i'll get him here to explain it) but anyway...

Basically he made code that would move an object from point A to point B in 3D x,y,z, now he would run checks on the object and if it encountered an obstruction it would return to point A.

All the arrays were to store the xyz coords of the entities, and the miscellaneous data in comparing them to walls other entities etc.

The selection for point B, was determined by a random set of parameters, within a certain 3d radius...picture a sphere with center of point A.

The radius of the sphere was: and a radius of K+R

K: is a constant that was the minimum radius so that any part of the entity's wire frame would just be tangent to a sphere derived from a logical center in the entity's wireframe.

R: is a random value generated

The drawback was you could move an object within a room, to say the other side, or down a flight of stairs, but room to room was difficult...alot of funny things would happen like only heads and guns sticking out of walls and floors =) But he prevented (most) consumables and mission critical enemies/items from having too much of a change, cause it happened a few times, that you were locked out of a room, and the key you needed was inside.


UPDATE:

Ok..I just called him up, and he reluctantly told me for the 55th time how it worked.

He says that in addition to the the 3 dimensional arrays for the objects, he implimented some that to stored the xyz coords of each vertex in a level. So all of this means that only "known" maps could be used with it.

To make a map "known" it happens when you actually compile the level in an editor (i've only made a few Q2 maps, so i'm not that familiar). A separate program that creates the files sets aside a huge chunk of RAM and copies and stores the X,Y,Z data for the map to a file.

The stored data is then called upon and, loaded into the RAM (hence the huge amount of system resources that were eaten up) and as the level is being loaded in the game (i.e. you just went from one area to another and you get a loading screen), the randomizer starts after the standard entity placement code, and makes it's own placements.

He said the RAM penalty was not mostly in the data itself having to be loaded, but the 1.0 * (10^55) (some god-awful big number) of checks that had to be done.

/me goes ::puff:: ::puff::
"Man...that took alot of typing."

Hope that clarifies it.

Share this post


Link to post

Thanks, now I know what he did.

How about for the ground units to simplify the position by making their bounding boxes tangent to faces with normals that point up, and with a predefined maximum and minimum angle?

That way you´ll place enemies on safe ground and slopes. You must do a volume checking routine, so the enemy won´t get clipped, but that´s it. I think that would be faster, but I´m not sure if Q2´s flexible enough to perform vertex-based analysis on each level triangle.

Share this post


Link to post
Guest
This topic is now closed to further replies.
Sign in to follow this  
×