a character class for my rpg

Erik Max Francis wrote:
> So what exactly do you think _you're_ trying to do here, chief, if not
> exactly the same thing?

Umm.... I'm waiting for you to list reasons for something that I can
then prove wrong? No, I'm not doing the same thing I'm pointing out
your alleged annoying fanboyness and offering my opinion on such fanboyness.

I'll take your refusal to deny the charges as acceptance of guilt. The
guy wasn't trying to argue whether java is or isn't suitable for game
development, he was asking a C/C++ question. There's a time and a place
for everything.

-Tim

Tim Ford wrote:

> Umm.... I'm waiting for you to list reasons for something that I can
> then prove wrong? No, I'm not doing the same thing I'm pointing out
> your alleged annoying fanboyness and offering my opinion on such fanboyness.

_My_ alleged annoying fanboyness? Do you even know who you're talking
to, at this point?

--
Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
Divorces are made in Heaven.
-- Oscar Wilde

In article <1114710702.737729.173790@o13g2000cwo.googlegroups .com>,
kotori83@hotmail.com says...

> Hi, i'm relatively new to programming. I've worked with Java for
> awhile, but i have really seen its limitations when it comes to game
> programming, so i've started developing on my own. I have done simply
> stuff already so i decided to move on up the ladder of difficulty. I
> am posting a copy of a character class that i have recently written. I
> need it to be flexible enuf to be called relatively frequently in my
> battle engine. Here it is:

> If anyone can give me any insight into any improvements i can make
> towards this code, i'd really appreciate it! Basically what i'm trying
> to do with this is create a new hero at the beginning of the game, and
> during the character creation process allow the user to "roll" for the
> ability scores. But more with random number generators later
> btw

Well, it's a beginning. Arguably the only question is whether you
should have decided in advance whether you need all these things. On
the other hand, you have avoided the temptation of creating a public
member when you do decide some function needs a value for strength.

I have some comments. However, I don't want to push you into sitting
around prettying up your access functions forever. What you have will
do to start with, so feel free to ignore these. (Or you may simply
disagree with some or all of them.) After all, one of the good things
about OO is supposed to be that you can change something without
messing up your whole program!

First, you are returning int values for attack, defence etc. Why?
It's good for some things like rolling and reporting, less so for other
things that use the values. If you return floating point values, you
won't risk making errors like:
int damage = hero.GetAttack() / 1000;
...which will return zero if the hero's attack is less than 1000.

Using ints for everything is a hangover from the days when floating-
point processors were PC add-ons.

Second, I'm not sure I like the hero class being a string. Maybe it
should be an enumerated value, with each possibility being associated
with a class name. Again, less chance for error:
if ( hero.GetClass() == "warior" ) { attacks += 1; }
...why does my warrior not get an extra hit???

Third, are you going to be deriving classes from Hero? If you plan on
deriving classes that will need access to the members, you might
consider using 'protected' instead of 'private'. 'Private' is better
if you plan on deriving classes that won't need such access.

Finally, you should include rec.games.roguelike.development on your
newsgroup list. It's full of people who program exactly this sort of
game.

- Gerry Quinn

In article <882dnRCtBNSaKOzfRVn-tg@speakeasy.net>, max@alcyone.com
says...
> David Haley wrote:
>
> > Personally I would also attach '_' to data members (e.g. int hp_ but that's a
> > question of style preference. Some have the _ before, others have m_hp, others
> > have mi_hp, others have miHp, etc...
>
> The prefixed underscore frequently runs afoul of Standard violations,
> specifically undefined behavior due to using implementation-reserved
> identifiers.

Indeed. m_ is the usual standard, but you may want to define a few
Hungarian-like variations. (I definitely don't recommend going the
whole hog with Hungarian notation, but a few helpful prefixes can be
useful.)

- Gerry Quinn

Tim Ford wrote:

> Peter Ashford wrote:
>
>> ...and by the way - fuck off. How dare you assume that I'm some kind
>> of "fanboy" on the basis of one question? FYI, although I have done
>> some simple games in Java, I work in C++ ATM. Go shove your
>> self-rightous assumptions.
>
>
> As if your working with C++ has anything to do with your java fanboyness.
>
> Are you seriously telling me you weren't waiting for him to list the
> reasons he doesn't like Java for games so that you could attack each
> reason to prove it wrong? Be honest
>
> -Tim

Having programmed in C forever and C++ and Java for merely "a long time"
I can think of many reasons why one might have issues coding games in
Java which are non-issues (mainly using the wrong APIs for the job). I
was wondering whether this were the case here. It's possible I'd have
been able to shed some insight.

I ain't waving no flags. If I were to apply your apparent logic to
posting on Usenet, I'd assume that your rude reply to my first post
marks you as a "C++ fanboy". Though I think that would be childish.

This day of Fri, 29 Apr 2005 11:07:12 +0100, Gerry Quinn
<gerryq@DELETETHISindigo.ie> saw fit to scribe:

>In article <882dnRCtBNSaKOzfRVn-tg@speakeasy.net>, max@alcyone.com
>says...
>> David Haley wrote:
>>
>> > Personally I would also attach '_' to data members (e.g. int hp_ but that's a
>> > question of style preference. Some have the _ before, others have m_hp, others
>> > have mi_hp, others have miHp, etc...
>>
>> The prefixed underscore frequently runs afoul of Standard violations,
>> specifically undefined behavior due to using implementation-reserved
>> identifiers.
>
>Indeed. m_ is the usual standard, but you may want to define a few
>Hungarian-like variations. (I definitely don't recommend going the
>whole hog with Hungarian notation, but a few helpful prefixes can be
>useful.)

Righto. That's why I put it behind. I'm not fond of the m_ notation and
personally even less fond of Hungarian-like variations unless there's really an
ambiguity of type. Maybe it's a question of habit, though; I just find it hard
to read when there's this long prefix in front of the variable name. I guess
that if you work with it long enough you learn to filter it out when you're not
explicitly looking for it.

--
~david-haley
david-usenet@the-haleys.com
(no unmunging necessary)
---------------------------

> This day of Fri, 29 Apr 2005 11:07:12 +0100, Gerry Quinn
> <gerryq@DELETETHISindigo.ie> saw fit to scribe:
> >Indeed. m_ is the usual standard, but you may want to define a few
> >Hungarian-like variations. (I definitely don't recommend going the
> >whole hog with Hungarian notation, but a few helpful prefixes can be
> >useful.)

Hungarian notation is a bad idea. The problem is that when (not if!) types
change, then you now have a large maintenance problem of fixing up all usages,
not just the single definition.

Even worse (and common given schedule crunches) client usages are not changed
at all. Instead developers learn to understand what the type "really" is. Then
you have the worst of all possible worlds: a tedious notation that is not only
confusing, it is in fact wrong.

No information is better than misleading information.

A convention like m_ is at least more stable.

Let type declarations encode the type. The name of an item should indicate
what it is at a conceptual level (something that tends to be much more
stable), and not worry about encoding the type. Rely on your IDE's navigation
abilities to find the declaration quickly if needed.

--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net The Rhythm has my soul.

This day of Fri, 29 Apr 2005 17:16:04 GMT, Ray Blaak
<rAYblaaK@STRIPCAPStelus.net> saw fit to scribe:

>> This day of Fri, 29 Apr 2005 11:07:12 +0100, Gerry Quinn
>> <gerryq@DELETETHISindigo.ie> saw fit to scribe:
>> >Indeed. m_ is the usual standard, but you may want to define a few
>> >Hungarian-like variations. (I definitely don't recommend going the
>> >whole hog with Hungarian notation, but a few helpful prefixes can be
>> >useful.)
>
>Hungarian notation is a bad idea. The problem is that when (not if!) types
>change, then you now have a large maintenance problem of fixing up all usages,
>not just the single definition.
>
>Even worse (and common given schedule crunches) client usages are not changed
>at all. Instead developers learn to understand what the type "really" is. Then
>you have the worst of all possible worlds: a tedious notation that is not only
>confusing, it is in fact wrong.
>
>No information is better than misleading information.
>
>A convention like m_ is at least more stable.
>
>Let type declarations encode the type. The name of an item should indicate
>what it is at a conceptual level (something that tends to be much more
>stable), and not worry about encoding the type. Rely on your IDE's navigation
>abilities to find the declaration quickly if needed.

FWIW, a tool like Eclipse makes the renaming quite easy with the refactor
commands. It's quite impressive, actually. I feel like a kid just discovering a
marvellous new toy. I have not tried using Eclipse's C++ plugin yet so I
don't know if it works there, but it's rather nifty for Java at least.

That being said, I think you make good points about why hungarian notation
shouldn't be used.

--
~david-haley
david-usenet@the-haleys.com
(no unmunging necessary)
---------------------------

Ray Blaak wrote:

> Let type declarations encode the type. The name of an item should indicate
> what it is at a conceptual level (something that tends to be much more
> stable), and not worry about encoding the type. Rely on your IDE's
navigation
> abilities to find the declaration quickly if needed.

There are two topics here: Pure HN, and "warts".

Pure HN was invented before Microsoft had a useful code browser, and when C
did not always enforce typesafety.

Given pchFoo, your editor could select 'pch', and F1 would invoke the Help
system and tell you "pointer to character". This was useful when the prefix
was a complex type. The editor of that era (Programmer's WorkBench) couldn't
infer a real type from a symbol.

Modern coding styles typically use "warts". The distinction is they encode
the programmer's intent, as well-known abbreviations. Like all of modern
programming, they should help _encapsulate_ the true type, not couple to it.

Some common warts:

a - object or reference to object
m_ - member
str - string
p - pointer

Some less practical warts:

I - interface
C - class
s_ - static
sm_ - static member
g_ - global (don't get us started!)
sp - smart pointer

The sp isn't practical because one should generally not sling pointers or
smart pointers around like confetti. An owner object should employ a pointer
or smart pointer, and should only pass references ('a') to servant objects.

--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand

The struct idea sounds great, now how exactly would i implement this?
I have it setup like this so far:
//
// Character Class
// Author: Kotori
// Last Update: 29 April 05
//
struct Hero
{
int m_Hp;
int m_Mp;
int m_Atk;
int m_Def;
int m_Lck;
long m_Exp;
int M_Lvl;
char *m_heroName;
char *m_heroClass;
};

In my older code, i had the functions for getting and setting laid out
in the class, how exactly would i do this with this setup? By the way
i didn't intend on starting a holy war, i have used java before and it
was great for many things, but i saw it as lacking in the graphical API
department. I have found Allegro to be exactly what i am looking for.
No offense to the Java crowd out there, it was a great tool in my
learning of OOP. We never used structs in Java in fact i don't
think they exist in Java, lol.
My coding convention is a little mangled, i've picked up different
styles from the books i've read on C++ programming. I actually prefer
the hungarian style, but i'm sure every programmer has his preferences.