InfestedRL - my 7 days roguelike challenge - FAILED

[BethesdaLove]

Maybe this could be helpful if you havent seen it yet?

http://roguebasin.roguelikedevelopment. ... ke_Dev_FAQ

 

[soggie]

I've scoured every article in roguebasin, and after checking out several sources I've managed to create a simple dungeon generator. Not really satisfied with it, but I guess I'll have to make do. I'm failing this 7DRL for sure... 3 more days are needed to put in monsters, AI and polishing. Sigh.

I've tons to write about during the post-mortem.

 

[soggie]

Here's what I've got so far:

 

[Zed]

cool dude

 

[BethesdaLove]

soggie, plz post your scrolling code.
I cant figure out to to center the camera on my dude and scroll...

 

[soggie]

It's official, I've failed my 7DRL challenge. Good thing is, I've learnt a hell lot this time, and have a more matured engine right now.

I'm taking a long look at what went wrong in this week, and the post mortem will be LONG.

Anyway, I have a question:

In the game, I have two ways of moving the character:

1. Press directional key, and character moves one tile
2. Press directional key, and as long as key is held down the character will move in that direction until reaching a wall

Which would be better?

In the first technique, code is much cleaner and easier. All I need is to call an action function and that's it. But in the second technique, it's much harder, with lots of conditional checks in the update function to guess the current state the sprite SHOULD be in.

I initially went for the first, before changing my mind and tried to implement the second (which wasted one whole day).

Ideas?

 

[BethesdaLove]

Are you using SDL?

Than SDL_EnableKeyRepeat() is the one for multiple events polling alongside with single key_down event checks.

Here is my really humble code.

http://pastebin.com/yzzwpPRJ

 

[Zed]

Is LOS blocked by walls etc?

 

[soggie]

Are you using SDL?

Than SDL_EnableKeyRepeat() is the one for multiple events polling alongside with single key_down event checks.

Here is my really humble code.

http://pastebin.com/yzzwpPRJ

Thanks, but in my system its a little more complicated. I am using a simultaneous turn-based system, which means you enter an action, the event loop is blocked while the animation for that action is played, and once the animation is completed the event loop is unblocked. Any events that happen during the block period would be discarded, except for system critical events.

I'm doing something similar to 100rogues actually, in terms of animation/input handling mechanism.

Is LOS blocked by walls etc?

No, I didn't have time to implement LOS. And, from my past experience, using the current LOS seem to be faster since there's only one image to blit.

I'll implement it once I get the time to do so - right now it's pretty low on the priority list.

 

[BethesdaLove]

Well, if the event loop is unblocked after the animation, why not poll for key_down? If the player is still holding it -> next turn + repeat animation?

edit

maybe this could be used?

http://sdl.beuc.net/sdl.wiki/SDL_GetKeyState

 

[soggie]

Well, if the event loop is unblocked after the animation, why not poll for key_down? If the player is still holding it -> next turn + animation?

Yeah, that's what I am going to do.

A better way would be to have a state called next_state though, which stores all actions to be done, and delegate the state handling to the entity itself. This way I would have a much easier method of handling input, and can even switch between the two modes easily.

But I'm more interested in the user interaction part. Since I have lots of long corridors, moving the player one tile at a time seem to be a hassle in my test runs.

What would you prefer, as a player?

 

[BethesdaLove]

Running fast.

 

[soggie]

Added post-mortem:

Post-mortem

 

[BethesdaLove]

Its very nice linking to an image but HOW ABOUT THE SCROLLING CODE?
I place the dude randomly on map and want the camera to center on him. But SDL always shows the [0][0] corner in the upper left and what else fitts on the camera.

 

[soggie]

Its very nice linking to an image but HOW ABOUT THE SCROLLING CODE?
I place the dude randomly on map and want the camera to center on him. But SDL always shows the [0][0] corner in the upper left and what else fitts on the camera.

Opps sorry, I kind of missed your reply.

I'm compiling the source code for release soon, but here's how I did it:

There's a global offset in the scene, which is the player's current pixel location. The camera follows the player (on every update loop, update the camera position to match the player position).

When you render any renderable entity, use this formula:

x = ex + ( gx - cx )
y = ey + ( gy - cy )

ex, ey = the current renderable entity's pixel position
gx, gy = the global offset (player pixel position)
cx, cy = the camera pixel position (top left corner of the camera)

Ideally, you will need to do this instead:

x = ex + ( gx - cx ) - ( player entity sprite width / 2 )
y = ey + ( gy - cy ) - ( player entity sprite height / 2 )

to get a perfectly centered player character.

This works for me.

I'm not sure what you meant by SDL showing [0][0] for your camera code. Maybe you're getting the SCREEN pixel location rather than the WORLD pixel location?

How do you store your entities? On a 2D tile array? BSP Tree? Scene graph?

 

[BethesdaLove]

Eh, I can do math, thankfully =P.
But I can barely code...

struct tile
{
int z;
SDL_Surface *terrain_tile;
character *agent;
};

tile map[MAPWIDTH/TILESIZE][MAPHEIGTH/TILESIZE];

screen = SDL_SetVideoMode( CAMERAWIDTH, CAMERAHEIGTH, 0, SDL_SWSURFACE );
...
SDL_Flip(screen)
...

Now before the Flip, I blit the whole map with muddy_road_1 and place the player in some random coordinates. When the window shows, I always see the map[0][0] tile in the upperleft corner. And I cant figure out how to force SDL to show something different. If I knew I could do the scrolling.

Here is the whole code. Dont laugh. set_camera() is not done was a copy-paste, the whole code is done without thinking, like how to store entities and so on. I just started writing "stuff"...
http://pastebin.com/S6Z7ZZ2h

 

[soggie]

SDL_Rect dest_rect;
                dest_rect.x = x*TILEWIDTH;
                dest_rect.y = y*TILEHEIGHT;
                if (SDL_BlitSurface(source, 0, destination, &dest_rect)==-1)

This part seems strange. You are blitting to SCREEN coordinates and not WORLD coordinates. See my previous formula for how to calculate the WORLD coordinates to blit to.

 

[BethesdaLove]

I am blitting to world coordinates. If I make the screen the size of the world, than all tiles are working and showing. So the blitting works. Its just that the camera is showing me the top left corner. Maybe I am not understanding something in how blitting or fliping works...
Ill wait for source.

 

[soggie]

Did you update your camera to follow the player position on every frame? I can't access your pastebin source anymore so I'm just firing off guesses.

Here's the source code:

infested+gore.zip

Go to gore.scenes.topdowntilemap and look at the Camera code. I use a lot of OO here so you might need to do a fair bit of backtracking, but ask here and I'll do my best to answer anything.

 

[BethesdaLove]

2 mb , 2092977 bytes. Winrar says: Unexpected end of archive.
Pastebin works for me. Here is a different one http://pastebin.ca/1927742
Wait a min, you arent using SDL, are you?

 

[soggie]

Try downloading again.

I'm using pygame, which is a python wrapper around SDL. The commands should be similar, even though the function names might not be.

EDIT:

Found the problem. You have a camera but you never update it's position. What you should have done is add a line in draw( ) to update the camera's position so that it is centered on the player's position.

After that, use the global offset formula and you should be good to go.

One advise - your render code is tied too tightly to your input processing code. They should be separated.

 

[BethesdaLove]

Archive still not working.
And, hehe, I dont know how to update the cameras position...

edit

Oh, Jesus, lol, I think I just understood that I actually dont have a problem except for my empty head. I dont have to move the camerascreen, I have to simply "move" (blit) the required tiles onto my camerascreen. :facepalm:

 

[soggie]

Okay, your code needs a fair bit of rewrite to make it work properly. I'll blog a step-by-step guide to writing the camera on my blog tomorrow. Need to sleep now as I'm flying to Bangkok in 8 hours.

 

[BethesdaLove]

My code is garbage man, even I see it, it will need 10 rewrites.
You dont need to bother with it.