ZFGC

Resources => Coding => Topic started by: 4Sword on July 04, 2008, 03:01:29 am

Title: Pokemon Walking Engine
Post by: 4Sword on July 04, 2008, 03:01:29 am
I was going to include a pause menu with this engine, but I am currently refining the way in which the menu is drawn.  This walking engine is a replication of the character movement in Pokemon Blue.  It is pretty basic and more features will be added later.

Includes:
- Walking on a Grid
- Solid Object Collision
- Correct Animation Rate
- Fixed View

Preview:
(http://i8.photobucket.com/albums/a13/4Sword/ashviewwalk.gif)

Download: PokemonWalk.gmk (http://crystalrook.sitesled.com/PokemonWalk.gmk) (30.93KB)
Title: Re: Pokemon Walking Engine
Post by: Walnut on July 04, 2008, 03:47:45 am
Good stuff, but friendly tip, you might want to considering renaming this. I mean, just read the topic title, realize this is ZFGC, remember the shitstorm over how this place supposedly gets nothing but walking engines, and reconsider the topic title.
Title: Re: Pokemon Walking Engine
Post by: 4Sword on July 04, 2008, 04:06:30 am
I figured that if I got a shitstorm that I would at least get something.  It is kind of funny in that I was once dumbfounded by how "Ash"'s footwork worked.  Like, if you are moving to the next grid space, before getting there one of your feet comes out, and then you stop and then if you move again in the same direction, you transition to the other foot.  I was going to try and find the image_speed by screen capturing the Pokemon Blue ROM which alters your image by position.  Meh, that was a complicated way of thinking about it; also, if I based image transition simply based on distance traveled, it would not animate if there were an obstacle in your way.

In regards to the menu, I left it out more specifically because upon observation of the way the Game Boy rendered it, the borders, arrows, and even letters all fit into 8 x 8 image sizes, so with that in mind I plan on rewriting what I had by basically mosaic-ing all of those 8x8s from a font sprite set instead of having stored complete images.  It sounds like I am over-thinking it, but in terms of efficiency, there are a lot of menus with different sizes, and doing it the way I mentioned with the mosaic like idea would make it better.

Also, thanks for the comment, I was surprised that someone saw this, lol.
Title: Re: Pokemon Walking Engine
Post by: Giverny on July 06, 2008, 08:21:08 pm
nice engine :p
As for the menu thing, in Pokemon Blue, the menu is a background, moer specifically a tileBG. Its to save RAM and ROM  and stuff.
Title: Re: Pokemon Walking Engine
Post by: 4Sword on July 06, 2008, 08:34:38 pm
Well I do not know if I will be able to replicate precisely how it is rendered due to the different structures of both Game Maker and the Game Boy, but this is how I draw the outer frame of my menus currently for any size of menu I want:

Code: [Select]
startxm = argument0;
startym = argument1;
lengm = argument2 - 2;
heigm = argument3 - 2;

draw_sprite(spr_font,98,startxm,startym); 
draw_sprite(spr_font,104,startxm, startym + ((heigm + 1) * 8));
draw_sprite(spr_font,100,startxm + ((lengm + 1) * 8),startym);
draw_sprite(spr_font,106,startxm + ((lengm + 1) * 8),startym + ((heigm + 1) * 8));

for (a = 1; a <= lengm; a += 1)
{
  draw_sprite(spr_font,99,startxm + (a * 8),startym);
  draw_sprite(spr_font,105,startxm + (a * 8),startym + ((heigm + 1) * 8));
}

for (b = 1; b <= heigm; b += 1)
{
  draw_sprite(spr_font,101,startxm,startym + (b * 8));
  draw_sprite(spr_font,103,startxm + (a * 8),startym + (b * 8));
}

It could even be more simplified if I replaced the variable names in the bottom part with just the argument names.  I am trying to make it so that when I draw static text that it does not refer back to the variables in this script; which should be easy enough, I just have to change the way blank white space and text are allocated when drawn.  Right now I have it all set up so that draw_menu, draw_txts, and draw_arro are all separate.  Somewhat of an issue comes up when when calling draw_txts because the white space extends to where the arrows drawn x-coordinate, but it is not that much to worry about.
Title: Re: Pokemon Walking Engine
Post by: HyperKnight32 on July 07, 2008, 12:53:18 am
Looks like you've put a lot of effort into this.

I remember back in the GM day I made a pokemon walk engine(which has been long since lost forever). But unfortunately it was mostly drag and drop 'cause I couldn't really understand the concept of gml and struggled with the language. But it was fun to walk around in, I had townspeople who randomly walked around in the game and it was impossible to collide and get stuck in them. I also observed FFIV and made a walk engine, I watched the movement in the game and what I was doing so closely I'm pretty sure I almost got it just like the game.

Oh how I wish I could make games in gamemaker again, unfortunately due to the high criticism of it and the difficulty for me to learn a programming language from scratch I think I'd be better of sticking to composing music. But the urge to make a game is so strong, and gamemaker isn't that bad when you know what you're doing, I like this walk engine very much. Reminds me of when I made my own :).
Title: Re: Pokemon Walking Engine
Post by: 4Sword on July 07, 2008, 05:02:33 am
Thanks, but it only looks like a lot of effort because I included commenting with the code so that others could learn from it more easily if they wanted to.  I am really trying hard to make it as efficient as it can be though; in doing so, I ended up siding with the built in place_snapped function rather than doing it custom with modulus and the number 16 with both x and y to determine if the character is on the grid. 

Game Maker is just a tool that if used well it cannot be mocked totally.  Pokemon Blue is fun to work with in that its challenges are code related so I will probably continue working with it alone until I can get into making Pokemon in something like C# if possible.  I also have a Legend of Zelda game that has a movement engine modified from Goodnight's in its sprite checking that is pretty good; you can swing your sword, go in and out of buildings, and move around with your shield out at a slower speed.  I might just release that later because I do not know how far I will get on that, but it is helpful because the code is nice and the animations for Link are done well.

But yeah, a while back I went through a game making slump.  A while ago I started trying again and now it just feels kind of natural and challenging in a good way.  It is not so much my passion, but it feels nice. 
Title: Re: Pokemon Walking Engine (Also WIP Menu Engine)
Post by: 4Sword on July 07, 2008, 09:03:22 pm
Yeah, I was working with the menu engine, getting the basics down; I would have been bailing straw today, but it rained and you cannot move that stuff when it is wet (well, it is not that hard, but you do not want the barn to lose support by having the wood rot).  Anyway, like I said, it is a work-in-progress engine, but the basics are good.

Includes:
- Drawing a Menu of Custom Width and Length
- Drawing Text Staring on Line One or Two of Custom Width and Length

Preview:
(http://i8.photobucket.com/albums/a13/4Sword/menuearlypreview_15050.gif)

Download: PokemonMenuWIP.gmk (http://crystalrook.sitesled.com/PokemonMenuWIP.gmk) (35.29KB)

EDIT: I have not updated it yet, but as you can see by the screen shot, there is a gap between the text and the frame.  This is for the arrow that is drawn to indicate your position on the menu.  What I have to do is figure out how to record that position so that an arrow can be drawn there.  How do I do this?  Hypothetically, I could try put a symbol into the text line that when read indicates an arrow position to be drawn.  By doing this I would have to omit the arrow position symbol before it is read by the text drawer.  I think I know what to do.  The only thing I really have to focus on is drawing the arrow to the left or right of the text as a yes/no choice box draws it on the right, but that should be easy enough.

EDIT2: I am an idiot.  The yes/no box has the arrow on the left still, so this should be easy enough to make.

EDIT3: I tested out my hypothesis and it proved right to some degree.  I altered the way in the text and blanks were drawn; to create a blank 8x8 space for the arrows, a tilde precedes the spot in text where the arrow is drawn.  Inside the code I also record what that drawn position would have been into a variable.  However, there are issues still.  Basically, if you are the main menu and want to go to another menu, the arrow becomes hollow on the main menu and should stay like that until you get back.  I could probably fix this with a "previous" variable and by using two-dimensional arrays to store the image return value to display the arrow based on menu position and menu type.  It's a pain in the ass to work out, lol.  The menu works now by drawing the main menu, and then drawing the sub-menus over it, and rather than creating sub menu position variables.  Guh...  I did solve the menu frame and text drawing things, but the arrows are elusive.
Title: Re: Pokemon Walking Engine (With Ledge Jumping)
Post by: 4Sword on July 14, 2008, 03:41:50 am
I did not have the left, right, and up directions for jumping off a ledge because I mainly felt done with the concept and replicating the displacement numbers would take forever.  It is not fully done though, but yeah, it is something.

Changes:
- Reworked code to lessen dependence on step event
- "Ash" is now drawn four pixels up compared to last download to be in the correct position.

Updates:
- Ledge Jumping

Flaws:
- Shadow is not drawn directly before you jump off ledge and directly after you land
- Some redundancy in "Ash" displacement variables when drawing.

Preview:
(http://i8.photobucket.com/albums/a13/4Sword/ledgejump.gif)

Download: PokemonWalk2.gmk (http://crystalrook.sitesled.com/PokemonWalk2.gmk) (32.10KB)
Title: Re: Pokemon Walking Engine
Post by: HyperKnight32 on July 14, 2008, 03:48:05 am
Looking good in the preview, by drawn four pixels up did you change the sprite size by +4 or did you set the y origin to 4 pixels?
Title: Re: Pokemon Walking Engine
Post by: 4Sword on July 14, 2008, 03:58:02 am
Oh, you are right, I could have done that, but instead I just set the displacement drawing variable for "Ash" to be set to -4.  In the Draw Event, there is a condition statement to determine whether or not to draw the shadow and then a function to draw "Ash" himself with the x value set to x + image_dispx.  I will probably change this later though when I go through it again to update it for efficiency. 

Also, the reason the flaw exists is mostly because the condition that is checked to draw the shadow is true when "Ash" is overlapping the ledge object.

EDIT: There also seems to be a glitch in the engine somewhere.  Somehow if something is just right, you can walk up through a ledge, but replicating the effect is nearly impossible.
Title: Re: Pokemon Walking Engine
Post by: Minilinkki on July 21, 2008, 09:17:42 pm
Wow, good work man, i like it.
Mod Edit: You may watch your offensive tone, if you don't mind. This is a collaborating topic, have a little more respect, if you don't mind.
Title: Re: Pokemon Walking Engine
Post by: 4Sword on July 21, 2008, 09:25:11 pm
I am currently working on redoing it again as the animation rate for the "Ash" character was twitchy when he would come to a stop.  That, and since the drawing is done at the end of each step, updating the animation has to be figured in accordingly.  My reworked engine that I might release soon if it is good enough actually does everything without the use of speed, as it now would only use x and y position updates each step.  I have fixed the animation so it is perfectly perfect now, I just have to finish the ledge jumping so that I do not go backwards in my updated engine versions in terms of functionality.
Title: Re: Pokemon Walking Engine
Post by: 4Sword on July 29, 2008, 04:38:49 am
Alright, I just got done reworking the ledge jumping and walking engine.  The only bit of code that I did not like in it is in the step event, to check for the presence of a ledge, it seems redundant, but only a little.  Also, I noticed on an emulator, the controls for Pokemon movement were simpler than I thought.

Updates/Corrections:
- There is a delay when you jump off of the ledge to draw a shadow.
- The shadow is still drawn for one step when you land.
- The step event is used over dividing it up into key presses for simplicity.
- The "solid" objects no longer have step events of themselves, this saves processing power
- Up-down-left-right hierarchy priority key setting (it looks like a step back, but this is how the Game Boy did it)
- Image transition is clean and self-correcting; since drawing is done last, image transition was set back a step.
- X and Y movement setup rather than the speed function
- Image Displacement off of ledge includes only values where displacement changes compared to last displacement value
- Directional variables have been removed in favor of setting a "snap" position and comparing the current x or y to it.

Download: PokemonWalk3.gmk (http://crystalrook.sitesled.com/PokemonWalk3.gmk) (28.77KB)

Edit: I just figured out that it still is not perfect, lol, I need to tweak it so that there is a felt delay after landing.  I thought that it was fine since it still drew the shadow, but there is no real delay, sorry.

Edit2: Simple fix, it now works as perfectly as it needs to, oh and I reworked the level so that there are a series of downhills for the hell of it, lol.
Title: Re: Pokemon Walking Engine
Post by: kremling on July 30, 2008, 08:30:36 pm
Wow, nice engine so far, works real well.
Title: Re: Pokemon Walking Engine
Post by: SlimmyG on July 30, 2008, 09:35:05 pm
Wow, this works really well. Is this building up to some lasrger project?
Title: Re: Pokemon Walking Engine
Post by: 4Sword on July 30, 2008, 10:01:17 pm
I plan on making it a larger project, but I cannot promise that I will have the interest to go that far; working out the way it works is where I am having the most fun right now.  I did have this odd idea that once it was done I could tweak it so that the main character is Link who has attacks like a Pokemon and Zelda creatures were in the game, lol.  The next update will have surfing and walking through tall grass; most of the effects for which are done, I just have to get the animation's timing of the water right.  The text engine is the hardest part and that is not close to being done yet.  I also have to work on a way to fade when going in and out of buildings as well as battle transitions. 
Title: Re: Pokemon Walking Engine
Post by: SlimmyG on July 30, 2008, 10:11:56 pm
I plan on making it a larger project, but I cannot promise that I will have the interest to go that far; working out the way it works is where I am having the most fun right now.  I did have this odd idea that once it was done I could tweak it so that the main character is Link who has attacks like a Pokemon and Zelda creatures were in the game, lol.  The next update will have surfing and walking through tall grass; most of the effects for which are done, I just have to get the animation's timing of the water right.  The text engine is the hardest part and that is not close to being done yet.  I also have to work on a way to fade when going in and out of buildings as well as battle transitions. 

That sounds pretty damn amazing, and judging by what ive seen so far, its gonna be awesome. Also that does sound like a cool idea for a game...
Title: Re: Pokemon Walking Engine
Post by: 4Sword on August 22, 2008, 12:49:21 am
This isn't an update that a lot of people who have looked into the code can appreciate because I am not done with it yet, but I made a breakthrough in regard to both the movement code (if you are off the grid, incrementing where you are is now based on your sprite_index, in a similar fashion, I got rid of the fake key presses as you cannot change your sprite anyway when you are in a delay thus you can use the sprite_index to tell the game what to do).

The reason that I am not giving out the GM7 is that the transitions, while they work effectively, they are not fully done in that objects are not made completely black before the transition goes full black.

http://crystalrook.sitesled.com/PokeProject.zip
Title: Re: Pokemon Walking Engine
Post by: Kingknight on August 22, 2008, 01:07:28 am
wow 4sword keep it up lookin better every second :)
Title: Re: Pokemon Walking Engine
Post by: HyperKnight32 on August 22, 2008, 01:11:28 am
Oh my, this is flawless!

The walking, the centred view and everything, you've done an exceptional job. I think this has just given me the spark I needed to actually do something in gm. Do you know if it's possible to do the exact same in GM 6.1A registered?

Not saying I want to do a Pokemon game, just enough functions and stuff to be able to have the same effect.

Anyway this is quite exceptional, it's getting better each time I see this, quite surprised when I compared it to the original. I do see what you mean by the transition, but it's not much of a big deal but it can be easily done like how you want it.
Title: Re: Pokemon Walking Engine
Post by: 4Sword on August 22, 2008, 01:19:56 am
lol, thanks Kingknight and HyperKnight32.  Oh, and this is being made in GM7 unregistered; which kind of sucks in that some of the fading effects are going to be more difficult to accomplish.  So yeah, you would be more than able to do the same in GM6.1A registered, in fact, you could probably do a little bit more.
Title: Re: Pokemon Walking Engine
Post by: Kingknight on August 22, 2008, 01:23:29 am
looking forward to your surfing example
plz post it soon i can't wait XD
Title: Re: Pokemon Walking Engine
Post by: HyperKnight32 on August 22, 2008, 01:25:40 am
Ah ok, awesome, thanks for that :D. I only know how to do a grid based walking engine with drag and drop, of course if I bother to learn more gml it can be easily accomplished.

I like it how you've done this with the original Pokemon games and not one of the newer ones. I've always liked the original most XD, something about it just kept me captivated.
Title: Re: Pokemon Walking Engine
Post by: 4Sword on August 22, 2008, 01:38:54 am
looking forward to your surfing example
plz post it soon i can't wait XD
It's actually not that hard to do; I was working on it earlier, but it is not ready yet.  I was thinking about having a obj_surf character that has obj_ash as its parent, which makes the code easier.  However, the surf object does not need to do checks for obj_enter (enter door), obj_exit (exit door), obj_ledge_ (ledge), or obj_grass (grass), so I am thinking about just having it use its own code; if the water is in a "region" where Pokemon are as well, all of the water becomes similar to grass on land.  I might have the obj_bike character have obj_ash as its parent though as most of the code and place checks are the same.

Ah ok, awesome, thanks for that :D. I only know how to do a grid based walking engine with drag and drop, of course if I bother to learn more gml it can be easily accomplished.

I like it how you've done this with the original Pokemon games and not one of the newer ones. I've always liked the original most XD, something about it just kept me captivated.

Grid-based stuff is easy once you get into it really; all it is is normal movement with restrictions.  I like the original game too; its actually odd that I am remaking Pokemon Blue as the first game I had was Yellow and then I got Red - I only got Blue when I traded in a Gameshark.  I was playing Blue earlier though, and I think that I have an idea of how random NPC movement works (they just go in random directions within a set region, which is why characters don't walk out of towns and the one guy in Cerulean only walks up and down). 

Anyway, going from drag and drop to GML is not that difficult once you get the function names down. 
Title: Re: Pokemon Walking Engine
Post by: Moon_child on August 22, 2008, 01:47:19 am
So are you planning to make a Pokemon game? Anyway it's pretty nice.
Title: Re: Pokemon Walking Engine
Post by: 4Sword on August 22, 2008, 02:02:22 am
Well, I would be getting ahead of myself to say that I am planning to make a game with it because I have just mainly done the overworld features and there are other overworld features that I have to work out (Sabrina's gym's warp tiles, refreshing areas in that area with the ghost Pokemon, stairs, biking downhill that gets forced although that is more of an obj_bike issue based on "region" or possibly room, etc). 

I looked at the GML Help file and it made me believe that font_add_sprite() was able to be used in the unregistered version by not stating that you could only use it in the registered version.  Getting past this is not that difficult, just time-consuming in that it takes longer.

Oh, and thanks.
Title: Re: Pokemon Walking Engine
Post by: Kingknight on August 22, 2008, 02:09:19 am
will u make a flying example that would be really helpfull :P
Title: Re: Pokemon Walking Engine
Post by: 4Sword on August 22, 2008, 02:14:50 am
Flying, doesn't seem like it would be that difficult to do, but I have not attempted it yet.  The way it happens though is that you navigate through a menu, select fly from a Pokemon that can, pick a spot on a map or back out of it, go back to the menu or do a graphical fly pattern, and then if you chose to fly, you land where you need to go and are facing something like left and then you face down.  It's not really difficult to get that into code, but it helps to have more than one location before I can test it.
Title: Re: Pokemon Walking Engine
Post by: 4Sword on August 23, 2008, 06:16:57 am
Update: This is not so much a substantive update in terms of adding to what I have, but I feel confident enough to start this as a project soon.  I still have to get two more screenshots that show off a new feature (and for that I have to make new features) and I have to put together a stable demo with those features.  I have put up a project page though on the site and will update this whole thing as well as here (I will use here for the little stuff).

Here is the link to the page on the site: http://www.zfgc.com/index.php#?action=games&sa=view&id=65
Title: Re: Pokemon Walking Engine
Post by: 4Sword on August 24, 2008, 06:51:00 am
I got bored, so I added some quick !@#$%.  I detailed this on my project page which is located under Games -> WIP Games on the Site, and the download is located under the downloads section which is also on my project page.  The room transition has not been fixed yet because it works well enough for now, but I added some new things such as:
- Multiple rooms (the previous version only had two locations, so the code was really smoke and mirrors)
- NPC that changes direction when you face him and are close to him and press "Z".
- Deactivating objects outside the view (if you play the Gameboy, you may notice that objects only appear once "Ash" is snapped to the grid, thus between grid spaces, the presence of NPCs and other objects ahead might not be "visible" - use Oak in my demo to see this better)

Download page is located at:
http://www.zfgc.com/index.php#?action=games&sa=view&id=65
Title: Re: Pokemon Walking Engine
Post by: wildex999 on August 24, 2008, 09:48:19 am
Hm... the "invisible" object thing worked well, except that it didn't work when walking in from the left to right, no big problem tho, I would not have noticed they popped in anyway, never did for the original game anyho =/
The rest looks as detailed and good as ever =P
Title: Re: Pokemon Walking Engine
Post by: 4Sword on August 24, 2008, 03:40:13 pm
I do not know what you are specifically referring to, but I think the reason that it might not be "working" from coming from the left is that when you are to the far left of Oak, you are actually off-screen with your x-coordinate as negative; it works fine for me from the right.  And yeah, in the original game they popped in, I checked it on an emulator.  Oh, and another thing, if you enter a building and between rooms you press left or right, when you get to the next room it will not always go left or right because the keyboard status is not checked when the window is invisible.  This is actually a flaw in Game Maker; if there was a function to check if the window was active, then I would be fine and I would have used keyboard_check_direct() (using it otherwise, you would be able to move even if the window of the game was not selected).

Edit: Actually, I just checked, and you were right, thanks.  It shouldn't be that hard to fix, I just have to lessen the width of the activation region on the right by one.
Title: Re: Pokemon Walking Engine
Post by: Moon_child on August 24, 2008, 04:40:50 pm
A great update! it has become more gameboy-like!
Title: Re: Pokemon Walking Engine (Now in SDL)
Post by: 4Sword on September 19, 2008, 03:48:14 am
This is kind of a weird update and there seems to be something wrong in the code somewhere that I am trying to fix, but meh.  I have pretty much stopped major work on the Game Maker version of this and instead I have started C++ programming with SDL.  Here is just Ash walking around on a grid (the images mess up if you push keys funny on grid spaces, lol, although one of them shows the entire sheet so I think that it is partially based on how the image is displayed in my show() method)

Edit: Oh, I discovered part of the problem.  Mostly since my GM code was not so dependent on GM functions I was able to copy the way it was written from there into C++ and SDL for the most part.  In the up-down-left-right checking though, in the GM version, if you are on a walking frame instead of a standing one while you are on a tile, it updates it to be a standing one.  In my C++ code I forgot to check to make sure the image index was not 3.  It was going to a 4 index which didn't exist in the image memory so it was looking for something that wasn't there and getting something from overflow.  I will include this fix in the next release.

Edit2: Fixed an error where if you stopped you would sometimes be stuck on a walking frame.  This was because the index checking I mentioned in the previous Edit, if you were on index 3 which was completely legitimate, it would not update to the next legitimate index in my code.  I fixed it, but it doesn't seem optimism.

Edit3: I just decided to fix it and update the download so here:

http://www.zfgc.com/index.php?action=games&sa=getdownload&id=259

(The only big issue with it now is how if you tap the keys you can seemingly go a little faster, but meh, that might all just be in my head)
Title: Re: Pokemon Walking Engine
Post by: HyperKnight32 on September 19, 2008, 08:33:51 am
It doesn't work :(. All I get is a black box that flashes for a split second then it closes without any error message or anything, was looking forward to it, ah well.
Title: Re: Pokemon Walking Engine
Post by: 4Sword on September 19, 2008, 08:44:17 am
Yeah, I think I rushed parts of it.  It works for me if I put it on my Desktop, but running it out of a folder gives problems, lol.  Sorry about that.  I will look into it more to see if there is a good way to fix the problem.

Edit: It is late (4:02 AM and I have a test at 9:00 AM) so I will get back on this later today.  The test is actually going to be easy since I had the same one last year although this is a different class.  It's all about logical relationships.  I might also include the source code but it isn't that flashy; it is just a modified tutorial where I changed some functions and changed the sprites and the source would contain the means to compile it on your computer if you had SDL, meh.

Edit2: Try this: http://www.zfgc.com/index.php?action=games&sa=getdownload&id=260

Extract it anywhere or to the Desktop and try it, it has all the images and stuff with it.
Title: Re: Pokemon Walking Engine
Post by: wildex999 on September 19, 2008, 10:58:26 am
Hehe, the second download worked. :) The grid movement seems to work, except for the tapping = walking faster part ;)

Hm.. now I'm curious...*Goes to look at source*

By the way, what compiler did you use?

EDIT: Awww, the .c file isn't a full source =(
Owell =P
Title: Re: Pokemon Walking Engine
Post by: 4Sword on September 19, 2008, 03:09:09 pm
Yeah, I had to experiment with how key checking was done because it was not directly working correctly with the format where it checked to see if a key was up or down.  I ended up having to put in variables press_u, press_d, press_l, and press_r to hold Boolean values and that ended up working differently.  I don't really know fully why you can go faster by tapping the keys, it may just be how it processes.  As for the source, it is just:

Code: [Select]
//The headers
#include "SDL/SDL.h"
#include "SDL/SDL_image.h"
#include <string>

//The screen attributes
const int SCREEN_WIDTH = 160;
const int SCREEN_HEIGHT = 144;
const int SCREEN_BPP = 32;

//The frame rate
const int FRAMES_PER_SECOND = 30;

//The dimensions of the dot
const int DOT_WIDTH = 16;
const int DOT_HEIGHT = 16;

//The surfaces
SDL_Surface *dot = NULL;
SDL_Surface *screen = NULL;

SDL_Rect clipsUp[ 4 ];
SDL_Rect clipsDown[ 4 ];
SDL_Rect clipsLeft[ 4 ];
SDL_Rect clipsRight[ 4 ];

//The event structure
SDL_Event event;

//The dot that will move around on the screen
class Dot
{
    private:
    //The X and Y offsets of the dot
    int x, y, xprev, yprev;
   
    //Psuedo-Keys
   
    bool press_u, press_d, press_l, press_r;
   
    //Direction Temp
    int d;
   
    //Animation Rate
    int anima;
   
    //Image Index
    int index;
   
    public:
    //Initializes the variables
    Dot();
   
    //Moves the dot
    void move();
   
    //Shows the dot on the screen
    void show();
};

//The timer
class Timer
{
    private:
    //The clock time when the timer started
    int startTicks;
   
    //The ticks stored when the timer was paused
    int pausedTicks;
   
    //The timer status
    bool paused;
    bool started;
   
    public:
    //Initializes variables
    Timer();
   
    //The various clock actions
    void start();
    void stop();
    void pause();
    void unpause();
   
    //Gets the timer's time
    int get_ticks();
   
    //Checks the status of the timer
    bool is_started();
    bool is_paused();   
};

SDL_Surface *load_image( std::string filename )
{
    //The image that's loaded
    SDL_Surface* loadedImage = NULL;
   
    //The optimized surface that will be used
    SDL_Surface* optimizedImage = NULL;
   
    //Load the image
    loadedImage = IMG_Load( filename.c_str() );
   
    //If the image loaded
    if( loadedImage != NULL )
    {
        //Create an optimized surface
        optimizedImage = SDL_DisplayFormat( loadedImage );
       
        //Free the old surface
        SDL_FreeSurface( loadedImage );
       
        //If the surface was optimized
        if( optimizedImage != NULL )
        {
            //Color key surface
            SDL_SetColorKey( optimizedImage, SDL_SRCCOLORKEY, SDL_MapRGB( optimizedImage->format, 255, 0, 255 ) );
        }
    }
   
    //Return the optimized surface
    return optimizedImage;
}

void apply_surface( int x, int y, SDL_Surface* source, SDL_Surface* destination, SDL_Rect* clip = NULL )
{
    //Holds offsets
    SDL_Rect offset;
   
    //Get offsets
    offset.x = x;
    offset.y = y;
   
    //Blit
    SDL_BlitSurface( source, clip, destination, &offset );
}

void set_clips()
{
    //Up Sprites
    clipsUp[ 0 ].x = 0;
    clipsUp[ 0 ].y = 0;
    clipsUp[ 0 ].w = DOT_WIDTH;
    clipsUp[ 0 ].h = DOT_HEIGHT;
   
    clipsUp[ 1 ].x = DOT_WIDTH;
    clipsUp[ 1 ].y = 0;
    clipsUp[ 1 ].w = DOT_WIDTH;
    clipsUp[ 1 ].h = DOT_HEIGHT;
   
    clipsUp[ 2 ].x = DOT_WIDTH * 2;
    clipsUp[ 2 ].y = 0;
    clipsUp[ 2 ].w = DOT_WIDTH;
    clipsUp[ 2 ].h = DOT_HEIGHT;
   
    clipsUp[ 3 ].x = DOT_WIDTH * 3;
    clipsUp[ 3 ].y = 0;
    clipsUp[ 3 ].w = DOT_WIDTH;
    clipsUp[ 3 ].h = DOT_HEIGHT;
   
    //Down Sprites
    clipsDown[ 0 ].x = 0;
    clipsDown[ 0 ].y = DOT_HEIGHT;
    clipsDown[ 0 ].w = DOT_WIDTH;
    clipsDown[ 0 ].h = DOT_HEIGHT;
   
    clipsDown[ 1 ].x = DOT_WIDTH;
    clipsDown[ 1 ].y = DOT_HEIGHT;
    clipsDown[ 1 ].w = DOT_WIDTH;
    clipsDown[ 1 ].h = DOT_HEIGHT;
   
    clipsDown[ 2 ].x = DOT_WIDTH * 2;
    clipsDown[ 2 ].y = DOT_HEIGHT;
    clipsDown[ 2 ].w = DOT_WIDTH;
    clipsDown[ 2 ].h = DOT_HEIGHT;
   
    clipsDown[ 3 ].x = DOT_WIDTH * 3;
    clipsDown[ 3 ].y = DOT_HEIGHT;
    clipsDown[ 3 ].w = DOT_WIDTH;
    clipsDown[ 3 ].h = DOT_HEIGHT;
   
    //Left Sprites
    clipsLeft[ 0 ].x = 0;
    clipsLeft[ 0 ].y = DOT_HEIGHT * 2;
    clipsLeft[ 0 ].w = DOT_WIDTH;
    clipsLeft[ 0 ].h = DOT_HEIGHT;
   
    clipsLeft[ 1 ].x = DOT_WIDTH;
    clipsLeft[ 1 ].y = DOT_HEIGHT * 2;
    clipsLeft[ 1 ].w = DOT_WIDTH;
    clipsLeft[ 1 ].h = DOT_HEIGHT;
   
    clipsLeft[ 2 ].x = DOT_WIDTH * 2;
    clipsLeft[ 2 ].y = DOT_HEIGHT * 2;
    clipsLeft[ 2 ].w = DOT_WIDTH;
    clipsLeft[ 2 ].h = DOT_HEIGHT;
   
    clipsLeft[ 3 ].x = DOT_WIDTH * 3;
    clipsLeft[ 3 ].y = DOT_HEIGHT * 2;
    clipsLeft[ 3 ].w = DOT_WIDTH;
    clipsLeft[ 3 ].h = DOT_HEIGHT;
   
    //Right Sprites
    clipsRight[ 0 ].x = 0;
    clipsRight[ 0 ].y = DOT_HEIGHT * 3;
    clipsRight[ 0 ].w = DOT_WIDTH;
    clipsRight[ 0 ].h = DOT_HEIGHT;
   
    clipsRight[ 1 ].x = DOT_WIDTH;
    clipsRight[ 1 ].y = DOT_HEIGHT * 3;
    clipsRight[ 1 ].w = DOT_WIDTH;
    clipsRight[ 1 ].h = DOT_HEIGHT;
   
    clipsRight[ 2 ].x = DOT_WIDTH * 2;
    clipsRight[ 2 ].y = DOT_HEIGHT * 3;
    clipsRight[ 2 ].w = DOT_WIDTH;
    clipsRight[ 2 ].h = DOT_HEIGHT;
   
    clipsRight[ 3 ].x = DOT_WIDTH * 3;
    clipsRight[ 3 ].y = DOT_HEIGHT * 3;
    clipsRight[ 3 ].w = DOT_WIDTH;
    clipsRight[ 3 ].h = DOT_HEIGHT;   
}

bool init()
{
    //Initialize all SDL subsystems
    if( SDL_Init( SDL_INIT_EVERYTHING ) == -1 )
    {
        return false;   
    }
   
    //Set up the screen
    screen = SDL_SetVideoMode( SCREEN_WIDTH, SCREEN_HEIGHT, SCREEN_BPP, SDL_SWSURFACE );
   
    //If there was an error in setting up the screen
    if( screen == NULL )
    {
        return false;   
    }
   
    //Set the window caption
    SDL_WM_SetCaption( "Pokemon Blue SDL", NULL );
   
    //If everything initialized fine
    return true;
}

bool load_files()
{
    //Load the dot image
    dot = load_image( "character.bmp" );
   
    //If there was a problem in loading the dot
    if( dot == NULL )
    {
        return false;   
    }
   
    //If everything loaded fine
    return true;
}

void clean_up()
{
    //Free the surface
    SDL_FreeSurface( dot );
   
    //Quit SDL
    SDL_Quit();
}

Dot::Dot()
{
    //Initialize the offsets
    x = 0;
    y = 0;
    xprev = 0;
    yprev = 0;
    d = 1;
    anima = 0;
    index = 0;
    press_u = false;
    press_d = false;
    press_l = false;
    press_r = false;
   
}

void Dot::move()
{
    //If a key was pressed
    if( event.type == SDL_KEYDOWN )
    {
        switch( event.key.keysym.sym )
        {
            case SDLK_UP: press_u = true;; break;
            case SDLK_DOWN: press_d = true; break;
            case SDLK_LEFT: press_l = true; break;
            case SDLK_RIGHT: press_r = true; break;   
        }
    }
    else if( event.type == SDL_KEYUP )
    {
        switch( event.key.keysym.sym )
        {
            case SDLK_UP: press_u = false; break;
            case SDLK_DOWN: press_d = false; break;
            case SDLK_LEFT: press_l = false; break;
            case SDLK_RIGHT: press_r = false; break;   
       }       
    }
   
    if (x % 16 == 0 && y % 16 == 0)
    {   
      //if (xprev != x || yprev != y)
      //{
        xprev = x;
        yprev = y;
        //return;
      //}

      if (press_u)
      {
        y -= 2;
        d = 0;
       
        if (index % 2 != 0 && index < 4)
        {
          index++;
        }
       
        anima = 1;
        return;
      }
      else if (press_d)
      {
        y += 2;
        d = 1;
       
        if (index % 2 != 0 && index < 4)
        {
          index++;
        }
       
        anima = 1;
        return;
      }
      else if (press_l)
      {
        x -= 2;
        d = 2;
       
        if (index % 2 != 0 && index < 4)
        {
          index++;
        }
       
        anima = 1;
        return;
      }
      else if (press_r)
      {
        x += 2;
        d = 3;
       
        if (index % 2 != 0 && index < 4)
        {
          index++;
        }
       
        anima = 1;
        return;
      }
      else if (!press_u && !press_d && !press_l && !press_r)
      {
        if (index % 2 != 0 && index < 4)
        {
          index++;
          return;
        }
       
        if (index % 2 == 0)
        {
          anima = 0;
          return;
        }
      }
    }
    else
    {
      switch (d)
      {
        case 0: y -= 2; anima++; return; break;
        case 1: y += 2; anima++; return; break;
        case 2: x -= 2; anima++; return; break;
        case 3: x += 2; anima++; return; break;
      }
    }   
}

void Dot::show()
{
     
    if (index == 4)
    {
      index = 0;
    }
     
    switch (d)
    {
      case 0: apply_surface( x, y - 4, dot, screen, &clipsUp[ index ] ); break;
      case 1: apply_surface( x, y - 4, dot, screen, &clipsDown[ index ] ); break;
      case 2: apply_surface( x, y - 4, dot, screen, &clipsLeft[ index ] ); break;
      case 3: apply_surface( x, y - 4, dot, screen, &clipsRight[ index ] ); break;
    }
   
    if (anima == 3)
    {
      if (index <= 3)
      {
        index++;
      }
           
      if (index == 4)
      {
        index = 0;
      }
     
      return;
    }
    else if (anima == 4)
    {
      anima = 0;
      return;
    }

}

Timer::Timer()
{
    //Initialize the variables
    startTicks = 0;
    pausedTicks = 0;
    paused = false;
    started = false;   
}

void Timer::start()
{
    //Start the timer
    started = true;
   
    //Unpause the timer
    paused = false;
   
    //Get the current clock time
    startTicks = SDL_GetTicks();   
}

void Timer::stop()
{
    //Stop the timer
    started = false;
   
    //Unpause the timer
    paused = false;   
}

void Timer::pause()
{
    //If the timer is running and isn't already paused
    if( ( started == true ) && ( paused == false ) )
    {
        //Pause the timer
        paused = true;
   
        //Calculate the paused ticks
        pausedTicks = SDL_GetTicks() - startTicks;
    }
}

void Timer::unpause()
{
    //If the timer is paused
    if( paused == true )
    {
        //Unpause the timer
        paused = false;
   
        //Reset the starting ticks
        startTicks = SDL_GetTicks() - pausedTicks;
       
        //Reset the paused ticks
        pausedTicks = 0;
    }
}

int Timer::get_ticks()
{
    //If the timer is running
    if( started == true )
    {
        //If the timer is paused
        if( paused == true )
        {
            //Return the number of ticks when the timer was paused
            return pausedTicks;
        }
        else
        {
            //Return the current time minus the start time
            return SDL_GetTicks() - startTicks;
        }   
    }
   
    //If the timer isn't running
    return 0;   
}

bool Timer::is_started()
{
    return started;   
}

bool Timer::is_paused()
{
    return paused;   
}

int main( int argc, char* args[] )
{
    //Quit flag
    bool quit = false;
   
    //The dot that will be used
    Dot myDot;
   
    set_clips();
   
    //The frame rate regulator
    Timer fps;
   
    //Initialize
    if( init() == false )
    {
        return 1;
    }
   
    //Load the files
    if( load_files() == false )
    {
        return 1;
    }

    //While the user hasn't quit
    while( quit == false )
    {
        //Start the frame timer
        fps.start();
       
        //While there's events to handle
        while( SDL_PollEvent( &event ) )
        {
            //Handle events for the dot
            myDot.move();
           
            //If the user has Xed out the window
            if( event.type == SDL_QUIT )
            {
                //Quit the program
                quit = true;
            }
        }
       
        //Fill the screen white
        SDL_FillRect( screen, &screen->clip_rect, SDL_MapRGB( screen->format, 248, 248, 248 ) );
       
        //Move the dot
        myDot.move();
       
        //Show the dot on the screen
        myDot.show();
       
        //Update the screen
        if( SDL_Flip( screen ) == -1 )
        {
            return 1;   
        }
       
        //Cap the frame rate
        if( fps.get_ticks() < 1000 / FRAMES_PER_SECOND )
        {
            SDL_Delay( ( 1000 / FRAMES_PER_SECOND ) - fps.get_ticks() );
        }
    }
       
    //Clean up
    clean_up();
   
    return 0;   
}

Yeah, I just modified the dot movement Lazy Foo tutorial from that project page so that it moved in a grid and would animate.  It isn't that great and probably has redundancies in it due to that I was just seeing if I could get it to work.
Title: Re: Pokemon Walking Engine
Post by: wildex999 on September 19, 2008, 05:23:19 pm
Wow, all that code for... Ehhem, Well, good luck with it =D
Title: Re: Pokemon Walking Engine
Post by: 4Sword on September 19, 2008, 05:26:38 pm
It just looks like a lot because it is just in one file.  As I get further, I will branch off certain files to include character code and whatnot.  As I said though, some of the code is probably redundant because I just made sure it would work not that it would be efficient; the way I code also is more vertical than horizontal, and a big chunk of that code is for loading the image animations, and another chunk is just SDL drawing to the screen.  It just looks like a lot.

Oh, and it should also be noted that there is a lot of commenting in that which can later be removed.
Title: Re: Pokemon Walking Engine
Post by: wildex999 on September 19, 2008, 05:35:11 pm
You might get past the tapping=faster bug by sepparating the move function into SetMove() and DoMove(). Where SetMove = when pressing the key, and DoMove is called each frame, I'm not too sure, not used to other people's code =P
Title: Re: Pokemon Walking Engine
Post by: 4Sword on September 19, 2008, 05:41:51 pm
Yeah, originally the movement code from the tutorial I was looking at had it so pressing keys would set your velocity and then there would be code that moved you.  I remember it being smoother, but it had diagonal movement.  By setting up my code the way I did, it can't happen because you can only move in one direction from a grid space (or whenever x % 16 == 0 && y % 16 = 0, same thing really).

The SetMove and DoMove methods would probably work out better though because in upcoming code, NPCs will have movement based not on key presses.  Separating the code would just be a better use of space.

But really, lol, I put this together over the course of about a day and a half, it wasn't going to be that good.  I am just happy that I was able to get the animation to work decently, >.<.
Title: Re: Pokemon Walking Engine
Post by: wildex999 on September 19, 2008, 05:44:08 pm
Well, the reason you're getting the speedup when pressing a key, is because the move code is called each time a button is pressed AND after the event check. Sepparating them would mean it could update key's without actually doing any moving, and then move afterwards.
Title: Re: Pokemon Walking Engine
Post by: 4Sword on September 19, 2008, 05:49:12 pm
Ah, thanks.  As I am typing this out, it sounds even to me like sarcasm but I assure you it is not, but until you wrote out that first sentence of your last post, that was what I was not realizing.  I'll get to work on that then.  Realizing the shear power of C++ with at least SDL makes me wish I could have gotten through Game Maker a bit sooner though, lol. 
Title: Re: Pokemon Walking Engine
Post by: wildex999 on September 19, 2008, 05:51:53 pm
C++ is powerful, yet dangerously so =P
Title: Re: Pokemon Walking Engine
Post by: HyperKnight32 on September 19, 2008, 11:00:48 pm
Thanks for the pm, it works fine now :), sounds like you'll be getting the walk bug fixed in no time at all.

If you made one room the size of the pokemon world from blue/red in gamemaker with everything all done and tiled and all required sprites, compared to doing the same in C++ I assume the gamemaker would slow down dramatically but C++ would handle it flawlessly?
Title: Re: Pokemon Walking Engine
Post by: 4Sword on September 19, 2008, 11:12:01 pm
Yeah, setting up a view should not be that difficult but I am not familiar yet with tiling, but I think that it is possible so that the program doesn't tile everything at one but once when you get close to the outskirts of the area.  It is odd to think about it but it kind of feels like Game Maker if Game Maker were to be crammed into "Execute Code" statements, with Game Maker's objects being classes, and having C++ do functions better (arrays  and variable types make it worth it alone).

As for speed, C++ wouldn't have all the extra bulk that Game Maker puts in with it, so it will be smaller.  I don't think that the Pokemon overworld though is one big area as there are areas off the map that crash the game and if you walk through a wall in the original, the tiling messes up and it forgets where you are. 
Title: Re: Pokemon Walking Engine
Post by: 4Sword on September 20, 2008, 04:32:58 pm
Oh, and just to update, I split my movement code back into two parts and it works perfectly now with that.  Right now, I am trying to add a rock object that you can run into which prevents movement.
Title: Re: Pokemon Walking Engine
Post by: Mirby on September 20, 2008, 04:41:07 pm
Make sure it makes the bump SE. Then it will be perfectly accurate!
Title: Re: Pokemon Walking Engine
Post by: 4Sword on September 20, 2008, 04:44:54 pm
Ugh... ripping the sound effects is not so easy nor is it that necessary for any of the real code yet.  I am pretty sure that the bump sound is made when Ash is on a walking frame while his movement is being obstructed.
Title: Re: Pokemon Walking Engine
Post by: Porkchop on September 20, 2008, 04:52:54 pm
I am pretty sure that the bump sound is made when Ash is on a walking frame while his movement is being obstructed.

Pretty much. The sound only plays every stepping frame anyways. So it's like...

Step/Play - Stand - Step/Play - Stand and so on.
Title: Re: Pokemon Walking Engine
Post by: 4Sword on September 23, 2008, 06:09:14 am
Alright, update.  I fixed the previous issue with tapping to go faster and added a Clefairy that follows Ash around in the SDL version of this project which is now located at:

http://www.zfgc.com/index.php#?action=games&sa=view&id=82
http://www.zfgc.com/index.php?action=games&sa=getdownload&id=268

Note: I have not added it yet, but when you idle for a while, the character that follows you (Clefairy) should start facing random directions.  Also, once I add collision events, so of the following stuff may get different - if you are at a corner between two walls and you are facing left with Clefairy facing left, you stop, then you do down, Clefairy's direction will then not change.  Also, in the original games there is a delay for Ash's movement when he tries to go through the following object if he is moving from a stopped position or of some other small value, I'll add this later once I work out collisions.


Title: Re: Pokemon Walking Engine
Post by: Cassyblanca on September 23, 2008, 06:15:39 am
I have to say, 4Sword; you're getting good, and I'm glad to see that SDL and C++ is working out for you.

Good luck in continuing this project, I'm cheering for your C++ version.
Title: Re: Pokemon Walking Engine
Post by: 4Sword on September 23, 2008, 07:27:00 am
Ah, thanks.  It works out fine, but it was kind of funny how long it took me to figure out how to make it so when Clefairy was on Ash's previous grid space that its direction would change to Ash's - the ultimate cause of the problem was that I had a local variable in Clefairy that was the same name as the global variable - I can't believe I didn't see it yesterday when I knew that was exactly what to look for and yet I was unable to find it then.

Looking ahead, ledge jumping should not be that difficult to implement either even with an object that follows Ash because the object that follows Ash has its movement based on Ash's' - i.e. following object is only delayed if Ash is delayed.  Then I could have a variable for x and y offset for drawing manipulated by the distance between the current (or next grid space since ledge doesn't count as a landing space) and previous space to get the displacements.  Clefairy's image displacement could be based around its x and y and its relation to Ash's previous x and y, but meh: I haven't thought all of that out yet, should work though.

But yeah, SDL is pretty cool.
Title: Re: Pokemon Walking Engine
Post by: wildex999 on September 23, 2008, 07:45:38 am
I haven't done any direct code for having objects follow yet, but wouldn't it be simple to jsut make a ghost history of Ash's movement?, so when he moves to the next tile, the object following him mimics the movement he did to get to the previous tile.

I dunno, something like:

struct Ghost
{
int prevt;
short prevdir;
int nextt;
short nextdir;
} ;


Or something? x3
Title: Re: Pokemon Walking Engine
Post by: Moon_child on September 23, 2008, 08:07:00 am
It's good to see this is being made in C++ now. And the SDL library seems to be pretty easy to use. I might try it out too.
Title: Re: Pokemon Walking Engine
Post by: 4Sword on September 23, 2008, 08:11:10 am
I haven't done any direct code for having objects follow yet, but wouldn't it be simple to jsut make a ghost history of Ash's movement?, so when he moves to the next tile, the object following him mimics the movement he did to get to the previous tile.

I dunno, something like:

struct Ghost
{
int prevt;
short prevdir;
int nextt;
short nextdir;
} ;


Or something? x3

The way I was thinking about it is that the following object would just follow and have its code based on positions and not action; as you go when you are not at the leader's previous position and you fix your direction when you make it there if need be.  Ash may also have to refer back to his previous position in some cases.  I think it ends up in the long run to where just basing it on positions cuts down on the number of variables, but meh, I do not know; not sure when structures would fit either in the scheme of things.

I figure I will just work until I hit an obstacle and then think it over.

It's good to see this is being made in C++ now. And the SDL library seems to be pretty easy to use. I might try it out too.

Yeah, I have a C++ assignment due for class at 11:59 PM CST tonight which I should have spent my time on, lol, but compared to all this nonsense, it should be easy enough - just a program with functions and print-outs and I will probably just work on it in class and get it done there. 

The SDL library is pretty easy to use, but I really owe Lazy Foo' Productions and their tutorials for helping me get the concepts.  Once I learned how it was different from what I was doing in Game Maker and how it was similar, crossing over wasn't that difficult.

Title: Re: Pokemon Walking Engine
Post by: Cassyblanca on September 23, 2008, 08:14:12 am
Told you those tutorials would help ;)
Title: Re: Pokemon Walking Engine
Post by: wildex999 on September 23, 2008, 09:08:22 am
Positions? So you keep a vector of variables with previous positions? like
int oldpos[16]; ?

Anyway, If I don't remember wrong, The following character should always copy your last movement. If you move to the Left, and the move down, the one following you should move left, and then move down the next time. I can't see how that is easily done without keeping some kind of history of Ash's movement.
Title: Re: Pokemon Walking Engine
Post by: Mamoruanime on September 23, 2008, 09:11:03 am
Positions? So you keep a vector of variables with previous positions? like
int oldpos[16]; ?

If I'm not mistaken, that's how the actual game did it anyway--- I cant remember too specifically, but I've been inside and out of it XD (ask MiN; we were trying to make pokemon stuffs and it was uber complex), and I believe it just remembers last positions up to a certain point
Title: Re: Pokemon Walking Engine
Post by: wildex999 on September 23, 2008, 11:56:50 am
Finally got a look at the latest download, didn't have a computer to test on before now =P
Anyway, looks good, and seems to work well, but It might just be me, but doesn't it follow too fast? They seem to overlap now and then. And one thing, 700 lines of code? =P lol, Well, I can't say anything, I'm up to 3000-4000~ lines of code, and only have rendering x3
Title: Re: Pokemon Walking Engine
Post by: 4Sword on September 23, 2008, 01:51:29 pm
I've already explained why there are so many lines, and it is not like if you mashed all of what was in a Game Maker program into one code source like you would have any less.  As for it being too quick, you both move at the same speed - I looked at Pokemon Yellow on an actual Game Boy and it seemed to have a little overlap as well. 

Some of that overlap could be handled with an evaluation of depth also, but I haven't included that yet as I thought it wouldn't be necessary.

The code I used for the following object was just:
Code: [Select]
    if (spot_y > ASH_PY)
    {
      spot_y -= 2;
      spot_d = 0;
      anima++;
      return;
    }
    else if (spot_y < ASH_PY)
    {
      anima++;
      spot_d = 1;
      spot_y += 2;
      return;
    }
    else if (spot_x > ASH_PX)
    {
      anima++;
      spot_d = 2;
      spot_x -= 2;
      return;
    }
    else if (spot_x < ASH_PX)
    {
      anima++;
      spot_d = 3;
      spot_x += 2;
      return;
    }
    else
    {
      spot_d = d; 
      anima = 0;
      return;
    }

I haven't used vectors yet as for evaluation I only needed to test components of up, down, left, right, or nothing.  I'll go back later I guess.

Title: Re: Pokemon Walking Engine
Post by: Cassyblanca on September 23, 2008, 01:59:52 pm
Finally got a look at the latest download, didn't have a computer to test on before now =P
Anyway, looks good, and seems to work well, but It might just be me, but doesn't it follow too fast? They seem to overlap now and then. And one thing, 700 lines of code? =P lol, Well, I can't say anything, I'm up to 3000-4000~ lines of code, and only have rendering x3
Bearing in mind the fact that he's still fairly new to C++ and SDL, hasn't taken the time to clean, organize, and optimise his code, that's somewhat reasonable.

Quote from: Mamoruanime date=1222171010
ask MiN; we were trying to make pokemon stuffs and it was uber complex
You mean you were asking me to convert algorithms for determining experience and levelling from the mathematical forms to VB.NET.

On that note; Tim, if you need any help with things such as the experience algorithms, and how to implement them, feel free to ask.
Title: Re: Pokemon Walking Engine
Post by: 4Sword on September 25, 2008, 04:19:41 pm
Yeah, just looking it over, I could simple a few things for the better, but I'll do that once I get all the capabilities out of the game state that I need or whenever the code needs itself to be improved before such capabilities can even exist.

Also, I have added views which is actually pretty easy to do (all you do is draw things relative to a position on the screen).  I will release my next demo though once I get the collision system sorted out.
Title: Re: Pokemon Walking Engine
Post by: Mamoruanime on September 30, 2008, 09:06:34 pm
Quote from: Mamoruanime date=1222171010
ask MiN; we were trying to make pokemon stuffs and it was uber complex
You mean you were asking me to convert algorithms for determining experience and levelling from the mathematical forms to VB.NET.

On that note; Tim, if you need any help with things such as the experience algorithms, and how to implement them, feel free to ask.

lol yes that

Although I forgot that there was a ton of other stuff that I probably never showed you on the pokemon stuffs because I got horribly deterred by it :P

D: that games structure is asd;ajsd;kahsd
Title: Re: Pokemon Walking Engine
Post by: TheDarkJay on September 30, 2008, 09:51:10 pm
Heh, C++...hell to try and make good engines in until you get used to it. Then you start building finite state machines inside finite state machines (admittedly which just makes it all one big fsm, but it sounds cool) and all sorts of craaaazy things without really paying much attention to how far you've come.
Title: Re: Pokemon Walking Engine
Post by: 4Sword on October 08, 2008, 06:30:23 pm
Part of this feels rushed (especially the collision detection), but I thought I would show what I had anyway.  I fixed an error in animation, began using ternary operators ( ?: ), split the file up and cleaned up the code a little, made it so you can change direction without moving, got rid of some of the global variables that were not needed, added a fixed view, etc.

http://www.zfgc.com/index.php?action=games&sa=getdownload&id=283

Also, if anyone wants it, I could probably edit my old Game Maker code so that it would have a following object for that too.
Title: Re: Pokemon Walking Engine
Post by: 4Sword on October 10, 2008, 07:18:30 am
Update: I got bored and even though no one requested it, I went back and made this all into Game Maker.  The code is a little bit sloppy and redundant at parts, but I was trying to make it so the logic in the code itself could be preserved for when I implement this back into C++.

New feature:
- Clefairy follows Ash, even off of ledges in a similar fashion to Pikachu in Pokemon Yellow

http://www.zfgc.com/index.php?action=games&sa=getdownload&id=284
Title: Re: Pokemon Walking Engine
Post by: 4Sword on October 23, 2008, 10:01:45 pm
This isn't an update with anything in it other than a progress update.  I have gotten further, but I still feel as if it is not worth showing yet.  That, and I have been a little busy with my classes at my university.  With this in mind and even though no one has posted in this topic for a while, I am locking this topic.  Hell, I didn't even get a reply for the last update, but meh.

Locked.

Contact Us | Legal | Advertise Here
2013 © ZFGC, All Rights Reserved