Looking for someone to create 2600 homebrew for my movie

[AaronV]

Hi,

 

I am a filmmaker and big fan of the 2600. I'm looking for someone who would be interested in programming a game based on my film. I have tinkered with bitari Basic and feel like someone who is familiar with it could crank my game out pretty quickly. I'm certainly looking to pay someone to do this and I have a working version of the game that I made using Clickteam Fusion. I just feel like it would be a really cool way to promote my film by having an actual 2600 companion game made of it. If you have interest, please let me know.

 

Thanks,

Aaron

[Andromeda Stardust]

Hi,

 

I am a filmmaker and big fan of the 2600. I'm looking for someone who would be interested in programming a game based on my film. I have tinkered with bitari Basic and feel like someone who is familiar with it could crank my game out pretty quickly. I'm certainly looking to pay someone to do this and I have a working version of the game that I made using Clickteam Fusion. I just feel like it would be a really cool way to promote my film by having an actual 2600 companion game made of it. If you have interest, please let me know.

 

Thanks,

Aaron

Most homebrew programmers make games out of love for the hobby and a desire to make games. You may have trouble finding someone here who will work for commission. Also existing games are not so easily converted to Atari VCS. I recommend picking up a copy and reading "Racing the Beam" to get an idea, in layman's terms, of practical limitations for programming on the VCS.

 

Neat idea though. Mind telling us what the movie is about?

[+Andrew Davie]

Neat idea though. Mind telling us what the movie is about?

 

My guess is a movie about writing a '2600 game for a guy making a movie about writing a '2600 game for a guy... etc.

[AaronV]

Most homebrew programmers make games out of love for the hobby and a desire to make games. You may have trouble finding someone here who will work for commission. Also existing games are not so easily converted to Atari VCS. I recommend picking up a copy and reading "Racing the Beam" to get an idea, in layman's terms, of practical limitations for programming on the VCS.

 

Neat idea though. Mind telling us what the movie is about?

Sounds like a perfect situation to me - getting paid to do a hobby you love! I will check out the book. Thanks.

[AaronV]

 

My guess is a movie about writing a '2600 game for a guy making a movie about writing a '2600 game for a guy... etc.

You've just entered The Twilight Zone........

[+5-11under]

Personally I don't have time for this, but I'm sure there are some who might be interested. Some additional details might be helpful, such as general gameplay idea, timeframe, reward, link to other game you made, whatever other information you have.

[Mountain King]

Time frame might be a factor. A similar situation happened a few years ago, you may have heard about it, with a movie called E.T. The Extra Terrestrial. Even with Atari's best programmer on the job, it still didn't end well.

Edited February 11, 2016 by Mountain King

[Andromeda Stardust]

Some homebrews often spend several years in the WIP / Public beta process before they're finished and released in the AA store. Most commercial releases back in the day took a few months to complete and the only beta testing going on, if any, was done by fellow programmers.

[+Random Terrain]

. . . and the only beta testing going on, if any, was done by fellow programmers.

Is 1982 considered "back in the day" or is "back in the day" farther back?

 

youtu.be/os2ZZF4JWNw?t=4m31s

[Andromeda Stardust]

 

Is 1982 considered "back in the day" or is "back in the day" farther back?

 

youtu.be/os2ZZF4JWNw?t=4m31s

I was still in diapers in 1982 when Atlantis came out so I dunno. I guess that does qualify as "back in the day" since I have no memories from then. Good video, very educational.

[+KaeruYojimbo]

Sounds like a perfect situation to me - getting paid to do a hobby you love! I will check out the book. Thanks.

 

Maybe for some, but making someone else's idea while trying to meet someone else's deadline sounds kinda like a job to me.

 

Sharing your gameplay ideas or your finished game would be helpful in determining if your idea would be easy or even possible on the 2600 and if it could be done with batari basic or if it would have to be done in assembly.

[AaronV]

 

Maybe for some, but making someone else's idea while trying to meet someone else's deadline sounds kinda like a job to me.

 

Sharing your gameplay ideas or your finished game would be helpful in determining if your idea would be easy or even possible on the 2600 and if it could be done with batari basic or if it would have to be done in assembly.

Thanks to all of you for your insights. To be clear - I'm not expecting anyone to make Pitfall and I certainly not looking to put anyone under the demands and pressure it took to release a 2600 game back in the day. I'd just really love to play my game on the 2600 and I think it would be a excellent companion piece to the movie (and a fun 2600 game!!) In my limited work with batari it seems to me my game could be created without presenting too much of a challenge if they are a regular user of the program.

 

The gameplay - Two levels.

 

Level one - a non scrolling side shooter (Outlaw style screen layout) where you have only 25 shots to fire at targets on the opposite side of the screen. There is a vertically moving enemy between you and the targets. If you hit a target a reward is ejected toward you from the target and you must catch it to collect the reward. If the reward hits the enemy then the enemy collects the reward. If you hit the enemy with your shot the enemy fires back at you and if you are hit by the enemy shot you lose 5 shots. Once you use all of your shots that level ends. The amount of rewards caught by you and by the enemy are displayed on a screen before going to the next level. If you caught no rewards the game is over.

 

Level two - a non scrolling top down horizontal shooter (Carnival style screen layout). You now shoot your rewards towards the top of the screen trying to hit three "Carnival style" horizontal scrolling rows of prizes. Again the enemy is also moving horizontally between you and the prizes. If you hit the enemy you lose all the prizes you have hit up to that point and the enemy will fire his rewards at you which also results in a loss of prizes if you are hit. The prizes are spaced out so that more valuable ones are on the back two rows making them harder to hit, the front row is mostly low value prizes - think bronze, silver and gold bars. As you hit prizes your score is tabulated and when you run out of rewards to shoot the game ends.

 

As I mentioned, if anyone is serious about this I have a completed game that you can play on a PC that I can send to you as a reference.

 

Thanks!

[+KaeruYojimbo]

Sounds doable. One consideration would be the number of objects on screen. By default the 2600 can only display 2 sprites onscreen at a time. It's possible to work around this by "re-using" those 2 sprites in different positions, which can be done to an extent in batari basic, but you would be limited to single color sprites and you might not be able to get as many targets in your rows as you'd like. Another option would be to use playfield graphics for the targets, but you would be limited to blocks.

[Andromeda Stardust]

Sounds doable. One consideration would be the number of objects on screen. By default the 2600 can only display 2 sprites onscreen at a time. It's possible to work around this by "re-using" those 2 sprites in different positions, which can be done to an extent in batari basic, but you would be limited to single color sprites and you might not be able to get as many targets in your rows as you'd like. Another option would be to use playfield graphics for the targets, but you would be limited to blocks.

 

For the target shoot "carnival" thing, it is definitely possible to have rows of objects onscreen. You can have up to six objects across the screen evenly spaced using the hardware sprite replication on player 0 and player 1 sprites. You can do more than that through the use of flicker but I'm not going there. Assuming your character is on the bottom shooting up, you could blast bullets through multiple rows of sprites moving at different speeds or directions. But part of the problem is coding issue. The game has to remember which sprites have been shot by storing a bit in VCS RAM. This is difficult as the VCS only has 128 bytes [!] of memory available, assuming you are using standard bankswitching. Another issue is when the bullet or projectile has a collision with your target object, suppose you are using sprite replication to duplicate the object 3 times. Suppose you have the following senario:

 

[p0] [p0] [p0] <---

[p1] [p1] [p1] --->

[p0] [p0] [p0] <---

:

:

:

player

 

The hardware will detect a collision between the missile sprite (assuming you are using missles for your bullets) and player 0, but there is no indication of which of the three player 0 sprites made collision with the missile. In order to calculate it, your program will need to compare the offset of the P0 sprite (first copy) to the offset of your missile. From there you can deduce which object has been hit and change the sprite attribute to display two copies instead of three, far spaced or close spaced. But it gets trickier. If the leftmost sprite was hit, then you have to change the X coordinate offset to display the two player sprites in the 2nd and 3rd positions. There is a limited amount of CPU cycles you can use between screen refreshes, and you have to perform and manage said calculations on each row of sprite objects. If your routine uses too many CPU cycles during the overscan area, the Vblank will be delayed adding extra scanlines to the display, potentially causing the screen to jump or roll, or worse, completely black out the picture for up to several seconds [out of range] in the case of some digital displays. You will find as you add more stuff to your kernel, you will quickly run out of CPU cycles and RAM while trying to manage objects onscreen. Most game consoles have some sort of video buffer that handles objects onscreen in a special GPU memory area. This would typically be updated once every frame. The TIA graphics must be updated manually every scanline, and there is a finite amount of resources and CPU cycles to change objects with each passing of the CRT beam. For asymmetric playfields, the TIA playfield graphics must be updated twice per scanline, making your game even more strapped for resources. The Atari was designed in 1977 to play Combat and Pong. Only through the use of creative programming tricks over the years, has the VCS been proven capable of so much more...

[+KaeruYojimbo]

The hardware will detect a collision between the missile sprite (assuming you are using missles for your bullets) and player 0, but there is no indication of which of the three player 0 sprites made collision with the missile. In order to calculate it, your program will need to compare the offset of the P0 sprite (first copy) to the offset of your missile. From there you can deduce which object has been hit and change the sprite attribute to display two copies instead of three, far spaced or close spaced. But it gets trickier. If the leftmost sprite was hit, then you have to change the X coordinate offset to display the two player sprites in the 2nd and 3rd positions. There is a limited amount of CPU cycles you can use between screen refreshes, and you have to perform and manage said calculations on each row of sprite objects. If your routine uses too many CPU cycles during the overscan area, the Vblank will be delayed adding extra scanlines to the display, potentially causing the screen to jump or roll, or worse, completely black out the picture for up to several seconds [out of range] in the case of some digital displays. You will find as you add more stuff to your kernel, you will quickly run out of CPU cycles and RAM while trying to manage objects onscreen.

 

I've actually done this for the Galactopus sequel I'm working on. One problem with doing rows of 6 is that batari basic only allows replication of player1, so there would be constant flicker (which is why I stuck to rows of 3).

[Andromeda Stardust]

 

I've actually done this for the Galactopus sequel I'm working on. One problem with doing rows of 6 is that batari basic only allows replication of player1, so there would be constant flicker (which is why I stuck to rows of 3).

Yes, Batari Basic kernel has additional limitations on top of ASM. I was suggesting what is possible on real hardware, not how to program it. I wish I had the programming skills you guys do.

[+KaeruYojimbo]

Yes, Batari Basic kernel has additional limitations on top of ASM. I was suggesting what is possible on real hardware, not how to program it. I wish I had the programming skills you guys do.

 

I program like I play bass: I'm just good enough to make the ideas in my head happen. I just want to get some potential issues of doing a game like this in batari basic out there so the OP can decide what options might work best for him.

[Andromeda Stardust]

 

I program like I play bass: I'm just good enough to make the ideas in my head happen. I just want to get some potential issues of doing a game like this in batari basic out there so the OP can decide what options might work best for him.

Cool. I have a J-Bass but I don't really play much. It is very relaxing to listen to the "thud" sounds from the amp, and the large strings are much gentler on my fingers than my steel string acoustic.

 

I think the biggest roadblock to me regarding programming is the syntax. I have an idea what I want my sprite or character to do but I don't quite understand what commands to use and how to express myself in ways the computer can understand. And yes, I definitely understand binary, hex, and the mathematics involved with moving a pixel around on screen. I used to code my own games on a TI-83 plus calculator to entertain myself during study hall in high school. The teacher finally had to confiscate my calculator because I wasn't doing my homework...

[+KaeruYojimbo]

I think the biggest roadblock to me regarding programming is the syntax.

 

Some programming languages are definitely easier for me to wrap my head around than others. Java is supposed to be super easy, but whenever I look at Java code, it just looks like someone typed what they wanted the program to do but put periods in weird places. On the other hand, PHP made sense to me from day one and even though I've never learned Python or Perl, I can look at code and follow what's going on for the most part.

 

Back to the original topic. For level one, there would be some limiting factors to the number of targets as well. The 2600 can make horizontal duplicates of objects, but not vertical. Through sprite re-positioning, batari basic can give you a total of 6 objects. So you could have 1 for the player, one for the enemy and then 4 targets. Alternately, there's no limit to how tall a sprite can be, so what appear to be individual targets could just be one sprite the height of the entire screen. The trade-off being they wouldn't disappear individually when hit.

[AaronV]

 

Some programming languages are definitely easier for me to wrap my head around than others. Java is supposed to be super easy, but whenever I look at Java code, it just looks like someone typed what they wanted the program to do but put periods in weird places. On the other hand, PHP made sense to me from day one and even though I've never learned Python or Perl, I can look at code and follow what's going on for the most part.

 

Back to the original topic. For level one, there would be some limiting factors to the number of targets as well. The 2600 can make horizontal duplicates of objects, but not vertical. Through sprite re-positioning, batari basic can give you a total of 6 objects. So you could have 1 for the player, one for the enemy and then 4 targets. Alternately, there's no limit to how tall a sprite can be, so what appear to be individual targets could just be one sprite the height of the entire screen. The trade-off being they wouldn't disappear individually when hit.

If this is helpful - here is link to a screenshot from the game I made - Level 1. I certainly realize it can't look exactly like this on the 2600. I'd prefer if the character sprites are multi colored like Pitfall Harry but not 100% necessary (I included a link to a pic of my ideal player 2600 sprite too). It's very interesting reading about coding methodology you could use to accomplish things in batari.

 

http://www.videoinformationsystem.com/sprite.jpg

http://www.videoinformationsystem.com/screenshot1.jpg

[AaronV]

 

I program like I play bass: I'm just good enough to make the ideas in my head happen. I just want to get some potential issues of doing a game like this in batari basic out there so the OP can decide what options might work best for him.

Wow - I just played Galactopus on my Harmony, if the game had the opposite orientation it already plays very much like my level one - the Galactopus returns a reward when hit and those vertical lines that block you from hitting G'Pus serve the same purpose as my enemy character, only they are just much bigger and harder to miss. Fun game.

[+KaeruYojimbo]

A couple of things to keep in mind with Atari 2600 sprites. One, they can only be 8 pixels wide. Two, there can only be one color for each horizontal row (take a close look at Pitfall Harry or Mario and you'll notice this). Batari basic has a few further limitations regarding multicolored sprites. The best bet would be to stick with single color. That or create the game in assembly rather than basic, but you might have a harder time finding an assembly programmer who'd be up for doing this.

Edited February 13, 2016 by KaeruYojimbo

[AaronV]

A couple of things to keep in mind with Atari 2600 sprites. One, they can only be 8 pixels wide. Two, there can only be one color for each horizontal row (take a close look at Pitfall Harry or Mario and you'll notice this). Batari basic has a few further limitations regarding multicolored sprites. The best bet would be to stick with single color. That or create the game in assembly rather than basic, but you might have a harder time finding an assembly programmer who'd be up for doing this.

Sure, a Berzerk type figure would be fine as long as the enemy was a different color.