syntax error :(

[Clayton]

could anyone plz tell me why this code :

code:

class Character     import Rand     export startStats, levelUp, battleStats     type Stats :         record             item : array 1 .. 4 of string %%%             weapon : string := "Sword"%%%%%happens here %%%             equipment : array 1 .. 3 of string : init ("", "", "")             str, defense, skill, spd, luck, resistance, hp, experience : int             attack_, hit_, avoid_, critical_ : int         end record

creates the error "syntax error at := expected end"?

[Delos]

SuperFreak82 wrote:

could anyone plz tell me why this code :

code:

class Character     import Rand     export startStats, levelUp, battleStats     type Stats :         record             item : array 1 .. 4 of string %%%             weapon : string := "Sword"%%%%%happens here %%%             equipment : array 1 .. 3 of string : init ("", "", "")             str, defense, skill, spd, luck, resistance, hp, experience : int             attack_, hit_, avoid_, critical_ : int         end record

creates the error "syntax error at := expected end"?

I don't believe it is possible to instantiate elements of a record whilst declaring them. That is, you cannot give them a 'default' value, not directly at least.
Keep in mind that a record is a type not a variable, hence it couldn't be initialized in the first place.

[TheOneTrueGod]

What delos said is correct, and either way you shouldn't be initializing the variables that way. (Only constants)

What you should do (In most cases, I don't know what your case is...) is have a "Create" or "Initialize" procedure (I sometimes have both, one to be called from within children of that class, and one to be called from outside the class)

code:

class Character    export Create     var stats :         record             item : array 1 .. 4 of string             weapon : string := "Sword"             equipment : array 1 .. 3 of string : init ("", "", "")             str, defense, skill, spd, luck, resistance, hp, experience : int             attack_, hit_, avoid_, critical_ : int         end record    deferred procedure Create %So you can recreate it in children if the need be.    body procedure Create(weapon_ : string,str_/*... you get the point*/)        stats.weapon := weapon_        stats.str := str_        %etc...    end Create     end Character

Some minor quirks that i've found while i've been programming is:

#1) For RPGs, its probably better to keep all of your "stats" in one array, such as

code:

var stats : array 0..7 of real

This makes it MUCH easier to output to the screen, when the need be. As long as you keep it constant (eg. 0 = level, 1 = exp, 2 = str, 3 = agi, etc...) it should be easy to manage, and you can also have it in a record, with another array that keeps track of the "name" of each stat, eg

code:

var stats : array 0..7 of record    level : int    name : string end record

#2) The more tight you keep things the better. Your "Character" class here is extremely specific. Why not make it much more general, and then have children of it that keep track of PCs, and NPCs. That way, since they both do the same thing anyways, its MUCH easier to manage in less lines.

#3) Items / equipment should be a class unto itself, not a string.


Note: I make no claims to be an expert in classes. These are just things that I've found made my life easier when I was programming my RPGs, or things that i've been called on when submitting source code. Good luck

[Cervantes]

TheOneTrueGod wrote:

#1) For RPGs, its probably better to keep all of your "stats" in one array, such as

code:

var stats : array 0..7 of real

If you want to keep stats in an array, fine. However, it means you and whoever is reading your code has to memorize the keys: 0 is for level, 1 is for experience... Wouldn't it be better if we had some better way of referencing this? Wouldn't it be great if we could do something like

code:

stats["experience"] += 1000

Yes, that would be nice. That type of data structure is called a hash. It's like an array, except its elements (values) are referenced by a particular key (string, in this case), rather than an index integer.

Sadly, Turing does not have hashes. However, the next best thing are enumerated types. You can use this in conjunction with your stats array to do something like

code:

stats (stat_type.experience) += 100 % where stat_type is an enumerate type

I forget the exact syntax for creating an enumerated type. Check out enum in the Turing Help file.

TheOneTrueGod wrote:

#2) The more tight you keep things the better. Your "Character" class here is extremely specific. Why not make it much more general, and then have children of it that keep track of PCs, and NPCs. That way, since they both do the same thing anyways, its MUCH easier to manage in less lines.

Indeed. Inheritence is a powerful concept, especially when applied to something so highly structured as an RPG.

TheOneTrueGod wrote:

#3) Items / equipment should be a class unto itself, not a string.

Once again, "indeed". If you're going to use OOP for this, you might as well go all the way. You can even use inheritence for items.

For example:

code:

Item     Weapon         Melee             Sword             Mace             Axe         Ranged             Thrown                 Throwing Axes                 Darts             Ammo                 Bows                 Crossbows     Armour         Body Armour             Leather Armour             Studded Leather Armour             ...         Helmet             ...         Boots             ...         ...     Rings     Gems     Scrolls     ...

[wtd]

Cervantes, much of your hierarchy could be better organized in terms of both implementation and interface inheritance.

Consider a ThrowingAxe. It should be both an Axe and a ThrowableItem, but you can't inherit from both. So... you make ThrowAble an interface that ThrowingAxe implements.

[Cervantes]

I thought about it, but decided against it because Turing only supports single-inheritance and doesn't provide any sort of mixins. However, you raise a good point. Turing does provide some sort of implement mechanism, though I've never put it to use myself.