So I have been thinking about a game and some aspects, it is still a HUGE work in progress, but will be a reality at some point.
I am hoping to use DCS and all the libraries it supports to try and make it nice and small (compared to a pure BASIC game that is) with graphics (not sure on size yet). But mostly I am hoping to make it more of an ABS (Action Battle System) style game with items, armor, and weapons of all sorts.

Any ideas or suggestions on how I would go about a nice, easy, simple AI that I could have update within the main loop (I seem to have issues making anything of that sort) even just a simple character that walks around and if you are beside it, it attacks.

Features:

Story (still haven't worked on that yet)
HUD (showing Health, money, and equipped weapons/items)
Pause Menu (shows equipped armor and allows you to change weapons and items)
Will have graphics and use XLibs's Tilemap and Sprite routines for everything.
Will have different types of items and weapons
Swords
Shields
Potions
Armor (Body, legs and helmet)
Magic (not guaranteed, but hopefully I can add those and not lag the game)
In-game Map (also more of a hopeful, mainly depending on the size of the game)

I will update with more details and (hopefully) images of the game in action once I get it going.

Is Pokemon the kind of thing you mean by an Action Battle System, where the fights take place in a separate arena from the normal map? A simple AI will (go towards you | only go towards you when you're within N tiles), and fight you when it's in an adjacent tile (X1 = X2+/-{0,1} AND Y1 = Y2+/-{0,1}).

Nope, that would be Turn Based, for an Action Battle Side Scroller think of the original Mega Man games.

Ah, that makes sense. So are you thinking of a platformer, or more of a 2D sidescrolling RPG? And clerical sidebar, why is BBCode always disabled in your posts?

Going for a top-down NES feel I am hoping. Also I I'm not sure why, I thought it was enabled. o.o

It looks like you went through your profile and hit the "no" column for every single option. I turned on smilies, BBCode, and signature attachment for you.

Thanks, I must have accidentally hit that tying to find Thr original theme at school.

No problem (it's Cemetech6, as you must have found). So, let's get back to discussing your RPG. It sounds like a big project, so I think it would perhaps be best if you broke it down into some more manageable steps for yourself?

For now, since making maps and the collision detection code is a simple process for me now, I want to focus on the enemy side of things, like attacking if they are right beside you (which I have working, when the "enemy" is stationary), I just want some "non-random" way for the enemy to move, but not always right at you ,random yes, but not like it could never get to you, some sort of direction it will head for and make eventually.

I think you should just start with a player and an enemy, two pairs of coordinates, on a single 8x16 screen, and learning to make a simple AI for that to get started.

I have it now so if you walk beside the enemy, you will take damage from it, and for now, if you don't move, it won't do anymore damage (it decided to reduce HP so fast it was ridiculous), so I had to set a conditional for that one issue. >.<

What about the AI moving towards you, though? And you could set some kind of limit so that it's only allowed to injure you once every N cycles.

The AI moving towards you is what I have been trying and failing time after time, and I shall look into the attacking every so often idea today.

All you need to do is check their relative positions. On each engine tick (or every N engine ticks, if you need to slow it down), check their positions. I like to do it this way:


Code:

In reply, I am having issues getting a movement of only 1 using just 2 conditionals, I seem to only be able to get it to move is the same way I would do movement by user input, just using randInt(1,4) instead of getKey, here is the code so far (just the main loop for movement).


Code:

That's just random movement, not movement in the direction of the player, isn't it?

It won't allow the enemy to move away from the player at all, it took a while to get something figured out, but it will not allow the enemy to move away from the player, only towards it.

That seems like a fairly awkward way to do it, to me. Can you tell me what the pair of variables for the player's position and the enemy's position are, and whether you'd like me to rewrite that code with something based on what I pseudocoded for you?

X,Z is the players X,Y.
S,T is the enemies X,Y.
I,J,N, and O are all used for checking the position before it moves the player/enemy.

At the re-write, that would be awesome as well.

Code:
I've also made a whole bunch of other optimizations. Also, no bounds-checking on the enemy is needed by virtue of how my code works.