a character class for my rpg

Kotori wrote:

> The struct idea sounds great, now how exactly would i implement this?

How do you get to Carnegie Hall? Practice practice practice!

> 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;
> };

> 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.

You are not using "hungarian notation". That would be 'int m_iHp'.

From here, you have a lot of code to write between designing a hero class
and implementing the final game play. Google for the source to Rogue and
download it. You might even determine how to compile it, but at least it
will give you inspiration what the intermediate layers look like.

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

This day of 29 Apr 2005 15:47:24 -0700, "Kotori" <kotori83@hotmail.com> saw fit
to scribe:

>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?

You don't need to. You just directly access them:

Hero fred;
fred.m_Lck = 14;
// etc.

Or:

Hero * fred = new Hero();
fred->m_heroName = "fred"; // do this if you use STL strings
// etc.


Having getters and setters is redundant and impacts performance unnecessarily if
all you do is just straight return the data member. You shouldn't use them in
this case unless of course there is some interface design concern.


>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.

That's less and less the case IMO. The main issue is that graphics engines need
to be fast, _very_ fast and obviously Java takes a hit there when compared to
C++ or straight C. But more bindings are coming out that get around that
problem, and with improvements in processor power I wouldn't be at all surprised
if you could make a Java game with at least Quake 2 quality run smoothly on a
modern computer.


>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.

Which is, probably, why you never used them.

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

Erik Max Francis wrote:
> _My_ alleged annoying fanboyness? Do you even know who you're talking
> to, at this point?

Oh, mixed people up Anyway the first part of the post applies.

Tim Ford <timford1@REMOVETHISgmail.com> loquated like no one had ever
loquated before with:

> 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

Don't you find that paragraph a touch hypocritical Tim?
<Powers>There are 2 things that I really hate: people that are intolerant of
other cultures... and the dutch</Powers>

WTH

Tim Ford wrote:

> Erik Max Francis wrote:
>
>> _My_ alleged annoying fanboyness? Do you even know who you're talking
>> to, at this point?
>
>
> Oh, mixed people up Anyway the first part of the post applies.

The first part of the post applies? You think it's meaningfull to have
an opinion about someone being a "fanboy" on the basis of asking a
simple question? I suggest that you have an inflated view of the worth
of your opinion and perhaps a touch of hypocracy in the use of the term
"fanboy".

In article <usm19qzar.fsf_-_@STRIPCAPStelus.net>,
rAYblaaK@STRIPCAPStelus.net says...
> > 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.

Hungarian notation is supposed to help with both type and intended use.
The former can be harmful as you say, but the latter can be helpful.
So I think the optimum is a little more than m_ everywhere (this
distinguishes member variables from local ones).

For example, I use stat_ for static variables. I also give buttons
names like but_Help etc. Another convention I use is m_nThings for the
number of items. Enum values get all caps and a prefix relating to the
enum name.

- Gerry Quinn

In article <kkwce.1335$2f2.98@newssvr19.news.prodigy.com>,
phlip_cpp@yahoo.com says...

> Some less practical warts:
>
> I - interface
> C - class
> s_ - static
> sm_ - static member
> g_ - global (don't get us started!)
> sp - smart pointer

I cannot abide C for class. Everything should be a class anyway!

It drives me mad when I create a class with a name starting with C,
e.g. City, amd MSVC helpfully creates files called "ity.h" and
"ity.cpp".

- Gerry Quinn

In article <i3g571tk1ei3asta2ongk609ibri7li2sj@4ax.com>, david-
usenet@the-haleys.com says...
>
> Having getters and setters is redundant and impacts performance unnecessarily if
> all you do is just straight return the data member. You shouldn't use them in
> this case unless of course there is some interface design concern.

If he is looking for hero strength and attack values, they will quite
likely be modified by items or conditions. A getter function is
perfectly sensible. For now there is no difference between "strength"
and "base strength" but there will be some time. If you've got access
to m_Strength all over the program, you may find it troublesome when
you change.

Also, they may be accessed externally. For example, a bar graph
showing the hero's hit points may want const access to them.

Of course, the class itself can still access the variables directly if
it needs to. The functions can be inlined, removing the performance
issues. You can also do various variations on const access and access
by reference.

Also, performance is pretty much irrelevant here. How many times are
you going to need the hero's strength every second?

- Gerry Quinn

In article <MPG.1cdd5ef927cc8c9198a0a3@news.indigo.ie>,
gerryq@DELETETHISindigo.ie says...
> [...]
> Hungarian notation is supposed to help with both type and intended use.
> The former can be harmful as you say, but the latter can be helpful.

"m_" helps with neither type nor intended use; it designates scope.


> So I think the optimum is a little more than m_ everywhere (this
> distinguishes member variables from local ones).

And why is that distinction important? (I can think of two reasons,
neither of which is particularly compelling.)

--
Christer Ericson
http://realtimecollisiondetection.net/

This day of Sat, 30 Apr 2005 10:39:37 +0100, Gerry Quinn
<gerryq@DELETETHISindigo.ie> saw fit to scribe:

>In article <i3g571tk1ei3asta2ongk609ibri7li2sj@4ax.com>, david-
>usenet@the-haleys.com says...
>>
>> Having getters and setters is redundant and impacts performance unnecessarily if
>> all you do is just straight return the data member. You shouldn't use them in
>> this case unless of course there is some interface design concern.
>
>If he is looking for hero strength and attack values, they will quite
>likely be modified by items or conditions. A getter function is
>perfectly sensible. For now there is no difference between "strength"
>and "base strength" but there will be some time. If you've got access
>to m_Strength all over the program, you may find it troublesome when
>you change.

Right, hence 'interface design concern'. If all he's doing is just accessing
them straight and that's all he'll ever do, there's no reason to have getters
and setters. My point, obviously not clearly expressed enough, was that the big
answer to his question was the old "it depends" line.


>Also, they may be accessed externally. For example, a bar graph
>showing the hero's hit points may want const access to them.
>
>Of course, the class itself can still access the variables directly if
>it needs to. The functions can be inlined, removing the performance
>issues. You can also do various variations on const access and access
>by reference.
>
>Also, performance is pretty much irrelevant here. How many times are
>you going to need the hero's strength every second?

Probably not often. Still, I don't see why somebody should throw away
performance for no reason. If hero.strength and hero.getStrength() are perfectly
equivalent, and if, as I said above, there is absolutely no need for a getter
and there never will be, then why should we throw away performance?

Personally I would use a getter but that's also because I rarely have a data
member where there should be complete transparent access for the outside world.

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