Upcoming Events
Unite 2010
11/10 - 11/12 @ Montréal, Canada

GDC China
12/5 - 12/7 @ Shanghai, China

Asia Game Show 2010
12/24 - 12/27  

GDC 2011
2/28 - 3/4 @ San Francisco, CA

More events...
Quick Stats
96 people currently visiting GDNet.
2406 articles in the reference section.

Help us fight cancer!
Join SETI Team GDNet!
Link to us Events 4 Gamers
Intel sponsors gamedev.net search:

  Contents

 First Requirement
 If Statements
 Loops
 More Theory

 Printable version

 


  The Series

 Storing/Reading
 Doing Something
 Control Structures

 

More theory time!

Now, after giving you all that ugly source code to figure out how to implement more efficiently, I will move on to some theory, and let you decide how you want to code it; I won't provide any code in the article for this little discussion.

Now, you're probably curious as to why I have used only bit flags for data-storage in the scripts so far. With a bit of thought, however, the question arises "How can we name a variable, and refer to it as a string?" In other words, how can a script define a variable by itself, and then have vb refer to that variable using a STRING, because the actual VB code can never actually contain the name of that variable, because it was written in the script, not the vb code! A C/C++ coder would immediately jump to something like a linked list, but we can't do this in VB... Or can we? VB can't do it in the usual manner of C/C++, using a struct, the C equivalent of a user-defined type in Visual Basic.

Once again, the magic that is VB's poorly designed, poorly implemented OOP system comes to our rescue. Using a system of classes, we can design a linked list fairly easily. You would have one class, called something like 'CLinkedListItem', and it would have a member variable called, for example, 'm_Next', defined as a CLinkedListItem object. In this way, you can set the m_Next variable to be a 'pointer' to the next item in the list! Then, another variable could be created called 'm_Name' which would contain the name of the variable in the context of the script. A member variable named 'm_Data' would be needed to hold the 'data' of the script variable.

With this type of setup, it would be quite simple to then read up on binary trees, or hashing algorithms, and implemente one of these methods to allow for efficiency in searching for the correct element of the linked list. An exellent resource for this type of thing is at http://members.xoom.com/thomasn/s_man.htm. He implements the algorithms in both C and VB, so you should be able to do something with it!

Using named variables will come in very handy with your scripting language, making it much easier to keep track of what variable contains what data :) With the numbered bits/flags system, you would need to keep some sort of record of what bit/flag represented what.

Suggestions...

As in the previous article, I will leave you with some suggestions for things to do to improve the scripting system for your own personal needs.

I mentioned in the introduction that the implentation of all the loops etc. was not very well done (ie: efficient). They were also somewhat restrictive, and could become quite complicated due to the need for making command blocks 'become' part of a larger one, because the small ones would be part of conditional statements and loops, whereas the logical thing in everyone's mind is that of VB, having the actual statements 'inside' beginning and ending statements for the control structure, whether it be a For loop, of and If...Then...Else statement.

I believe that if you wanted to set this up better, which I really think you should, you could change the layout of the actual script loading script, and the data structures that store the command blocks etc. I am sure that lights are starting to flash on in your head by now, so I will leave this discussion at that, and allow it to progress to your own personal taste.

Conclusion

Well, I finally got this third part done. It was a push, as you can probably tell. I hope it has gone into enough depth while retaining enough generality to allow you to take everything to your own personal liking. You should, by now, have a pretty good understanding of how the basic system works, including how to create your own scripting commands. I would really like to make one thing clear, though. When I wrote all of this code, not only for this part of the series, but for all of them, I did not truly mean for the code to be copied and pasted, and actually used. I mainly intended it, and still do intend it, to be used more as an explanatory tool, and to demonstrate one way of doing things (which, imho, is a very ugly way of actually implementing the scripting system). Therefore, none of the code that has been written for this article is set in stone, and neither is the entire structure of the scripting system. Please feel very free to change things: how the scripts are stored in memory during run-time, add extra 'built-in' commands that aren't run like the normal ones with ExecuteCmdBlah. There are a million possible, and very viable, solutions to all the problems with this system, and I am sure that you can come up with at least one way to fix any problem that you run into!

So, basically what I am saying is, BE INVENTIVE AND CREATIVE. Do what suits YOU, not what you think I would have done. That's how you become a better programmer! :)

Source Code

The source code to this third part in the series is, as always, available from my website. A change from previous parts, though, is that there is more to it than a single class module. I have included a sample project, as well as a somewhat confusing demonstration script. This is what I used to test all the code, so it's not exactly well commented in itself. But, by stepping through it, and watching what happens, you'll pick it up in no time!

The address of the ZIP file containing the source code is:

[ http://blackhole.thenexus.bc.ca/downloads/gamescriptvb-pt3.zip ]

Contact + Future Releases

As before, updated versions of this third part of the series, as well as later parts as they are written, will be available from my website, the black hole:

[ http://blackhole.thenexus.bc.ca/ ]

I welcome any questions or comments, as well as *constructive* criticism :) I can be reached via email at:

[ dgoodlad@junction.net ]

Thanks for reading!

David Goodlad