npc movement on tiles

[na_th_an]

yeah, which is no types!

Dots in variable names are bad practice, 'cause in every estructured language the dot is used to express a member of a data structure.

I find dots useful... for end of statements and for creating my own "taxonomy". :rotfl:

Why have data structures when you can express things EXPRESSLY?

To be more tidy.
To keep better track of your variables.
To write less.
To have better file managing.
To share data among modules in an easier manner.
To ease changes in your variable data (encapsulation).

Imagine that you have all your player's values in separate variables. You have to pass values to subroutines, you have to write 20 parameters. If you wanna add a new value you have to change every SUB call and every SUB header. Lack of encapsulation makes every subtle change an oddisey.

You just don't like TYPEs, but don't try to find an excuse 'cause you haven't Avoiding data structures is not good at all. It is just not so bad.

Not using TYPEs is just a matter of taste. But telling a newbie not to use'em is not a good practice (not didactic).

[Diroga]

I DONT GIVE A CRAP ABOUT TYPES I NEED HELP WITH THE npc MOVEMENT

[barok]

yeesh. talk like that and no-one will help you. for help with npc's, check out fling-masters rpg creation tutorials 2 and 3.



http://www.qbrpgs.com

[Diroga]

7h4n|< j00

[Agamemnus]

npc.x(n) = npc.x(n)-1
npc.y(n) = npc.y(n)+1

--------------------------------------

Na_th_an, I feel obligated to respond, for the good of non-TYPErs around the world:

>To be more tidy.
Debatable and unprovable, so I'll leave it alone.

> To keep better track of your variables.
You can do the same with a good DIMing methodology.

> To write less.
Yes, but only in the start of a DIM statement.

>To have better file managing.
True.

>To share data among modules in an easier manner.
True.

To ease changes in your variable data (encapsulation).
Hmm.....?

>Imagine that you have all your player's values in separate variables. You have to pass values to subroutines, you have to write 20 parameters.

Wrong! If the values are globals to begin with, all you need to do is pass an index variable! So that makes the next paragraph invalid too. But now you would proceed to go with the "passed locals are better than globals" argument, wouldn't you..?

>Not using TYPEs is just a matter of taste. But telling a newbie not to use'em is not a good practice (not didactic).

Well na_th_an, I think that we could compromise. Imagine a type.. of TYPE.. that follows the same naming conventions as a regular variable (index at the end), without absurdly limiting variable access or naming like a usual QB type. This TYPE would be converted to a regular variable before final compilation.

I suppose that things get weird if types had arrays with this kind of TYPE, but here's how I'd handle it:

Code:

TYPE b
c(1 to 10) AS INTEGER
END TYPE

DIM SHARED b(1 to 10) AS b

bla2=1: bla=1
b.c(bla2)(bla) = 4

'or perhaps:

b.c(bla2, bla) = 5

'It is true that you couldn't add this, too:
DIM SHARED b.c(1 to 10, 1 to 10) AS b
'but, why would ANYONE want to do that?

[Diroga]

dude you said that already. i get that. how do i loop that plus the move your sprite code ?

[Agamemnus]

how do i loop that plus the move your sprite code ?

Could you please rephrase that? I really have no idea what you just said.

[ak00ma]

Ok guy...this is a n00b version...I don't use it....but for you:

Code:

TYPE npcType

xpos AS INTEGER
ypos AS INTEGER

END TYPE

REDIM SHARED npc(100) AS npcType

npc(0).xpos = 0
npc(0).ypos = 0

SCREEN 13

PSET (npc(0).xpos, npc(0).ypos)

DO

SELECT CASE INKEY$

CASE "w": PRESET (npc(0).xpos, npc(0).ypos) : npc(0).ypos = npc(0).ypos - 1 : PSET (npc(0).xpos, npc(0).ypos)

CASE "s": PRESET (npc(0).xpos, npc(0).ypos) : npc(0).ypos = npc(0).ypos + 1 : PSET (npc(0).xpos, npc(0).ypos)

CASE "a": PRESET (npc(0).xpos, npc(0).ypos) : npc(0).xpos = npc(0).xpos - 1 : PSET (npc(0).xpos, npc(0).ypos)

CASE "d": PRESET (npc(0).xpos, npc(0).ypos) : npc(0).xpos = npc(0).xpos + 1 : PSET (npc(0).xpos, npc(0).ypos)

CASE CHR$(27): END

END SELECT

LOOP

I hope you understand at least this......

[Diroga]

Agamemnus-
if i do x=x+1 : y=y+1 then i have to loop that. in addition i have to loop the inkey$ to move my sprite around. how do i do that without problems.

[Diroga]

ak00ma-
thats the basic thing i use to move. whats the preset for? what's so bad about moving like that? is there a better way?