SOLDIER: The Forgotten Soul

[cjgone]

some times a happy picture helps visualize a tile map ;o


Each tile is 8 tiles, aka 0-7 8-15 16-23 24-31


7-0 +1 = 8 pixels.

[Liazon]

[asdf]

Same here. Usually it's simple enough to give each map a width and height, which you can use to calculate (with x/y coordinates) when the player has reached the edge of the map.

"if you design events based on these coordinates, it makes it almost impossible to make any changes later"
What changes would you be making? I'm not sure what you are trying to do.

[cjgone]

Actually you can use the tile map to set off events.. like as you scroll, check the elements at the edge of the screen to see what is supposed to happen.

[TylerMcL]

alright, I'm really sorry about any confusion... Let me try to clear some things up for you guys :D

Alright, so like in BASIC, you normally have to keep track of your x and y coordinate -- right? This older method can then be used to "trigger" certain events based on their x or y coordinate. (Yes, there are other methods -- i know)
Instead of this beginner's method (yet effective), I am going to use the map itself to trigger events. A certain number (eg. 0000 0001)

What the engine is going to do is distinguish what kind of tile-map "pieces" the player sprite is on top of. The closest thing to keeping track of an x and y coordinate is going to be the offset only when the player is no longer centered on the screen.

So here's what I meant with the whole "not being able to make any changes" statement:

I have not yet designed any bit of how the tile-map is going to fit together. I'm not sure where I want to put trees, or rocks, or roads, or people, or anything. But what I am going to do is create an engine that does not require several different tile-maps. It's just going to be one large tile-map. It is going to remain in the program, then be decompressed in a reserved area of RAM, and then set into the Display memory.

That bit didn't really answer the question whatsoever, so let me try that again :D

I don't want to keep changing the engine for the tile-mapper. I just want to be able to change the tile-map itself. Forget about changing it;s dimensions in the code, just add a loop that checks the corners of the tile-map for a 0000 0000 byte that will signify the edges of the tile-map. It just seems easier for me to be able to edit more often, without the confusion and head-ache.

I hope this terrible explanation helps somewhat

Tell you what -- I'm kinda tied up at the time, but I'll attempt to draw a picture of what I mean later tonight, or first thing tomorrow morning :D

Pictures always help -- right?

[cjgone]

You, as the programmer should know the end of the map. I don't think having a specific tile to signify the border of a map works anyway.

All you can do is have a barricade to keep yourself from walking off the edge.


Not sure what you mean, but you need an x and y coordinate for atleast one corner where everything is relative 2.

[TylerMcL]

...? Of course I can have a specific byte (tile) indicate the border of a tile-map. Data is whatever you make of it. And I freakin say that 0000 0000 is going to signify the border to my tilemap -- why not, right? :P

And I don't have to have an x or a y coordinate for 95% of the time. All you have to do is detect a keypress, and move the sprite and tilemap accordingly. Just simply keep track with a flag for if the sprite is centered or not. If it is not centered, then I'll use sometype of coordinate system to calculate the offset.

This all makes sense, right? ...I hope so...


EDIT:

Let me try a different perspective of explaining.

Including everything above, consider the following:

Once it has been determined that the sprite is no longer centered, set the remaining amount of steps that the player has left before he supposively would "walk" off the screen. Once this number counts down to zero (and you're right next to the wall), don't allow any movement in that direction Simple as that!

[cjgone]

Erm, in Blobby i didn't use an x and y coordinate either ;o

I used what tile was on the edge of the screen and the pixel offset. I think thats what you're doing.


Still I have no idea about your map border but if you can make it work, kudos. ;o

[TylerMcL]

hey everyone! Sorry again i haven't been able to post any progress. :/ I've been really busy with work lately, and I'm waiting to go back to school on the second.

After the first week of school, this project is really going to start making some progress. I want to have the sequel done by the beginning of next year that's my plan!

Thanks again for not hunting me down and killing me for not making much of any progress on the game I've been planning oiut alot of it during my hours at work though. I have some pretty good ideas, along with how I'm going to go about with them

Appreciate all your patience! (no -- I am NOT thinking of discontinuing the game -- just been making some money for a car

[asdf]

I don't think you should really set a deadline for yourself at this point, especially since that is pretty hasty. I don't doubt that you can finish it, but setting deadlines usually only serve to frustrate you or burn you out. :)

A quote from Maarten who wrote The Verdante Forest RPG:

[TylerMcL]

Wow, that were some amazing statements from Maarten! That really helps alot I take back my statement about the timeline then -- great pieces of work/art don't have limits, do they? I'm sure Mozart didn't give himself a due date :P

and asdf, thank you for the piece of code! It helps alot. And I feel dumb for some of my previous statements... Let me get things out, the right way :blush:

Since it would look terrible if I simply had the character stop at the very side of the screen for no apparent reason, I'm going to go about with this, the most easily understood by me What I'm going to do, so that I avoid having the routine constantly return and check the tilemap for the location directly ahead of the player, I'm going to have it check only the very top corners of the tilemap.

This is a terrible explanation, so let me try drawing a terrible picture

[cjgone]

I don't think you even need edge restrictions.

[DarkerLine]

The boulder idea is a good one for other than programming reasons. If there's an arbitrary border the player can't walk past, the player will still want to try. Boulders (or trees, or a wall, or anything appropriate to the location) are an easily visible sign of "map ends here".

[TylerMcL]

yeah, that's what I was how I was kinda planning to end the map. Unlike in this terrible picture that I made on MS Paint I don't want the map to scroll after a certain point... yes -- obviously :)

The purpose of the corner "flags" were just to tell the engine not to scroll anymore. That was a dumb idea though, for obvious reasons. I don't really like having the edges all trees though, it looks kinda funny to me :/

[cjgone]

For the stop scrolling thing, you won't need to do anymore work then drawing your character like usual...

When you move left, lets say you would normally decrement the x cor of your character and the maps to scroll the whole map right?

But when the map hits a certain xcoordinate, stop scrolling the map but continue decrementing the objects xcor...

Dunno what you know about it, but the characters location on the LCD is completely relative to the lcd like:
*pic*

[TylerMcL]

Um, I'm not sure if you were able to read the previous posts or not :/ I decided that I'm going to save myself the giant hastle, and not use x or y coordinates. Just the offset from the center once an "edge" tile is detected a certain amount of spaces ahead Silly kids -- wait.... I am one :P

Silly rabbits (wow, I'm slap-happy to be going back to school soon )

But cjgone, I do understand what you'd meant. Once the "stopper" is detected, just advance the sprite, but don't initiate the tile-mapper routine that shifts the map.

[Liazon]

aren't you going to need x,y coordinates (or a tilemap offset) to do hitdetection?

[cjgone]

Er, x and y is defintely the easiest method.

Only other good way is to do something like

[asdf]

Also, your idea about the four corners won't work if your tilemap is too large. Check the attached picture (if it worked). If none of those bytes are on screen, you'll be wasting a lot of space searching for it! I think using map dimensions are certainly easier, but don't think that there is a right or wrong way! Maybe you'll find some implementation that works better for you, i've just found that for a general tilemap this is the easiest route to go

[TylerMcL]

yeah, like I thought, the corner idea wouldn't really be effective, or worth the time. So like I figured I'd end up doing, I'm just going to have "border" tiles. That should do the job :)

As for hit detection, and events, I'm going to implement it into the sprite placing routine. I'm just going to have it check the tiles that the sprite is going to be under, then act on that. I'm going to use the scan-under method to place the sprite, I'm going to have the routine first check to see if it's even a tile that the user can go on. And if it can, to see how much room it has left on that tile to move before you hit, say, a wall of a store. (Since the roof is there, I want to implement some type of pixel-test in addition to the tile-testing routine. :)

Also, the reason why I'm not designating the tilemap dimensions, is because once all my Soldier games are finished, I'd like to release some type of easy smooth-scrolling routine that would be interchangeable with tilemaps; meaning the user would not have to change anything except for the tiles and the tilemap