VBGamer (© 2002) - The VB Adventure Maker

The VB Adventure Maker
VBBR	I was just wondering, would it be OK for me to create a thread for my current project, like masterbooda did for his engine? So users can be updated with the development status and post commens, suggestions, etc. Also it would be good if I could release some small tech demos here.
VBBR	All right, this is it. If someone sees my profile, will know that The VB Adventure Maker will have to wait a little. I have two main reasons for that: 1) The stupid important-and-paying project is STILL using a lot of my free time; 2) BSP support for R3D hasn't come out yet, and I need it so I can experiment and see what is better, to use or not BSP maps. But don't worry, as soon as issue 1 is solved I will start work on something different, something unique... see my new sig. [;)]
Almar Joling	Maybe you can convert an OGL BSP loader tutorial, like on www.gametutorials.com
VBBR	I think it's better to wait a few weeks for a fully-integrated and optmized loader than write my own meanwhile. And besides that, I wanted to take a break on this project too.
Eric Coleman	I'm not sure why you are asking. This is a vb game programming website. [:)]
VBBR	Thanks! So, from now on, this will be officially "The VB Adventure Maker Thread" !
VBBR	First, here is the installer for the Revolution3D Engine runtime files (one will need this to be able to execute the program and games created). [url="http://www.freewebs.com/hxs2/files.htm"]Download it here[/url] Now for the development status. In the proccess of developing the runtime module I kinda accidentally created a rather stupid 3D maze game. So, if you like to be running around a confusing maze, this could be kinda fun to you. Get the maze game from the link above. The controls are as follows: - Arrow keys: move - ESC: exit A default map comes with the game. You can create your own by editing the map.txt file inside the DATA directory. The map can have up to 100x100 tiles in size. While editing the map, use the characters as follows: - X or x: wall - . (dot): floor - blank space or whatever other character you put there: will display nothing The player ALWAYS starts at position 2,2 and is looking downwards. NOTE: The game may take a little while to load depending on the speed of your computer; please wait a little before considering a crash. Also it takes some time to release everything when it's shutting itself down. Please test/play this mini-game and tell me what do you think of it. If you experience any problems with either the R3D setup package or the game itself, please let me know.
2dcoder	oww man!! I was really getting kind of interested in this project until you posted you use someone else's engine!!!! I thought it was going to be a VB exclusive project? Wass up?? Get rid of the external engine and code it in 100% VB!!! THAT would be cool!
VBBR	Well, I guess it would, but it's the FIRST game/program I ever create in 3D... so I tought it would be better to use a ready-made engine (and that's not a shame at all--Revolution3D is a great engine and the majority of its users are VB coders; in fact the earlier versions of R3D were coded in VB, but then switched to C++ for an increase in speed (and possibility of using DirectX9 unmanaged). Now let me clarify something: Revoluton3D is a graphics engine, all it does is the rendering part. It is not a game engine. This I'm coding myself, in VB. Revolution3D is not an engine designed for games specifically, is only deals with graphics and DirectX stuff, more like a DirectX wrapper. I don't consider a shame to use someone else's rendering engine ('cause rendering engines out there are pretty much the same)
Eric Coleman	using other people's graphic's engine's are probably the ONLY way to create a real 3D game in VB. It's not that VB can't do it, but there is just so much work involved to create the engine and the game, it's best to just use an already made engine and then start work on the game. There is also the "Truevision" engine, but it's really just a directx wrapper, not a graphics engine. And there is also Genesis 3D, which seems like a really nice 3D engine. The screenshots look pretty cool.
VBBR	I've looked at Genesis3D and Truevision, but I prefer to stick with Revolution3D because it's free even for commercial use. All it requires is an R3D logo displayed for 3 seconds inside your app. I also think screenshots depend more on the author of the app than the engine itself. (BTW, from the next version on R3D will support Pixel and Vertex Shaders [:D])
VBBR	So here am I again. Development of the runtime module is going very, very well. Development of the editor is completely ZERO. At the present time I'm defining the game information and maps in INI and TXT files. But it is starting to grow larger and larger and I feel it's the time to create the editor and a binary file format. I have no problem with the format, but I do with the editor. I'm just too stupid at designing GUIs. Like: - One program for everything or one for each module like models/maps/general/etc? - MDI or SDI? - Menus? Toolbars? Plain buttons? So if one of you could help I would gladly appreciate. Here is the information I have to create/store: - Game info (name, author, description) - Models info (name, file name and format) - Textures info (name and file name) - Areas info (see below) - Maos info (see below) Let me explain the Areas and Maps stuff. All of the game 'maps' are subdivided into several 'areas', which means, when we go from one area to another, it loads specific models and textures that are used in that particular area (thus minimizing the 'map' loading time). So each area must store this information: - Models that are used in that area (model ID, texture, rotation, solid-yes/no) - Textures that are used in that area (just the ID referencing to the main textures database) - Skyboxes list (each skybox has the following attributes: Texture and auto-rotation for the 3 axes) - Maps list (just the ID referencing to the map file) Each area is stored in a file like area0001.dat. So do maps (map0001.dat). The models database is stored in a models.dat file and the textures database in a textures.dat file. General game info is stored in the game.dat file. Thanks in advance for any help at all. (and for your patience in reading all this!)
Almar Joling	quote: Originally posted by Eric Coleman using other people's graphic's engine's are probably the ONLY way to create a real 3D game in VB. It's not that VB can't do it, but there is just so much work involved to create the engine and the game, it's best to just use an already made engine and then start work on the game. There is also the "Truevision" engine, but it's really just a directx wrapper, not a graphics engine. And there is also Genesis 3D, which seems like a really nice 3D engine. The screenshots look pretty cool. Truevision has quite envolved a bit though, I think it's a bit more than just a wrapper these days :)
Scorpion_Blood	i c that truevision is by some nice "made in vb" 3d games! look here what a found >> http://www.theforce.net/games/apps/boyavin/index.shtml awsome game using truevision and made in VB also :)
Sion	quote: Originally posted by VBBR I'm just too stupid at designing GUIs. Like: - One program for everything or one for each module like models/maps/general/etc? - MDI or SDI? - Menus? Toolbars? Plain buttons? Well, I guess there's not a single correct answer to that question. It very much depends on your game (...maker), and how you want to structure it. Is it only ment to be used by programmers and/or contest developers or should lesser individual be able to use it as well? In any case, I think you should go with the a mix of MDI and SDI. An editor like Starcraft's Campaign Editor is a very good example. It's clean, user friendly and easy to find your way around in. It uses an MDI form for the map editing and basicly SDI for everything else. Something to note (which almost all modern editors have in common) is the use of side bars and menu bars to provides more user friendly and efficiant access to some of the most used functions. The menus also contain the functions of the bars, but are used mainly for more advanced options. The sidebar should hold many different types of items depending on what your maps etc. has to have of infomation. Each type should have it's own page on the sidebar. When editing any infomation or when given any changable options a SDI interface should be used. This is also very common. Think of the Trigger-page of the Starcraft editor for instance. It makes it possible to create cleaner and more specialized forms. These forms should have plain buttons of couse :) On the MDI form a right-click function is an absolute must. This also provides more rappid access to key functions. All in all, take a look at some on the editors on the marked - they will provide you with a good idea of how to design your editor. After all, they where created by industry professional who get paid to make editors etc. as best and useful as they can possible be. Whether you should make a single program to handle all your game contest or make multiple programs depends very much on your target group and the similairty of the data. If everybody should be able to use your app. then yes, everything should be collected in a single program. This is done in the Neverwinter Nights editor "Auora" for instance. But be careful not to combine things that have nothing in common. In the NWN editor everything you could change were somehow connected in menus, options etc.. For instance, if you wanted to change to appearance of your character you entered the charaters profile via the charaters right-click menu from the map-view. But it you wanted to make a new charater figure from stratch you had to open up 3D Studio Max or a different 3D mesh program. Remember to restrict the number of things you'll include in your editor and don't give the user 100% complete control over everything (not at first at least) or you will suffocate in skyrockting coding complexity. Wow, so much written and still so little said... hope some of it gave you a few design ideas. Good luck on the editor! :)
VBBR	Thanks a lot, this really lightened a lamp inside my head. I'm starting to design the editor in my mind right now... Just one thing more: for the Map Editor... should I make it: - 3D, with a view like the in-game (mouse picking of course) - 2D, like a top-down view of the map using "dummy" tiles, like an ugly icon for each object [:)] Please consider here the ease of use AND the ease of programming [:D]
Sr. Guapo	Both. You could have the actual editor as a 2D top-down thing, then have a way to view the level in 3D. This can either be a seperate window (like 3D modeler), or a "Render" button the user can press.That would combine the ease of programming, with the abilty to render 3D graphics.
sdw	Make whichever you think would be easier. That way there's a better chance you'll get it done.
VBBR	I think I will go with Sr. Guapo's suggestion. It fits perfectly because I already have a split-screen design for the program in my head. (and just render, rotate and zoom the map sounds very easy to do)
VBBR	Now here's some news! Following is an screenshot of the current state of the editor. As you can see a texture sample is shown at the right by automatically applying the selected texture to a cube and a sphere so you can immediately see the result. The size labels aren't working as of yet [img]http://revolution3d.de/screenshots/albums/album52/editor1.jpg[/img] I've also created two nifty functions for Putting and Getting variable-sized strings to/from binary files. (the functions will Put/Get the string at/from the current position on the file) [code]Public Sub PutString(FileNumber As Integer, sString As String) Put #FileNumber, , Len(sString) - 1 Put #FileNumber, , sString End Sub Public Function GetString(FileNumber As Integer) As String Dim size As Integer Get #FileNumber, , size Dim tmp() As Byte ReDim tmp(size) Dim dummy As Integer Get #FileNumber, , dummy Get #FileNumber, , tmp GetString = StrConv(tmp, vbUnicode) End Function[/code] The dummy variable is there to hold some stupid 2 bytes that VB puts in the file along with a string. Do not ask me the purpose of the -1 in the Put function because I just don't know. I only know that it works this way. [8D]
Sion	The editor looks real nice! Well, although it's not possible to see that much of the editor - but it's nice to be able to see how the texture will look as material on geometri. I realize that the editor is in an early state, but it would probably become convient with a minimize and maximize button :) The binary read/write rutines look very handy (and extremely simple), but it seems that it requires the files to be open in order to use Get and Put...? Where have you read about this technique, because Get and Put are undocumented? I haven't heard about them before.
VBBR	Well, I just created these two functions from scratch. Dunno about the docs, because I simply don't have them (I learned VB mainly from a book, the web and the Object Browser). For the functions: They both assume you have a binary file opened with read(for Get) and/or write(Put) enabled. Something like: Open "c:\test.dat" For Binary Access Read Write Lock Read Write As #1 then you pass "1" as the argument for filenumber. just close the file later on with Close #1. About the editor, I just posted a picture of the texture panel, because it's the only currently at least half-coded and I would like to show the progress as soon as possible [:)] About the min/max buttons, I don't know if this would be a good idea because you need to resize everything, then re-initialize the display device, blah blah blah... I guess I may do this later. Hum, maybe just a minimize button won't hurt... [:D] Anyway, as soon as it's ready I will probably post a pre-alpha version (or something) here so you all can see.
Sion	With the DaBooda Turbo engine it is possible to change the size of the window where the game is initilized in without re-initializing it. Try looking at the code to see how he has achieved that. PS. Don't know if it's a very good idea to have files opend for longer periods at a time. In any case, be sure to use the command "FreeFile" to get an unused filenumber.
VBBR	I know, and I don't keep the files opened. I only open/read/write/close them when you change the current active tab. This also makes it easier in the way that you can't have to click "save" all the time (and it's not lost if the power gets cut off). Oh, and I do use FreeFile. I do can resize the window without re-creating the display device, but this makes the display all blurry. I will take a look at DBT, thanks.
Lachlan87	Can't you just reset the device? Presumably you already do that when the edior loses focus, so why not when you resize as well?
VBBR	I don't do anything when the editor loses focus, it seems to work just fine. And I can't reset the device because I'm not using DirectX directly (see, the thing is that I'm in fact using DX9 from VB6; the engine I use provides access to the internal DX objects, including the device, but as I'm using it on VB6 I don't have the possibility to access it. And as far as I know the engine doesn't have a reset device function. It does have a resize procedure, however this just stretches the display) Oh yeah, I'm also planning on adding auto and manual rotate to the sample geometry, what do you think?
cjb0087	"An Error occured while trying to set up the game"
VBBR	Oh now that's hard to detect where the error occured. - Did you install the R3D files? - Do you have DirectX9 installed? - What is your vidoe card configuration? - What is your PC configuration? - What is your OS? - Any information you feel relevant... Did anyone manage to run the game at all?
Sion	I had no problems running the game. I even managed to find my way out of the maze :) But it seems that the engine's clipping/culling/occlusion tests are not very good. When looking at the maze from outside the engine rendered ~48000 vertexes when only very few were needed. The walls of the maze blocked the view of all the walls inside the maze, but they still seemed to be rendered.
VBBR	Yeah I'm aware of all that. The mechanism I used for this "sample" (as it can't be called a game) is very innefficient because it renders even walls that are never visible (like every tile is made of a column mesh; but in a junction of two columns there are two quads that are in the middle and are never rendered). Also there is a quad covering the top of every column (wall). I made this back when the view was top-down and left over as it would only give more work :) But in the real thing the maps will be more efficient. Actually I do have a model that is just one side of a wall and one that is an outer corner, but try constructing something like this in notepad? In the time this was created all my files were just a map.txt file with X's and .'s. I COULD define different letters for the different walls but that would be a real pain; and a wrost pain to create the map with a lot of different symbols. (of course in the final version the editor will be ready and we'll be able to create maps seemlessy) And from whhat I reckon this engine only uses frustrum culling. I will look further on this, maybe make a suggestion. Tahnks for the comments. P.S. In fact it's easy to get out of the maze; just keep going in the same direction and eventually you will do it. The way I made the map it doesn't have any dead ends. P.S no.2: Did you try creating a map? You can create any size up to 100x100 (and this is a lot, the default map is 50x50)
VBBR	Did anyone here play Broken Sword: The Sleeping Dragon? Because I just completed it yesterday and it gave me a completely different view of 3D adventure games. The system was very well-designed, I believe it works as follows: - The visual map structure is made of arbitrary geometry; i.e. you don't create it from tiles, you just make it all in a 3D editor or whatever; - The Map data (floors, walls, floor heights, slopes etc.) is separated into tiles in a normal 2D grid. - Wall collisions are checked in arbitrary angles (with sliding); I believe this is easily done with plane-sphere or rotated-bounding-boxes collision checking. Well, this basically screws up all the basis of my system :) But I think it's worth changing fot the better, right? Do you think the above approach is a good one?
Eric Coleman	If you start to add more features that make this too complicated, then you probably will not finish the program. Keep it simple [:)]
VBBR	You are definetly right. The small detail is that the system I just described is (I think) a lot simpler than the current. Creating maps in your favorite 3D modelling program is got to be more fun than trying to adjust tiles within a clumsy editor. Just defining where there is a wall is more simple too. Also this is not an "add features" case. It is a "remodel the system" one. [:D] I was already thinking that the original approach wasn't going to succeed in some ways. See, I think I'm going to toss the line collision-checking for now. For my current needs bounding boxes look just fine. And I do have sliding for them.
VBBR	OK. I've come up with an interesting idea. Since the engine will be script-driven, I thought of, instead of creating a complex binary file format, define all the game settings also using scripts (kinda like what NSIS does). Here is an example. Let me say I used to use INI files to store the game data. So the game header (main game file) could be something like this: [Game] Name=Test Game StartMap=1 StartX=2 StartY=6 StartRot=1 Now, using the new system, it would like something like that... Game.SetName("Test Game") Game.SetStart(1,2,6,1) Or even without the "Game" keyword. See? It seems a lot simpler and more dynamic. One of the main advantages of this method is that is saves me a lot of coding and trouble since WSH and Python/VBS/JS(that's another idea, to allow any of these 3 languages to be used according to the user preference) do all the hard work of parsing the file; I just need to create a class and expose its methods. What do you think of this method? And also about the "use the language of your choice" approach?
Sion	quote: Originally posted by VBBR (...) instead of creating a complex binary file format (...) Creating a binary file format dosn't have to be more complex than using regular INI-files. It can actually be even easier. Using the technique used in the following example it is possible to access binary files much like the way you acces INI-files with the exception that the binary files can hold any type of data. Link: http://www.Planet-Source-Code.com/vb/scripts/ShowCode.asp?txtCodeId=52388&lngWId=1 Paul Berlin has made a binary file read/write wrapper for use with his PGE engine. This also works much the same way INI-files does. Link: http://pab.dyndns.org/viewprogram.html?id=7 ... It just occured to me that you're using VB .NET, so the above examples may not be of great value to you. But dosn't VB .NET include some very extensive INI and XML handling functions and libraries? I know that this isn't the subject of your post, I just thought I would give some input on the binary file thingy for all that it matters...
VBBR	Well, thanks for that, but from where did you get the information that I'm using VB.NET? Actually I'm using VB6! BTW, I just looked at this code from PSC, it's simply awesome!
VBBR	Well, since almost no one exposed any opinion about the system I described, I will stick to it. [:D] What I want to know now is, what do you think of a multiple-languages scripting system? Like, you design your game and use for scripting the language of your preference, from the options below: - Python - VBScript - JScript (not sure if this will work because I don't know JScript so I haven't tested it) And besides that, would one language for the entire game be enough, or would the option for you to choose a different language for each script be an interesting feature? P.S. I'm asking this because it seems an interesting thing to me, although that's the thing that made me chase a bug for over 3 weeks. It seems each time you change the language in MS Scripting control you have to re-expose everything. Of course this seems the most obvious thing in the world now that I have discovered the problem. Oh, I'm currently creating a console too. The input part is up and running, you can put in a command and the program executes it. Gotta make some text appear in the console history now...
Brykovian	I would expect that a single language would be fine. And if that's a "known" language, then even better. Most task-specific systems usually only provide their own built-in scripting language. If you're able to speed up learning by having your scripting language be something like VB or java, then you're that much ahead. I think multi-language script support should be a lower priority than getting a working version out and available for people to try out with just a single language supported. -Bryk
VBBR	Just to give some info... - The console part is almost complete. (still some bugs though) - The scripting interface is more or less setup, all I need to do now is add some functions to it. [:D] You can use VBScript, JScript and/or Python wherever you like (altough it takes a little time to change the language due to having to re-create the whole interface). You can also use whatever language you want in the console, but I personally prefer VBScript due to it not being case-sensitive. - I also should work on the map system, mainly in the slopes, multi-height floors and collisions with them; basically, I need to make it so the player stops passing through solid things. [:D] - After all this I should stop, look at everything I've done and decide what path to take. I already made a huge change in plans in the middle of the programming (because I just can't plan things before actually programming), and this leaved a lot of useless code as well as a big mess where some parts of the code use the new system, while others still use the old. Just after I changed plans (and before I stopeed to look at it), I stopped working on it for 2 weeks, meaning that when I came back I didn't understand anything. So it all needs a huge cleanup now. Also I have to say that you won't see too much progress in the next week or two because I have a more important project to work on (it's always like this, isn't it?), but then development should continue at full power.
Sion	Wow, that sounds like a powerfull scripting interface, if it allows the user to take advantage of whichever of the three scripting languages he would like! Dosn't Python require some external files or libraries to work? When I get around to making the editor for my game, I think of using a fail-safe scripting language to prevent users from poping up a messagebox, deleting files or anything of that nature. "Lua" is such a language, but unfortunetly that's a C++ embeded language, so I'll have to use something else. Prehabs something of my own creation? In that case I guess the idea of "fail-safe scripting" is completely impossible [:P] But I would very much like to take a look at your scripting interface, when I'm done with the engine and game itself and moving on the editor. That isn't going to happen any time soon, however. Some very interesting things seem to be happening on VBBR's computer, I'm looking forward to seeing what all his hard work will lead to [:)]
VBBR	I use Python through WSH and something called the Python win32 extensions. Thanks to GameDev.net I found out how to discover the file dependencies (I used a program called depends.exe, look for it on google or see the topic called "Python Redistributables...?" in the GDNet Scripting forum). Actually the scripting interface is very simple... All you have to do is set the language property in the WSH control and re-expose all the classes you want to be accessed. There's a tutorial at [url="http://www.rookscape.com/vbgaming/"]Lucky's[/url] that explains very well how to use the control, you should take a look at it (if you haven't done so already). Also I researched something about Lua in VB and found out that it is possible, although I didn't see anyone that did it. I tried, but it seemed too much work.
VBBR	Also I would like to ask a question here... The engine I use (Revolution3D) will soon support BSP maps. What I want to know is, what is better, to model the environment in a normal 3D modeler and define the events in a custom editor, or to create everything in a BSP editor using entities as the action definers?
Sion	Ohhh yeah! I checked out the tutorial (I had actually seen it, and even glanced it over, but didn't think it brought anything new to the table), and it's great!! I have a little experince with using MicroSofts scripting classes, but I've never noticed those tiny small functions that enable exactly what I've been searching for! quote: Originally posted by Sion When I get around to making the editor for my game, I think of using a fail-safe scripting language to prevent users from poping up a messagebox, deleting files or anything of that nature. And a qoute for the tutorial ([url]http://www.rookscape.com/vbgaming/tutBQ.php[/url]): AllowUI - If set to True, allows the scripter access to the user interface based functions, such as "MsgBox". Needless to say, this should be disabled in a full-screen direct3d/directdraw based application, unless you're a sadist. UseSafeSubset - Turn to "True" to make the script less capable. Stops nasty hackers from coding a worm or something equally as nasty in your in-game scripting language! Actually, a competent coder could probably still do it, so be careful. If you let the world execute scripts in your program, you are taking a risk. Timeout - Here is a good way to in some small way make vicious script problems less vicious. This gives a script a time limit (in milliseconds) for it's execution, before being cancelled forcefully by your program. Fantastic, now I know how I will do my scripting! Thanks for the heads up VBBR! Only downside is that it isn't very effiant, but if the scripts are executed carefully that shouldn't be a problem... I hope.
VBBR	I have to say some things... First, sorry for the delay (that more-important-than-this project is taking all my time and is taking longer than I thought). Still, happily I had a chance to work on The VB Adventure Maker a little yesterday and I think I will be able to work a little during this weekend. I just started to remove the old code and guess what, everything stopped working. I'll have to re-write the entire map system to use BSP files (I think it will come out easier in the end), but the .92 version of Revolution3D (which will support BSP maps) hasn't come out yet. So the map is going to wait a little. sigh... The console also simply disappeared, leaving just the commands history panel (but I just discovered that that's because I had the "Activated" property set to false). That's also something that I need to look into, since the history panel was still there when the console was de-activated. After making what I can to see things working again, I will (finally) start designing an IDE. I think after all this time and changes in plans I already have everything clear in my mind as to what will be inside each game, how things will interact with each other, etc. Still I won't be able to do a lot of progress until BSP support arrives.