Project Eden - 2nd Attempt

[MausBoy]

I got pretty far with my homebrew Project EDEN, but it was turning into a big ugly mess of code, and a lot of the features I envisioned for the game were just not possible. Now that I have a better understanding of what can and can't be done with the VCS, and how to write decent code, I'm trying again from scratch.

 

I've read a lot of people saying that they like to follow the development of homebrew games from start to finish, so I'll keep a log here of daily progress, and hopefully get some good feedback along the way. Please feel free to add a post, even if it's just a "looks good...", it will encourage me to keep at it until this sucker is finished, polished, and in the hands of the people who will appreciate and enjoy it. Suggestions are also extremely appreciated!

 

The Game:

The year is 2074, Earth is toast, and you control EDEN; a ship designed for interstellar travel in order to preserve the human race. You must protect EDEN as it shoots through deep space on it's course to a new life sustaining planet. Along the way you encounter scores of hostile alien races, evil motherships, and nasty asteroid fields. I haven't decided yet if I will want/be able to include the levels where you land on planets to collect supplies, but if so; that too.

 

Day 1:

Designing EDEN

In my previous attempt, the starship EDEN was a player sprite, which are in extremely short supply. So I thought I'd try designing a player ship using only missile0. It's ugly, but functional, and leaves all four player sprites for some nice looking enemies and powerups. I really dislike the flicker, but virtually everything in this game is going to flicker. So you either hit Alt+P in Stella and deal with the choppy movement, or play as is and deal with the flicker. That's just part of dealing with my own and the VCS's limiations I guess.

 

So here is the demo .bin of the first days progress. There is a blocky ship that can move in all directions and fire. I'm considering switching it to a double shot, but that will make the game cheat once in a while, with shots passing through enemies. Yay or nay?

EdenDay1.bin

[Cybergoth]

I've read a lot of people saying that they like to follow the development of homebrew games from start to finish

 

Indeed

[jbanes]

Glad to see you back on the horse! Keep us up to date on your progress.

[gambler172]

Hi Mausboy

Hope to see more.I like Project Eden.And the demo some time ago was reall great.

greetings Walter

[MausBoy]

Thanks for the encouragement guys - Cybergoth I know I need to actually finish a game, hopefully this one is it...I know I've said that before though. This version isn't nearly as pretty, with the blocky ship and single color sprites, but I think it'll be a lot more playable. I'm concentrating on getting a good quality game going this time and skipping the fancy cinema sequences; I'll leave those until last, if there is room, which is the smart way to go.

 

Today I'm doing a "parallax scrolling starfield" for the effect of moving through space at high speeds. I think this looks a lot nicer than the "all scroll at once" starfield I used in the last version. I'll post a demo bin in a few...

 

EDIT : Ok, scratch that, pfpixel dosn't work in the version of bB I'm using, and pfhline/pfvline require way too many cycles to use them to plot a single playfield pixel, blah.

Edited December 15, 2006 by MausBoy

[MausBoy]

Day 2

My God, It's Full Of Stars!

I really need to figure out why pfpixel crashes my game. It only uses 80 cycles versus 200+, so I need to be able to use it...anyway, I thought I'd be clever and make the stars in the background scroll past at different speeds, to give the illusion of depth, but without pfpixel that won't fit.

 

 

Changes/Additions:

 

Added scrolling starfield!

Changed Eden's color to light blue, and score color to yellow.

Now Eden's missile isn't visible unless it is being fired.

 

I don't think I'm done for today so there might be another update. Up next : Something to shoot at.

 

Day 2b

Something To Shoot At

I've added an enemy ship that fires at you. missile collision detection for both ships is working.

 

If anyone wants to contribute some mockups of enemy ships and attack patterns, it would make this a lot better. There can be up to four 8x32 ships, two 16x32, or one 32x64 enemy sprites on screen at once. You can also use two 8x32 and one 16x32 enemy sprites at the same time. They can be single, double (2 rows=1 column), or quad width(4 rows=1 column) as well.

EdenDay2.bin

EdenDay2b.bin

Edited December 15, 2006 by MausBoy

[SeaGtGruff]

I really need to figure out why pfpixel crashes my game.

If you're using a RAM playfield, then pfpixel should work. If you're using a ROM playfield (which the multisprite kernel uses), then pfpixel won't work, because you can't change ROM. So... are you using the multisprite kernel? Also, after this weekend I should be able to get back into modifying bB some more for the Superchip, and I'd like to help batari by contributing stuff like that to the continuing development of bB before he releases version 1.00 (which I'm hoping will be soon now, so I can make it the "de facto" version in my bB tutorial). So maybe I can make a version of the multisprite kernel that allows a RAM playfield?

 

Michael

[MausBoy]

I'm using the standard kernel, 16k rom with superchip, only kernel option is pfheights. Putting in even a single pfpixel command destroys the playfield, resets the nusiz registers, and makes everything flicker like crazy.

 

A multisprite kernel that functions exactly like the standard, except with the extra sprites, would be great. Losing the score is a bummer though. I'd love to see more superchip modifications, but I think the nicest ones would be a higher resolution playfield, and of course multiple instances of pfheights & pfcolors.

 

Something else strange that happens is that if I put any code related to the score in bank 4, the playfield becomes symetrical and both sides scroll inward into the middle of the screen..

Edited December 15, 2006 by MausBoy

[SeaGtGruff]

I'm using the standard kernel,

In that case (as far as I know), pfpixel should work. When I have time later this weekend, I'll look at your source to see if I can tell what's happening.

 

A multisprite kernel that functions exactly like the standard, except with the extra sprites, would be great. Losing the score is a bummer though. I'd love to see more superchip modifications, but I think the nicest ones would be a higher resolution playfield, and of course multiple instances of pfheights & pfcolors.

Multisprite shouldn't have to lose the score, but I think batari made it clear when he first released that kernel that it's probably very buggy and unstable, and is just a preliminary version. On the other hand, having a limited amount of RAM and processor time is a big problem with "canned" kernels, so it may be that adding the new RAM variables for managing the extra player sprites had to take RAM away from other things, such as the score-- which is the sort of thing that Superchip support should help alleviate. As for which sorts of things the Superchip RAM should be used for, I think it should be configurable with set commands, the way that the various kernel_options can be selected-- e.g., set superchip_options hires_playfield, or something like that.

 

Something else strange that happens is that if I put any code related to the score in bank 4, the playfield becomes symetrical and both sides scroll inward into the middle of the screen..

You do run into the weirdest problems! Just kidding, we all do. The weirdest problem I ever ran into (not on the 2600, but in computer programming) was a variable that wouldn't retain its value. I mean, I even did something like this to see what was going on:

 

a = 1
print a

Guess what? Even though there were *no* other statements between those two statements, a was *not* equal to 1! That problem drove me up the wall. I don't remember how I fixed it or worked around it (this must have been about 10 years ago), but I think maybe it ended up being a problem with an array that was being overrun in memory, or some other kind of situation like that where one thing was extending past its boundaries and changing stuff it wasn't supposed to. Even though there were no other statements in between, the computer wasn't doing nothing, because it was doing all sorts of interrupt processing, not to mention having to perform the code that did "a = 1" and the code that did "print a"!

 

Did you post your source? Like I said, I'll look at it later thins weekend.

 

Michael

[SeaGtGruff]

Although you haven't posted your source, I took a quick look at this and did a simple test based on the specifics you mentioned-- the standard kernel rather than the multisprite kernel, 16K, pfheights kernel option (but I didn't use the Superchip). If I'm right, your problem is one of two things: (1) You must put the pfpixel statements in the last bank, just like the playfield statement. And (2) if you use the pfheights kernel option, then you must give the pfheights statement somewhere in your code, and it should come sometime before you make your first call to drawscreen, otherwise drawscreen won't know how high to make the pfpixels, and the screen will roll-- although if you eventually give the pfheights statement, the screen may stop rolling.

 

Michael

[MausBoy]

It's strange that pfpixel statements would need to go in the last bank, pfhline and pfvline can go in any bank with no problems. I did setup pfheights at the start of my program, and the pfpixel commands were in bank4. It's ok though, I'll just not use it in any programs.

[SeaGtGruff]

It's strange that pfpixel statements would need to go in the last bank, pfhline and pfvline can go in any bank with no problems. I did setup pfheights at the start of my program, and the pfpixel commands were in bank4. It's ok though, I'll just not use it in any programs.

Yeah, you're right, so maybe it was the way I wrote my test? Anyway, if you post your source, I'll look at it and see. Or if you don't want to post it "publicly," you can pm it to me if you wish.

 

Michael

[+batari]

It's strange that pfpixel statements would need to go in the last bank, pfhline and pfvline can go in any bank with no problems. I did setup pfheights at the start of my program, and the pfpixel commands were in bank4. It's ok though, I'll just not use it in any programs.

It sounds to me that the "bankswitch" constant isn't being properly defined. It gets defined when the compiler sees "set romsize" with size 8k, 16k or 32k. But if this isn't happening, I wouldn't expect it to compile at all, so I am not totally sure what's up.

 

You could try to to place dim bankswitch=16 at the beginning of your program, though this is kind of a hack.

[+atari2600land]

What happened to the fancy intro from the earlier version?

[MausBoy]

Thanks for the tip Batari, it looks like it worked. So I tried putting in the parallax starfield, and it ended up taking up way more cycles than just the standard pfscroll. It looked nice, but I have to be able to switch between two speeds for each star to not look repetitive, and for the effect to really look nice I'd need those multiple instances of pfcolors with pfheights so that stars that move slower (are farer away) are darker, faster(closer) are brighter.

 

A2600L - That was just a demo stripped from the original rom which was never released to the public. I want to try to get a decent game programmed before I stuff anything like that back into it, especially considering the limitations to one bank of graphic data. If that's taken care of in a future release though, I'll have a whole bank for cinemas and fancy "level X", "Game Over", "Paused" etc screens.

 

MR - thanks for all the help you always offer. I'm glad I got it worked out without sending you source, I want you to use all your free time on that superchip!

Edited December 16, 2006 by MausBoy

[MausBoy]

Day 3

Pirates Of The Milky Way

Now it's a real fight. Things are starting to shape up; most of the game elements are now onscreen.

 

Changes:

 

Added working energy bar, but it uses a ton of cycles. I might have to work out something else.

Collision detection for Eden tweaked, now you can get hit by enemy fire.

Updated enemy AI and fixed screen borders so that ships don't wrap or dissapear.

 

Up Next: Adding explosions and game over screen, lives remaining meter, and the other three enemies that can be on screen at once. That's right, this version can have four enemies on screen at once! Beats the hell out of one.

 

Any suggestions on how to get people to contribute sprites and enemy attack pattern ideas? I don't wanna crosspost, but it seems like most of the people who are looking are people who are busy with their own projects...

EdenDay3.bin

Edited December 16, 2006 by MausBoy

[PressureCooker2600]

extra lifes could be as basic looking as a diamond shape with a different color to make it stand out.......i dont have a good utility on my computer to do any of these ideas.....only got pen and paper

[+Nathan Strum]

Cool looking game.

 

With an enemy ship that big though, I'd want to shoot chunks out of it, rather than just having one shot kill it.

[SeaGtGruff]

With an enemy ship that big though, I'd want to shoot chunks out of it, rather than just having one shot kill it.

Great idea! Or maybe have it so it takes a certain number of shots to destroy it (e.g., with each hit it takes, its color changes slightly to indicate it's getting closer to an explosion), and/or have a "sweet" spot that will destroy the whole ship at once if you can hit it there (e.g., right smack dab on its nose).

 

Michael

[MausBoy]

Cool looking game. With an enemy ship that big though, I'd want to shoot chunks out of it, rather than just having one shot kill it.

I'm glad you like it, I just started so hopefully it will get better. There are much bigger ships that are destroyed piece by piece, and to have room for those large amount of sprites in one bank of ram I'll have to limit animated and changing ship sprites to those large bosses. I want each level to have as many unique ships and sprites as possible.

 

With an enemy ship that big though, I'd want to shoot chunks out of it, rather than just having one shot kill it.

Great idea! Or maybe have it so it takes a certain number of shots to destroy it (e.g., with each hit it takes, its color changes slightly to indicate it's getting closer to an explosion), and/or have a "sweet" spot that will destroy the whole ship at once if you can hit it there (e.g., right smack dab on its nose).

Michael

If there is an update that allows player data in any bank I would definately use that and other game elements a lot more, but if not I want to concentrate on being able to use as much of banks 2 and 3 for unique enemy AI. So I need to save space in bank 4 for all those seperate enemy ship sprites. I know about your method for changing single lines of a sprite but it's over my head.

I'll definately be using color as much as possible to enhance the aesthetics and gameplay, and I like the idea of hot spots, especially for the huge boss ships.

[LS_Dracon]

Horizontal shooter?

Great!

 

Mausboy, what you think to draw 1 bit sprites?

Using some tricks is possible, see image above, the "dive man" of seaquest was made using a single ball!

Just change the size, and position on every line, using a table...

Of course this waste much cicles... but you get a better looking, anyway your spite aren't bad, give a illusion of wings.

[jbanes]

Mausboy, what you think to draw 1 bit sprites?

Using some tricks is possible, see image above, the "dive man" of seaquest was made using a single ball!

Just change the size, and position on every line, using a table...

Batari BASIC's built-in kernal does not allow him to use this trick. That's why he's drawing the ship the using a flickering method.

[+atari2600land]

MausBoy, are you still working on this game? Have any updates?

[MausBoy]

I am still working on this game, and thanks for the interest/concern and the post asking where I've been. I've downloaded bB 1.0 today, so maybe next time you hear from me, it'll be with a bunch of completed games, including this one. Maybe if I can get one on cart, it'll make me enough money to get my friggin home phone turned back on. I only had local service, but Embark charges out the ass even for that. There is prepay landline local phone service here, so if I come up with $70 that I can afford to spend I'll be back to posting on here all the time again. Wish me luck!