2005 Stella Programmer's Contest

[mos6507]

2005 Stella Programmer's Contest

 

 

 

$1,500 total in cash prizes.

 

Entries Begin: August 11, 2005

Entry deadline: July 1, 2006

Awards Announced: August 1, 2006

 

The 2005 Stella Programmer's Contest is comprised of two categories:

 

"Supercharger Superstar" - $1,000 Grand Prize

 

Background:

 

Ever since the creation of Stellalist in late 1996, the hope was not just to create new games that could be put on cart, but to see what the community could do with the extra RAM in the Supercharger. So far, developers have preferred to develop traditional games on 4K carts. The goal of the "Supercharger Superstar" contest is to sponsor the creation of Starpath Supercharger games.

Rules:

 

Entries into this category must utilize the internal RAM in the Supercharger. Any size that will fit into the Supercharger is acceptable. The game must not be able to run from a regular cartridge.

 

Game development must occur in an open environment. Sourcecode must be shared with the list in order for the final game to be entered into the contest. Reusable innovative techniques developed by the programmer must be allowed to be used by other contestants and vice versa. The intention is to improve the overall state of the art of 2600 development. The game design and execution will matter more than the individual code snippets.

 

Contest entries must be significantly different in conception from eachother, and not traceable back to a previously released homebrew or disassembled game. This will prevent one contestant merely hacking or cloning any other game.

In the case of no valid entries, this prize will rollover into the following year's contest.

 

Desired Qualities (some of these may conflict):

 

-Originality

-Expansiveness of the game world (Multiloads)

-Nontraditional controllers (driving controllers, keypads)

-AtariVox support

-2-player or 4-player multiplayer

-Bidirectional PC Interfacing

 

"Best of Batari BASIC" - $500 Grand Prize

 

Background:

Batari BASIC lowers the barrier of entry to first-time 2600 programmers. This contest should bring in a new crop of programmers into the homebrew scene.

Rules:

 

-Contestants must have never published a homebrew game before.

 

-Entries into this category must author games using the Batari BASIC framework.

-The game can be as large and as feature-rich as Batari BASIC allows. This includes any future enhancements to Batari BASIC between now and the entry deadline.

-Contest entries must be significantly different in conception from eachother.

 

Desired Qualities (some of these may conflict):

-Originality

-Overcoming known Batari BASIC limitations

 

 

How to get started? Join the Stella mailing list and introduce yourself.

 

More details and bonus prizes TBD.

 

 

 

 

http://thedig.dyndns.org/?action=contest.details

[supercat]

Too bad I entered SDI into the minigame competition; otherwise it'd be a good basis for a full-fledged SuperCharger game. Actually, it uses a number of techniques I've not seen used before on the SC, with IMHO a pretty good level of success.

[+batari]

Too bad I entered SDI into the minigame competition; otherwise it'd be a good basis for a full-fledged SuperCharger game.  Actually, it uses a number of techniques I've not seen used before on the SC, with IMHO a pretty good level of success.

909611[/snapback]

I don't think that entrance in one contest necessarily rules out its eligibility in another... Or did I miss something from the rules?

[supercat]

I don't think that entrance in one contest necessarily rules out its eligibility in another... Or did I miss something from the rules?

909714[/snapback]

 

How do you interpret "Contest entries must be significantly different in conception from eachother, and not traceable back to a previously released homebrew or disassembled game."?

[+batari]

I don't think that entrance in one contest necessarily rules out its eligibility in another... Or did I miss something from the rules?

909714[/snapback]

 

How do you interpret "Contest entries must be significantly different in conception from eachother, and not traceable back to a previously released homebrew or disassembled game."?

909726[/snapback]

By "previously released" I assume that means it was sold... I mean, you could release this game on a cassette tape and sell to Supercharger owners, but you didn't and presumably aren't, so to me that means it was never really released.

 

I think the idea here is that, for instance, you aren't allowed to take some game that was sold on a cart and improve upon it by using the Supercharger's RAM.

 

Though I could be wrong - the actual intepretation is up to Glenn.

[mos6507]

I think the idea here is that, for instance, you aren't allowed to take some game that was sold on a cart and improve upon it by using the Supercharger's RAM.

Though I could be wrong - the actual intepretation is up to Glenn.

 

No, that's a little too convenient. You can carry over some programming techniques but it would have to qualify as a completely different game. Like the difference between Adventure, Haunted House, and Superman or the difference between Solaris and Radar Lock, or Raiders and E.T.

 

The Supercharger contest is going to last a whole year so there is no reason not to start whole new games.

[Atari-Jess]

Might I suggest that all batari BASIC games not include any ASM editing that

the game must be made entirely from bB and no extra kernals/etc other than

what is built in to batari BASIC?

 

If you can code ASM, maybe you shouldn't be entering the bB contest

(by this I don't mean, just because you can code in asm, don't enter this contest. Just, if you can, don't adjust your bB code at the ASM level)

 

We can wait for Batari to create a "contest edition" bB and then it must use

code created with that particular edition.

 

/justthrowinideas

Edited August 12, 2005 by Atari-Jess

[potatohead]

Might I suggest that all batari BASIC games not include any ASM editing that

the game must be made entirely from bB and no extra kernals/etc other than

what is built in to batari BASIC?

 

If you can code ASM, maybe you shouldn't be entering the bB contest

(by this I don't mean, just because you can code in asm, don't enter this contest. Just, if you can, don't adjust your bB code at the ASM level)

 

We can wait for Batari to create a "contest edition" bB and then it must use

code created with that particular edition.

 

/justthrowinideas

909786[/snapback]

 

I personally am not in favor of that idea. The best bb games are going to be a mix of bb and ASM, IMHO. Besides, with a year learning some 6502 assembly is doable. That's the beauty of bb really. The assembly can be taken very small steps at a time.

 

First to save a little space, then to get things done faster, then to tweak the kernel, etc...

[mos6507]

This is really different from the minigame competition.

 

I'll think about these restrictions but I want to reward people for learning. Unless I

change the deadline, you all have a whole year. bB itself will evolve also.

 

I'm looking at bBasic as a rapid prototyping tool, not as an end in itself unless that is as far as certain programmers can go with it.

 

Right now my mindset is if I watch the evolution of a game from when it was 100% bB to 10% bB I think I'd still classify it as a bB entry even though you might not consider it a bB game. But only for programmers who are entering into asm for the first time.

 

I don't think seasoned coders should enter the bB contest and if it looks like they are, I'll try to steer them towards the Supercharger contest instead. After all, the purse is twice as big there. I am not going to let someone plop a finished game into the contest right at the deadline that is 10% bB. I want to see the games evolve over time.

 

The degree to which a programmer improves his skills and improves the game will factor into the judging.

[supercat]

One thing which might encourage more sharing of code would be if, rather than simply awarding a prize to the best game, the prize was subdivided among various people whose efforts were useful to the game. That way, even people who might not expect to win the overall contest might be encouraged to contribute kernels, music, etc. which other people could use in the hopes that those other people might win.

[SeaGtGruff]

One thing which might encourage more sharing of code would be if, rather than simply awarding a prize to the best game, the prize was subdivided among various people whose efforts were useful to the game.  That way, even people who might not expect to win the overall contest might be encouraged to contribute kernels, music, etc. which other people could use in the hopes that those other people might win.

912032[/snapback]

 

That's an interesting concept! I think it would be great to have people team up on games, even if they weren't entering the games into a contest. For example, I've always been more focused on graphics than sound, and I'm working on a couple of games myself, but right now neither one of them has any sounds whatsoever. And even though I used to play the Atari all night long with the sound turned off (so as not to disturb my parents!), a game without any sound is only half as good as it might be. Today's games are created by teams, anyway, unlike the old days when a programmer usually created a game all by himself or herself. It makes sense to have at least two people working on a game-- one to design the graphics, and the other to design the soundtrack.

 

Michael Rideout

[potatohead]

This could be done informally too.

 

Just make a team and go for it, or offer to help out on a project in process. The community aspect of this whole thing would probably keep folks honest. (Or forever be in the hall of shame !)

[vdub_bobby]

Could somebody point me to some info about how to program for the SC? I've done a little searching on [stella], to no avail.

[mos6507]

Could somebody point me to some info about how to program for the SC?  I've done a little searching on [stella], to no avail.

912563[/snapback]

 

There is scattered info out there but nothing truly newbie-friendly.

 

Most of us cut our teeth on 2600 programming with a great program called "How to Draw a Playfield" that Nick Bensema drew up. It didn't do very much, but it was enough to get a blank template up and running that would maintain a stable video frame.

 

I've solicited Bob Colbert to come up with something similar for the Supercharger, a simple 6K program that can be used as a starting point, and a simple multiload program, and some tutorial materials to go along with it.

 

I would also like to have some new DASM macros and other snippets to help simplify SC coding, making the sourcecode more readable. The raw header stuff in particular that goes at the end of a typical Supercharger sourcecode file is very cryptic. And a macro could make cart RAM writes look more conventional.

[mos6507]

That's an interesting concept! I think it would be great to have people team up on games, even if they weren't entering the games into a contest. For example, I've always been more focused on graphics than sound, and I'm working on a couple of games myself, but right now neither one of them has any sounds whatsoever.

 

The team aspect really becomes useful with multiload games.

 

If you wanted to write a game with a lot of mazes or other kinds of levels in it, then the level design can be farmed off to someone else like yourself who is more graphically inclined. Once the tools improve for making Supercharger ROMs I think it will be possible to create easy level editors for new games so that artistic types can make levels without worrying too much about programming. This would also open up a "modding" community way beyond what we've seen to date with hacks.

[mos6507]

One thing which might encourage more sharing of code would be if, rather than simply awarding a prize to the best game, the prize was subdivided among various people whose efforts were useful to the game.  That way, even people who might not expect to win the overall contest might be encouraged to contribute kernels, music, etc. which other people could use in the hopes that those other people might win.

912032[/snapback]

 

 

It's too hard to establish "credit" in that case. There can only be one official contestant per title. I'm sending the check to that person, who can then decide if and how to split it up.

 

In an open-source competition everyone is free to "steal" from everyone else so in theory it levels the playing field. The same person who takes a routine out of your game could wind up having one of their routines taken in turn. For those who do nothing but glue together code from others, well, they still have to turn it into a game that is actually FUN.

 

It's really all for the greater good.

 

By the time the contest is over I should have some 2nd and 3rd prizes. They probably won't be as good as cash, though.

 

I could have just made the $500 be a 2nd prize for the Supercharger contest but I wanted to create two levels so more jr. programmers could have a chance to enter so I put in the bBasic category.

[EricBall]

Just to announce that Glenn's extremely generous prize has guilted me into restarting my long dormant Lode Runner-esque game for the SuperCharger. I only hope that other VCS programmers will take up the challenge and put mine entry to shame.

 

In the interests of open-source development, I will document my progress (along with source code) in my AA Blog. I will also gladly answer any comments posted to my blog.

 

For those programmers interested in SuperCharger programming, I would encourage you to see the Cuttle Cart manual starting on page 15.

Edited August 20, 2005 by EricBall

[mos6507]

I thought this would be the most appropriate place to psot this.

 

I have a Supercharger with the write-protect switch mod installed that I haven't needed since I acquired a Cuttle Cart 1.

 

I'm offering to give this away to the first person who convinces me they are going to try to write a game for the contest using it.

 

Please PM me.

[mos6507]

I'm bumping up this thread to remind people about the contest.

 

So far we appear to have two Supercharger entries, Prince of Persia and Leprechaun.

 

I don't know of any "official" Batari Basic entries yet.

 

What I'd like to do is have people formally message me if they want their game entered into the contest and I will update my website accordingly. It can be a work-in-progress up to the last minute, but I still want to have a list to go by so I can track progress.

 

Thanks.

[neotokeo2001]

My Batari Basic entry won't be "official" for a few months.

[supercat]

I've still not decided exactly what I want to do, though I do have some ideas. A question, though: how should a games that requires loading each level be handled? Assume, hypothetically, that there are 16 levels of 256 bytes each.

 

-1- Have one load file containing the game and then one 256-byte load file for each level, stored on separate tracks on a CD with some silence between, using consecutive IDs for the level files.

 

-2- As above, but using the same ID for all the level files; if the wrong one is loaded, jump back into the loader immediately to grab the next track.

 

-3- Have one load file containing the game and first level, and then have two 2048-byte load files, one for levels 1-8 and one for levels 9-16. Only 256 bytes would actually be used each time the file was loaded (the game would use the 2K as scratchpad after grabbing the level data from it). Assign these files consecutive IDs.

 

-4- As above, but assigning the same ID (reload if the wrong file is grabbed).

 

-5- Use a custom load routine and data format, and just store a repeating stream of data containing all of the levels (with enough embedded header information to allow for starting at any point).

 

On a real SuperCharger, I would think it would be most convenient to have a CD which just kept repeating the level data over and over again. This could be left running while the user plays the game. If the game wanted to load level 3 when the CD is on level 6, however, the Supercharger would show an annoying "REWIND TAPE" message if unique IDs were used for each load portion. Using the same ID would avoid that message, but would cause the game to repeatedly do the barn-door load animation. Further, I don't know how emulators or the CC2 handle such issues.

 

Anyone have any thoughts?

[supercat]

One notion I've pondered that might be interesting with a real SuperCharger, but I don't know whether anyone would be interested, would be encoding data in such a way that it could be accessed during gameplay. Some back-of-envelope calculations suggest that--assuming the SuperCharger was being fed CD-quality audio--it should be possible to encode about 15 simultaneous data streams of one byte/frame that could be read at a processing cost of about 20 scan lines/frame. The video would have to run in sync with the audio, so switching data streams would require outputting frames that were shorter or longer than normal (say 261 or 263 lines) until the proper channel was at the right part of the frame.

 

A 60 bytes/second data rate isn't all that great, but if it was achieved during gameplay it would allow for some interesting possibilities. Anyone think that's a cool concept, or am I just crazy? Or both?

[Thomas Jentzsch]

A 60 bytes/second data rate isn't all that great, but if it was achieved during gameplay it would allow for some interesting possibilities.  Anyone think that's a cool concept, or am I just crazy?  Or both?

Sounds cool, but honestly, I don't exactly understand it.

 

60 Bytes/second? Might be enough data for an audio driver?

[supercat]

60 Bytes/second? Might be enough data for an audio driver?

1011229[/snapback]

 

Would suffice for a music driver, but might be more interesting for a "rails scroller" in the style of River Raid or Reindeer Runner. An River-raid-style game could have deliberately-designed enemy formations, etc. while Reindeer Runner could have levels of almost unlimited length.

[vdub_bobby]

Would suffice for a music driver, but might be more interesting for a "rails scroller" in the style of River Raid or Reindeer Runner.  An River-raid-style game could have deliberately-designed enemy formations, etc. while Reindeer Runner could have levels of almost unlimited length.

That would be cool. Do you know how hard it was to design, test, and fine-tune the levels in there already? I shudder thinking about levels of "unlimited" length.