For...Next - Design Journal: "Armageddon Complex", minor update

RSS Bot · September 19, 2008

Thought I'd post a new quickie build with progress:

Changes:

- Screen-to-screen array movement is working, thanks to some authoritative help from Nukey Shay and s0c7.

- Built in a drawScreen subroutine to 1)initialize first screen and 2)draw neighboring screens as the player reaches left and right bounds.

- Rewrote my pf object collision function to be generalized for any kind of object

- Created new variables to track the player's pf position for easier use in interactive pf object collisions, thanks to help from SeaGtGruff

- Created a new kind of object called a Wall, although it's not stopping the player just yet. When initialized, it draws a pfvline based on the next three values. Running into it doesn't do anything right now.

- Switched to 32kSC... I know I'll need it.

Next Objectives:

Map Movement

Now that I've learned a little more about how to move the pointer from room to room in my map array, I'm going to try something fancy. I'm going to create a variable called roomsize that will be the first value in any given room. I'm also going to create a variable that points to individual data "objects" in that room (each of which consists of ten values max: an object id, 4 shape flags, and up to 5 unique properties). Then I'm going to create 4 more variables -thank heavens for superchips- that gauge the roomsize of all neighboring rooms (left, right, up and down), so that when a player exits a room, the pointer will know how many lines to move before it will find the correct room to draw. This way, each room in the map array can have as many or as few lines as I want. This will optimize the length of the array for only what needs to be drawn. It will also probably make it easier to write a custom map editor (probably in Flash) that will let me "paint" on map objects and output formatted bB code. Hopefully getting all of this to work now will make it smooth sailing when I'm ready to plug'n'chug on designing/editing the levels.

PF Colors / Heights

It's now clear my graphic geekery is going to get me into a lot of trouble over the course of this project. For instance: the main reason I went with pfheights was so I could create the Teleporter animation without blank lines. I may have to rethink that decision - and maybe even scrap the animation altogether - since I don't seem to be able to store colors and heights in RAM so I can change them from room to room. And The Teleporter's green "beam" occupies a big 22 pixel high row, which means that even if I am able to figure out dynamic pfcolors/heights, I won't be able to draw anything other than elevators in a room that has them. And sprites may have to get involved with these pf objects of mine, to complete the illusion - which kind of defeats much of the purpose of drawing them in the first place. I think I get a lot of juice out of pfcolors/heights, but I'm ready to abandon ship if I need to.

Roaming Monsters

My two monsters are still dumber than dirt, but that's sort of on purpose. I've changed my labels and vars to initalize them as Sprite1 and Sprite2 ratehr than Enemy1 & 2, since all sprites are general purpose unless they have an id assigned to them. Why are they moving in one direction? For the same reason the chicken crossed the road, of course! In my next build, the sprites themselves will disapear, while the monsters they belonged to will continue to track xpos, making them able to move to unseen screens and go about their monster business in private.

Update attached. More soon...

Attached File(s)

AC_sb2.bas.bin ( 32K )

Number of downloads: 0

http://www.atariage.com/forums/index.php?a...;showentry=5290