|
Note: You must be registered in order to post a reply.
|
| VBBR |
Posted - Jun 30 2004 : 3:04:23 PM
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 |
Posted - Oct 03 2004 : 4:49:25 PM
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. |
| Almar |
Posted - Oct 03 2004 : 3:58:32 PM
Maybe you can convert an OGL BSP loader tutorial, like on www.gametutorials.com |
| VBBR |
Posted - Oct 03 2004 : 07:18:48 AM
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.  |
| VBBR |
Posted - Sep 18 2004 : 07:12:25 AM
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. |
| Sion |
Posted - Aug 26 2004 : 4:25:40 PM
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 (http://www.rookscape.com/vbgaming/tutBQ.php):
- 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 |
Posted - Aug 26 2004 : 3:01:33 PM
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? |
| VBBR |
Posted - Aug 26 2004 : 2:16:55 PM
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 Lucky's 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. |
| Sion |
Posted - Aug 26 2004 : 2:00:14 PM
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 
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 |
Posted - Aug 25 2004 : 2:07:04 PM
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.  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.
- 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. |
| Brykovian |
Posted - Aug 17 2004 : 5:11:11 PM
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 |
Posted - Aug 17 2004 : 3:14:25 PM
Well, since almost no one exposed any opinion about the system I described, I will stick to it.
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... |
| VBBR |
Posted - Jul 30 2004 : 6:11:34 PM
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! |
| Sion |
Posted - Jul 30 2004 : 5:46:31 PM
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 |
Posted - Jul 30 2004 : 5:05:23 PM
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? |
| VBBR |
Posted - Jul 18 2004 : 1:20:41 PM
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. 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. |
|
|
| VBGamer |
© |
 |
|
|
|
