Sure, no problem.
You're coding your latest RPG and you have a little mystic shop that people can come into. Perhaps they can buy certain things; other things can only be looked at.
One of those things is a Magic Eight Ball -- the kind that you shake to get an answer -- only, it has special powers and features that are relevant to the story and the information at hand at a certain point in the game. Somewhere in your story, you work it in so that you can 'remember' questions, and that you have to go to these mystic shops and pay a small fortune to use a Magic Eight Ball to tell you the answer. It is to be displayed with it's own bitmap background, without your character on screen, and it will have to generate a special message based on the question you ask it.
Should the code to control this be in the same location as that killer camera control code you've written? No, probably not.
In fact, I've inadvertantly added TWO problems..."how do we store the questions?" and "how do we control the eight ball?" Silly ChipOne.
Okay, here's what I'd do:
1) We need a seperate file for the questions, and again a seperate file for the eight ball.
2) Each file will have a UDT to describe the object (entity, type, whatever you'd like to refer to it as. I'll call it an object)
3) Each file will have a list of functions that are ONLY relevant to the UDT.
4) Our main file in the project will have to have a globally defined instance of the UDT (GLOBAL Questions(10) AS Question, for example).
The UDT's might look something like this for the questions:
TYPE Response
Answer1 AS STRING
Answer2 AS STRING
Answer3 AS STRING
ENDTYPE
TYPE Question
Sentence AS STRING
TimeAsked AS INTEGER
Answer AS Response
ENDTYPE
That would give us three possible responses to each question. You can populate those answers when the person 'finds' the question by reading them in from DATA statements.
That said, we can move onto the eight ball.
TYPE Eightball
QuestionNumber AS INTEGER
Message AS STRING
BackgroundColour AS DWORD
ForegroundColour AS DWORD
ENDTYPE
This will allow us to use differnt colours for different eight balls and store the index of the question in the question array so we can have direct access to that information as well. You could expand that and put whatever information you like in there.
Now, we'd set up functions like:
InitEightBall(QuestionNumber)
DisplayEightBall()
ShakeEightBall()
RevealAnswer()
Note: I indented ShakeEightBall() and RevealAnswer() to illustrate that they should ONLY be called from DisplayEightBall(). This technique is used to emulate scope, a feature in most languages which allows you define which functions are allowed to talk to (or even be seen by) other functions.
Now, where this gets interesting is when you look at the possibility of having
different eight balls in different shops or in other locations. Do you want them to all be the same, or will they have unique characteristics? Will they remember things? Know their location? You can put whatever data in the UDT that you like, and then make another array of the UDT for the eight balls (like we did for the questions/answers):
GLOBAL EightBalls(5) as Eightball
Now we have five eight balls that can be used in different scenarios. But, this is where it really gets exciting: we can use the same functions to do anything we like to ANY of the eight balls! That's right, all we'd have to do is change our function definitions to include an index into the eight ball array, and we can then perform all of our operations based on that number:
InitEightBall(EightBallNumber, QuestionNumber)
DisplayEightBall(EightBallNumber)
ShakeEightBall(EightBallNumber)
RevealAnswer(EightBallNumber)
This is just a short primer, but it illustrates some of the use of UDTs without getting into any of the advanced uses. Do your reading in the manuals and re-read this article and hopefully things will start to fall into place. If you have anymore questions, let me know!
Cheers,
ChipOne
-= i only do what my rice krispies tell me to do =-
