How to create "rooms"
Blitz3D Forums/Blitz3D Beginners Area/How to create "rooms"
| ||
| Hi there! I am very new to Blitz 3D, but not new to game-making. I first started with RPG-Maker 2000, then changed to RPG-Maker 2003 and finally programmed with the Game Maker 5.3a and 6.1. But now I really want to create my own 3D games and I have an interesting question (probably only for me...): How do you create rooms? In the listed programs above you've had only to "add" a room by clicking a symbol. So how do you realize this in B3D? My idea is to create seperate *.bb files for every room. Correct me if this is incorrect. And another question is: How to you change the location, room to another room, eg going through a door and then you are in another room?! If you can help me, that would be great! Thanks in advance, Michael aka Banjonator |
| ||
| Well, you wouldn't exactly create separate .bb files. You could use 'Maplet': http://www.blitzbasic.com/Products/maplet.php Maplet is free: http://www.blitzbasic.com/file/get.php?file=/Products/demos/MapletSetup101.exe |
| ||
| Yep... I got Maplet when I bought Blitz3D. It should be downloadable. You can create rooms in it OR you can create bigger levels areas in it. It does take some messing around with to get good with it. Maplet is a great introductory tool. It does have its limitations but since you are just dipping in to the waters of programming so to speak... it is great. Make a room then make a map... try both... :) RZ |
| ||
| >How do you create rooms? >In the listed programs above you've had only to "add" a >room by clicking a symbol. So how do you realize this in >B3D? When you call Graphics3D, you start with a completely empty world. 'Rooms' can be done in hundreds of different ways and part of the fun in programming is figuring out how YOU want to do it. You can do it in code or model every room individually. Check out the documentation that is included with B3D, and look for the CreateMesh command. This is how you create a mesh. Now you need to figure out how you want your 'rooms' to look. I would start out by making a mesh shaped like a box, with the faces facing inward, and with thick walls. make a mesh for each type of room, for example if the room is a dead end, you only have one door. When this is done, you have a set of building blocks, very similar blocks(like LEGO), but by using CopyMesh, you can create new rooms and position them in your world with PositionEntity. When you have built a small maze of rooms, you should start working with UV coordinates(for texture), so that you can add different details to every room. Then you should start working with collisions, so that you won't walk through walls. Now you have a very basic wolfenstein type game, and you can start worrying about optimizing it, but that's for a different post. >My idea is to create seperate *.bb files for every room. >Correct me if this is incorrect. Blitz3D is not a scripting engine, so you would be better served making it one single file for the moment. When you have a better grasp on B3D, then look up the Include command. >And another question is: How to you change the location, >room to another room, eg going through a door and then you >are in another room?! You move the camera. Andy |
| ||
| Hmm, it seems that you have misunderstood me. I know how to make the "rooms", actually the models / meshes. But what I mean is: ------------------------------ Remember Metroid! There are hundreds of rooms, but they are not placed next to each other. The load shortly before you open a door ... and then you can enter this room. So, if I want to make a game like this, with many rooms, I am sure, that I don't have to create a huge over-world like "Tallon IV" (Planet in Metroid Prime) in T.ED, Maplet or anything else. I am sure, that I will create them seperately and then place it to each other. But all that in one *.bb file? So if I want to "travel" across the overworld, there would be coordinates from -5000 to +5000 in x/z direction... So I thought I should make an own *.bb file for every room I have (every mesh) and if I open the door, then I will "jump" from one *.bb file to the next *.bb file where the room I want to enter is located (stored) in. I hope you understand now what I mean. If not, I will have to find out myself. :-? Thanks in advance, Banjo |
| ||
| You don't hold them in the Blitz source, you just load what you want, when you want. No, you wouldn't jump from .bb source file to another. Technically, you could use separate .bb files as 'include' files - but they all go into the same source code as one. Just load the meshes that you want, at the point you want them, just remember to free them after they are not needed. You just need to load each mesh (room) at the point you want to enter it, all the rooms will be on your drive as separate meshes (rooms). |
| ||
| >Hmm, it seems that you have misunderstood me. No, you failed to make yourself understood. >I know how to make the "rooms", actually the models / >meshes. Good, that one hurdle out of the way. >I am sure, that I will create them seperately and then >place it to each other. You make one create_room() function, and then you use different arguments for each room. I would create s room definition file for each room, describing the room. Give every room a unique number and use that as a filename. Every definition file should include: -Description of the room -names of textures -the numbers of the adjacent rooms something like: filename: 100543.dat "This is the kitchen" tiletexture1.bmp detailtexture9.bmp 100240 ; north 0 ; south - no door to the south in this room 100953 ; east 564 ; west When you enter a room, then you load the definition for that room, display the room and store the numbers of the adjacent rooms. This way you are only limited by the size of your harddrive, as to the number of rooms you can have. >But all that in one *.bb file? Forget about seperate bb files. Blitz is not a scripting engine, so if you create a bb file for eact room, they will all be combined into one when you compile the program. It will add massively to the filesize, and be generally unmaintainable. >So if I want to "travel" across the overworld, there would >be coordinates from -5000 to +5000 in x/z direction... Yes, or you can reset the coordinates at regular intervals, basically moving the world around you, thus avoiding floating point and Zbuffer problems. >So I thought I should make an own *.bb file for every room >I have (every mesh) and if I open the door, then I >will "jump" from one *.bb file to the next *.bb file where >the room I want to enter is located (stored) in. Make a generalized Create_Room() function, it will be easier to maintain and debug, and you can make sweeping changes without having to recode the entire game. Simple almost always beats complex, and in this case it certainly does. Andy |
| ||
| I think he means "areas" instead of rooms. An area can have a few rooms, combined with corridors. Like Half-Life, you walk from one area into another, but each area has a few rooms and corridors. By exiting an area (going through a door), you unload the area you were in and you load the appropriate area where that door leads to, while the center of the new area is located at coordinate 0,0,0. How it is done exactly, I don't really know, because I've never used this before (I haven't created such a big game that requires areas). But when you reach your door (EntityDistance ?), unload all current level-data (ClearWorld), load your new area (LoadAnimMesh ?), reposition your camera (PositionEntity camera) to where it should start (depending on where you entered the new area), and off you go, into your new area. Something like that. Pseudo-code:
If EntityDistance(room, camera) < 1 then
ClearWorld
LoadAnimMesh("Levels\Area2.b3d")
camera = CreateCamera() ; Camera was deleted too by ClearWorld
PositionEntity camera, -100, 0, 5
EndIf
|
| ||
| No matter if it's a room or an area, your program must be able to load a "room" and some parameters. The definition file suggestion is the way to go. You need a game engine that is capable of loading any room without to start a further program. as somebody mentioned before, all you need to do is unload the current meshes, reinitialize some variables and the load the new room. That's what I do too in my game engine, although it doesn't require to open doors to go to the next level (like "room"), but to accomplish a mission. One single Game loop is capable of loading an unlimited number of levels. That's the way almost every game engine works these days. So you could use a function call to unload the current and load the next room. After execution of this function the main game loop would continue normally. |
| ||
| >Hmm, it seems that you have misunderstood me. No, you failed to make yourself understood. I think he misunderstands us. The problem I think he has is that he essentially thinks Blitz is another point and click game creator. In the listed programs above you've had only to "add" a room by clicking a symbol. So how do you realize this in B3D? Being that Blitz is not a point and click game creator, it is a FULL programming LANGUAGE, you have to understand that you have to tell Blitz how to do every single little action in an almost specific order... you know what C++ is, right? Blitz is like that, except it's quicker, easier and actually makes sense :) This might seem like a massive leap from a semi-automated game creator like the ones you are used to, but once you master it it gives you much more control over your game. To use Andy's example, let's take a few square room meshes and join them together... in pseudo-code because I'm no Blitz3D expert... Graphics3D 640,480,32 ; Open a fullscreen app at 640x480x32bits.
room1=LoadEntity("room1.b3d") ; Loads a 3D object (in Blitz3D's proprietary format) and assigns a handle to it's location in memory to a variable named 'room1'
room2=LoadEntity("room2.b3d") ; Let's say each mesh is 20x20x5 units in size...
camera=CreateCamera() ; The Camera is of course what's used to view the world through your screen...
; A camera also needs a place to record information about itself (x,y,z positions, the way it's facing, etc) so the variable 'camera' is given a handle to where that data is stored in memory.
AmbientLighting 128,128,128 ; Some basic 'everywhere' lighting so that you can see your meshes - the three values are of course for red, green and blue
PositionEntity room1,0,0,5 ; This moves the mesh that is referenced by the variable 'room1', to 0 on the x and y axis and 5 units on the z axis, so the floor of the room is at 0.
PositionEntity room2,20,0,5 ; 'room2' is placed directly to the right of 'room1'
PositionEntity camera,10,10,1 ; The camera is placed in the middle of 'room1' 1/5 of the way up off the floor.
Repeat ; One of a few types of loops - Repeat-->Until
Select GetKey() ; If GetKey=...
Case RIGHTARROW ; If GetKey=RIGHTARROW Then...
RotateEntity camera,-10 ; Rotate the camera by 10 degrees clockwise
Case LEFTARROW ; If GetKey=LEFTARROW Then...
RotateEntity camera,10 ; Rotate the camera by 10 degrees anti-clockwise
Case UPARROW
MoveEntity camera,.5,0,0 ; Move the camera half a unit in whatever direction it's facing
Case DOWNARROW
MoveEntity camera,-.5,0,0 ; Move the camera half unit backwards
End Select ; End of the condition
UpdateWorld ; Makes Blitz calculate the new positions of entities amongst other things
RenderWorld ; Draws the camera's view to the back buffer
Flip ; Swap buffers (for double buffering) - brings the back buffer to the front (starts showing the stuff just drawn) and the front buffer to the back (to start drawing on it)
Until KeyHit(ESCAPE) ; If the Esc key hasn't been pressed, go back to the top of the loop
EndAgain, I'll stress that these probably aren't actual Blitz commands, but they are very close approximations... so you can see how the language is structured and how it works, in it's essence... Hopefully it helps you understand some of the differences between Blitz and the programs you've been using before. |
| ||
| To be honest, Toby, this example may confuse more than it enlightens. RotateEntity takes 3 Angle Paramters for an absolute Orientation. And Moveentity with the arrowkeys up and down is usually used with the Z-Direction, so the character would walk forward and backward. (moveentity c,0,0,1). One thing that seems to be very important to me that was mentioned before is: When you have a definition file for each room-mesh, that may be a simple textfile and is parsed by your app using the ReadFile and ReadLine Commands, you need to assign a unique number to each room. Additionally you need to assign a room number to each door in a room. So when a room has 4 doors (north, west, south and east), then each door "knows" exaclty what room it will teleport you to. And yes, it may even be possible to teleport far away to an other room that is not a physical next-door room, so to say. Let's say your definition file is named: 123.def So you would open the file, read the mesh file path and load the mesh, read all door number codes. Let's say the door on the east side has code 543. As soon as your player opens that door (detected by eg. MeshesIntersect with an invisible Box that is positioned around that door), you will: FreeEntity the current room and all it's additional stuff Reinitialize some variables Open 543.def Read the mesh filename, read the door codes of this room. If you think this number system is confusing, you may also use a name that is built from the rooms theoretical position, eg. 2-3.def and 2-3.3ds etc. depending on where the room is in a grid of rooms (x and z number of the room). Adding a room would them only mean to model a mesh for it and write a small definition file. So when there was no room in the south of room 2,3, and the door was locked (eg. by using a code of Zero that would signal your engine that it's locked), all you have to do is edit the Zero Code to a valid Code in the current room, then add the files (definition and Mesh) to the game folder. It may take more than one klick, but that's the way it is... 3D is a huge beast and you gonna spend hour after hour for bsaic stuff, so don't worry about a few clicks and hits more. |
| ||
| You aren't limited to rooms anymore. You aren't limited by much of anything except your own imagination and what the hardware is capable of. Since you probably don't want to keep the entirety of all the levels in your game in memory, you will need to break things up; however, doors are often not the best way to do this. While there have been quite a few games where you're confined to a room until you click a door, then teleported to a new room, (optionally with a cutscene of a door opening,) I can't say I liked the experience of not being able to walk (or fight) through the door myself. My suggestion is to use large, overlapping areas of your map, each containing tens of rooms, doors, and hallways. The overlap is important so that you can teleport your player to the new map (unloading the old one) and have them seem to be in the exact same place they were before you wrote the word "LOADING" to the screen. This is likely how Half-Life and its sequel work, Halo, and a lot of other FPS games. The key to this method is choosing an overlapping area which doesn't allow the player to see too much of the map in either direction - long corridors with bends at each end are quite popular. I don't remember waiting for anything to load in Metroid Prime. My money's on them using the same approach, but with a very advanced loading system which works quietly in the background. Good luck and happy hunting! |
| ||
| I started off thinking I understood this argument but now you have lost me. If it is about areas try Quill 3d map builder. That uses areas and portals. |
| ||
| I think I understand the basic idea behind it now. Thanks for your support. :) @octothorpe: Have you ever tried to enter a "Secret World" in Metroid Prime? If not, then you can't see that areas are loading shortly before entering them. Just try it once! (if you don't know how to enter a secret world, visit: www.samus.co.uk) |
   |