Text-Based RPG: Survival

[wall_fall_down]

Thanks, that was in my book, I should have seen it.

[WoF]

Two more considerations concerning Cominterns statements:

Function pointers might make life easier in some cases, but I think they can be avoided by consequent usage of objects and their methods.

But the look for a true class framework is an argument.
I think VB6 does not allow to inherit, but you can include base classes in more complex class definitions, so that's kind of an inheritance - yes, in a way. Don't nail me down on that.

What I liked at VB6 is the "simplicity" - well compared to VB.NET at least.
If I put a simple TextBox or a Button in VB.NET on a Form and look at the many, many properties - I have no idea about some of them. Same with other objects. It always strikes me down because there is so much more stuff as in VB6.
VB6 is less confusing for a beginner I think, and since you consider yourself a beginner I'm not sure what kind of complexity you will want to achieve. But as a programmer who has tried out many languages I'd always give BASIC to a beginner.
Beginners All Purpose Symbolic Instruction Code, as it were.
My opinion is: you can do (almost ) anything with every language as long as you know the language. And VB IS easy to learn and to understand.

[GremlinSA]

I've begun programming a time-of-day situation in which TimeOfDay is a string. Based on the value of the string, I have a lot of If TimeOfDay = "X" Then... / Else If etc. statements going on. The time of day/night is to be updated in-game every 10 minutes (1 game hour) and dawn/dusk both happen in three closely-timed stages (i.e. dawnEarly, dawn, and dawnLate.)

I've also considered trying to shift what hour of the day dawn and dusk occur, based on seasons. And yeah, I'm laughing at myself as well, because I' mreally making this more complex than it should be. But maybe I'm bored or something.

To sum that up, that's a TON of If-Thens inside more If-Thens. Are there any obvious alternatives that I'm missing here? Anything to make the time schedule seem like less of a mess?

When using variables that will have a set of fixed values it will be easier to use a UDT to build your variables and statements...

Ie..

Public Type Season as Byte
Spring 
Summer
Autum ' Fall
Winter
End type
 
Public type TOD as Byte ' Time of Day
Midnight
EarlyDawn
Dawn
LateDawn
Morning
LateMorning
EarlyAfternoon
' Etc - you get the idea
End type
 
Public GameSeason as Season
Public GameTime as TOD
Public Sunup as TOD
Public Sundown as TOD

then instead of doing if then's with in If thens, rather try to build simple individual functions than can be called independantly ..

Private Sub SeasonChange
Select case GameSeason
	Case Summer
		Sunup = EarlyDawn
		Sundown = LateDusk
	Case Winter
		Sunup = LateDawn
		Sundown = EarlyDusk
	Case Spring, Autum
		Sunup = Dawn
		Sundown = Dusk
End Select
End sub
 
Private Sub CheckDawnDusk
If GameTime = Sunup Then Msg="The Sun climbs slowly over the mountains" 
If GameTime = Sundown Then Msg="The Sun slips slowly behind the mountains" 
End Sub

Breaking everything down to the simplest function will effectivly leave your main program loop with a few checks and calls to the correct functions.

Also when building up your functions, try to work sequentially, IE: work out the functions for Hours first, then Days, then Seasons and Then Years. or rather start with the years firat and work everything in backwards towards the hours.. IE, Years affect the seasons crop size, Seasons affect the foilage and days temperature, the season affects the days sunup and sundown ...

You have a hell of a project ahead of you, but it will be fun, And many of us will be nearby whenever you need a little help with anything...

Gremmy...

[Comintern]

Two more considerations concerning Cominterns statements:

Function pointers might make life easier in some cases, but I think they can be avoided by consequent usage of objects and their methods.

But the look for a true class framework is an argument.
I think VB6 does not allow to inherit, but you can include base classes in more complex class definitions, so that's kind of an inheritance - yes, in a way. Don't nail me down on that.

Good point, and it expands on what I was talking about in terms of "robustness". What inheritance and function pointers let you do is write one bit of code that is generic to all of the objects in the game. Take for example critters and actions. If there are a lot of actions that are common to all of the critters in the game (i.e. "move north"), then you have 2 options to greatly simplify coding. Make a base class with a "move" method that everything that can move inherits from and call the method from your derived object, or make a generic "move" function that you can pass arbitrary objects to. Either of these can be done reasonably in VB (although the require substantially more code and would be harder to later add onto).

Function pointers are more useful in your parsing code. For example, if you have a long list of legitimate actions that the player can take, it's much easier if you build a table of actions the correspond to functions and pass the rest of the string to the appropriate parsing function. This makes adding new functionality a lot simpler. This can also be done in VB, but again you will find that the amount of code and it's ease of extensibility will suffer.

One suggestion that I have is to scan through the code of other open source programs similar to the one you want to write and see how they are implemented. Then you should have a basic idea of how well they would translate to VB and other ways you could accomplish them. You may get half way through and have to re-write the entire thing from the ground up, but it's a great way to learn any language.

That said, I'd lean toward dglienna's suggestion and take a stab at it in .NET, especially if you're comfortable with VB. No sense learning on unsupported technology.

[WoF]

Erm... Gremmy?

Public Type Season as Byte
Spring 
Summer
Autum ' Fall
Winter
End type

Which language are you thinking in at the moment? This is not how UDT works in VB.
I think you want Public ENUM here.
And Enum does not take an AS BYTE spec.
I think you wanted:

Public Enum Season
  Spring
  Summer
  Autumn
  Winter
End Enum

Public TOY as Season

or something like that.

To quote ComIntern:

You may get half way through and have to re-write the entire thing from the ground up, but it's a great way to learn any language.

True and true.
In case of a more complex program you have to do some real planning before coding or you end up rewriting everything more'n one times.

VBs class system is very much suitable for exting things later when more ideas come up if you use it consequently. Like Comintern was saying: if creatures have the same subset of properties like the player, then you'd define a class for that subset and let player and creatures inherit (or simply inplement) it.

Even if the saying goes VB6 is "not supported" by Microsoft anymore, full docs are still available in MSDN, and there's soooo much support here at CodeGuru, isn't it?

[GremlinSA]

Erm... Gremmy?

Public Type Season as Byte
Spring 
Summer
Autum ' Fall
Winter
End type

Which language are you thinking in at the moment? This is not how UDT works in VB.
I think you want Public ENUM here.
And Enum does not take an AS BYTE spec.
I think you wanted:

Public Enum Season
Spring
Summer
Autumn
Winter
End Enum
 
Public TOY as Season

or something like that.

O M G .. thanks Wof... You are so right... I was not thinking straight... That'll teach me to try a Serious code post at 11 PM, after a long day at work, with out checking it in a IDE first.....

Enum is what I was intending...

Gremmy...

[wall_fall_down]

Thanks everyone for having so much input... Rewriting the time systems now using the Enum and case instead... Makes it look much more tidy, doesn't it?

You guys have given me a lot to look up, and I appreciate it. I have looked for opensource games, but VB6 doesn't sound too popular.

And I made an extra fifty bucks for skinning two larger does, so I'm intending on going (20 miles!) to Barnes & Noble to try and find something about VB.NET. A supported language sounds appealing to me, and if I'm familiar with VB6 I assume the .NET won't be too traumatic of a change..?

As for actually timing the stuff out... I want it to be triggered by minutes of gameplay as I said, but my book leads me to believe I cannot.

The timer would be enabled to run when the player loads a game. I would like to call it perhaps every 20 minutes and advance it by X amount based on travel. However, before I get into trying to think up anything for the grid-location-specific travel advancement, I have to know if 20 minutes is possible.

I have considered the option of not using a timer event procedure, since my book tells me that these event procedures are limited to intervals of 65,535ms. So answer me this:

If I were to store the time in a variable, and then perhaps create a method of checking when

time = time + 20min

and then just use a case statement/other to make sure that morning follows daybreak, and noon follows morning... Would that work?

I would like to set up different times for dawn and dusk for each month as well, but I figure once I happen upon the smoothest trail I can easily duplicate & modify the same code, with a ticker to count months. The book I own teaches me a bit about making counters that use set values, so that every 12 months a year will pass and etc. so that's handled.

But my question here would be "is there some way of using the time = time + 20 script in junction with a statement that gives a different message for different times of day?

Thanks for being easy on the new guy, too. Last forum I went to treated me like crap because I was as green as the day I got cut.

[dglienna]

Use DateDiff() to compute actual differences, in seconds, minutes, days, years, whatever.

Usually with a timer, I set it to 500 milliseconds (1/2 sec) and then keep track of clicks of the timer. The actual limit doesn't matter, as you keep track of clicks.