3D room maker

well game maker is pretty much 2d when it comes to making levels. right? well with this anyone can make 3d levels, and set variables for specific instances. it does not have the ability to be exported to a text file because i dont want to GIVE away something this useful. i'm sure there are other ways of making levels and using dlls to make all the collisions for a REAL 3d game. if u know of some free model designers and ways to make 3d collisions for game maker, well i'd love to hear them. tell me what u think of this program.

http://host-a.net/slayer64/3D%20Room%20maker.zip

When you add an export function, it will be useful to a lot of people. However, this requires you to write a collision system for it. Speaking of which, I haven't seen a single gamemaker game having some good 3d collisions! Good luck.

collisions r already taken care of. here is a slice of code for u.

Code:

if z<other.z+other.zheight
&& z+16>other.z
{
        if place_meeting(x+hspeed,y-vspeed,other)
        {
            x=xprevious;       
            hspeed=0;
        }
   
        if place_meeting(x-hspeed,y+vspeed,other)
        {
            y=yprevious;
            vspeed=0;
        }
}

this code will make the current object stop and SLIDE against it. it only works for horizontal and vertical walls.
and have you seen Mega Block Man. its a game i made. look on YoYo games for it.

OK, that's great! Now onto the next level, where things get one hell of a lot complicater: slopes! That's were the fun begins

Also, when exporting, don't forget to use speed technique 6.

Quote :

Technique 6
Caution: This technique only works if you know exactly what you're doing; otherwise it will lower performance.
Generate terrain to big models. For example, if you have a terrain with grass and ground, generate all grass to one big grass model, and generate all ground to one big ground model.

In other words, if you have multiple boxes with the same texture, you could generate all those boxes to one big model. You keep the actual objects, and use them for collisions, but they don't execute a draw event. The controller should draw the big model.

Making the whole room 1 model.

yea i was thinking about that. but then? what if? i wanted a draw distance. if it was 1 model then that would be impossible, right? here is a piece of code for slopes, just a square object with the right z being higher than the left z.

Code:

if x<=other.x+32
{
    ds_list_add(list,other.z+(x-other.x)/4)

    count=0;


        do
        {
            z+=.1
            count+=1
            if count>20 break
        }
        until
            z>other.z+(x-other.x)/4
}

its OLD code so in new code i would probably make a while statementinstead of a DO. the ds_list is for storing the z and then finding the highest one after the object has collided with all floor objects. like if it was on an edge and collided with the one underneath. i would replace ds_list with an array in NEW code.

I don't know what kind of game you're going to use this room editor for, but in my current FPS engine it is actually faster to draw the world as one big model.

well the game im making isn't graphically demanding so it wont really matter either way. my laptop has a 1.73 Ghz processor and nothing lags so far, and there is no draw distance. but i was thinking about other people who have a really old computer. i agree that one big model is definitely faster than multiple draw events.

slayer64 wrote:

i agree that one big model is definitely faster than multiple draw events.

Not for racing games, or any other type of game which requires gigantic levels! In that case you should make areas, each with a big terrain model.

oh of course. GTA isn't one big model right? its different sections loaded in when they are needed. so i guess fewest models and draw events are best.