Collaborative bB game?

[Fort Apocalypse]

Have been thinking it might be neat to develop a game as a team. Anyone interested? Any ideas in best way to do it that?

 

(Would say to use source control, but I almost think it might be neat to do it by just agreeing on rotating through teams. It might also be neat to have two teams and have a competition on the forum. )

[SeaGtGruff]

Have been thinking it might be neat to develop a game as a team. Anyone interested? Any ideas in best way to do it that?

 

(Would say to use source control, but I almost think it might be neat to do it by just agreeing on rotating through teams. It might also be neat to have two teams and have a competition on the forum. )

I think that sounds like a great idea. Perhaps the best approach would be to assign certain tasks, depending on different people's strengths. That would be like a professional game company's approach-- one or more people could focus on the game design (i.e., its basic concept, overall goals, levels design, etc.), one or more people could focus on the graphics, one or more people would cocus on the sound effects and music, one or more people could focus on the programming, etc. The team could work together either by exchanging emails that are carbon-copied to everyone on the team, or-- if the game's development were going to be "open source" and visible to the public-- by posting messages to a thread in these forums.

 

Michael

[gambler172]

HI FA

Nice idea,but i am not a programmer ,but i could help with ideas and testing the game .

greetings Walter

[Impaler_26]

Thats a nice idea! I just started playing around with bB a while ago so i don't know much about programming yet but i could also help with the game design, testing, ideas etc.

[Fort Apocalypse]

Perhaps the best approach would be to assign certain tasks, depending on different people's strengths. That would be like a professional game company's approach-- one or more people could focus on the game design (i.e., its basic concept, overall goals, levels design, etc.), one or more people could focus on the graphics, one or more people would cocus on the sound effects and music, one or more people could focus on the programming, etc. The team could work together either by exchanging emails that are carbon-copied to everyone on the team, or-- if the game's development were going to be "open source" and visible to the public-- by posting messages to a thread in these forums.

 

Michael

 

That sounds great!

 

I would vote for keeping all of the stuff about the development of each game in its own forum thread- that way everyone in the community can contribute. But if we get enough interest in a competition, then maybe we could go the private team email route (and just post milestones and/or final game).

 

The two biggest hurdles I think will be trying to come up with game ideas that everyone in the team is interested in helping develop and how to handle submitting code/work and integration of different people's code.

 

I'll post again with some proposed ideas to get started...

[Fort Apocalypse]

How about a tank game - maybe similar to combat, but maybe not - maybe you could go off the screen like adventure and have a bigger than 1 screen map per level. Maybe 9 playfields in a 3x3 orientation? Or maybe you can only leave the screen in one direction (progressive game - kind of like Front Line or River Raid)?

 

Assuming that people liked that idea, then maybe someone could start the tank player definitions (just 8 directions?). Then someone else could define the playfield definitions or decide whether it is going to be scrolling (could just randomly draw dots in the beginning?).

 

Then someone could come up with the enemy tank AI, someone could come up with a title screen and select screen (and concepts about levels), then someone else do the shoot, hit, and die sounds, someone come up with title screen and win music.

 

Any other ideas? (it doesn't have to be anything like that- was just a starting idea.)

[Impaler_26]

How about a tank game - maybe similar to combat, but maybe not - maybe you could go off the screen like adventure and have a bigger than 1 screen map per level. Maybe 9 playfields in a 3x3 orientation? Or maybe you can only leave the screen in one direction (progressive game - kind of like Front Line or River Raid)?

 

Assuming that people liked that idea, then maybe someone could start the tank player definitions (just 8 directions?). Then someone else could define the playfield definitions or decide whether it is going to be scrolling (could just randomly draw dots in the beginning?).

 

Then someone could come up with the enemy tank AI, someone could come up with a title screen and select screen (and concepts about levels), then someone else do the shoot, hit, and die sounds, someone come up with title screen and win music.

 

Any other ideas? (it doesn't have to be anything like that- was just a starting idea.)

Hm.... a Tank game is not a bad idea but a combat-like game in bB has already been started, Combat DX.

 

So i think it would be nice to make it different from Combat, maybe something like Phantom Tanks?

[SeaGtGruff]

How about a tank game

Hm.... a Tank game is not a bad idea but a combat-like game in bB has already been started, Combat DX.

 

So i think it would be nice to make it different from Combat, maybe something like Phantom Tanks?

I started writing a lengthy reply to this the other night, but I'm short on time (on my way out the door to visit my sister for a few days), so I'll have to wait until Thursday night to finish it. But quickly, I had offered to finish "Combat DX" for Dragnerok X, and I had once suggested that he make a split-view screen so two players could be on different screens and run around from screen to screen trying to hunt down or evade each other (I did a sort of proof-of-concept demo that I called "Tag! You're It!" to show what I was talking about and demonstrate how it could be done). Perhaps Dragnerok X would consent to letting "Combat DX" be completed by a team, and possibly even rewritten to use the kind of split-view multiple-screen game play that I tried to illustrate in the "T! Y I!" demo?

 

I also have an idea for a platform game that might be kind of cool, plus lots of other ideas. I'll post some more Thursday night after I get back from visiting my sister.

 

Michael

[Fort Apocalypse]

Hm.... a Tank game is not a bad idea but a combat-like game in bB has already been started, Combat DX.

 

Man! Just looked at that code and I'm really intrigued about how the sprites were shared by pointing player0 and 1 at same memory locations. I'd have to stare at it for much longer before really getting it though.

 

Would be nice if there were something baked into bB that allowed for p0 and p1 to easily share player definitions, but it is pretty cool that you can do all of this stuff.

 

As for the Combat DX game itself, minus all of the many, many playfields available, it could benefit (maybe) from use of the 2 player score and life counters, and add something to the select menu to allow you to choose desert/arctic. But I also like Michael's split screen idea. Also, would be cool to have 2 tanks per player like Armor Ambush (pull back on joystick to change player).

[SeaGtGruff]

Man! Just looked at that code and I'm really intrigued about how the sprites were shared by pointing player0 and 1 at same memory locations. I'd have to stare at it for much longer before really getting it though.

Yeah, I wrote that part of the code for Dragnerok X. It's easy enough to figure out what you need to do, by writing a little batari Basic program, compiling it, then looking at the .asm file to see the assembly code that the batari Basic compiler generated. For example, compile the following program (which isn't even anything you can actually run, since it's just a "player0" statement, without any kind of display loop):

 

   player0:
  %00000001
  %00000011
  %00000111
  %00001111
  %00011111
  %00111111
  %01111111
  %11111111
end

Then open the .asm file that was generated, and scroll almost to the bottom of the program to see what the assembly code looks like (your program code will begin at the "game" line label, after all of the code for the kernel and such):

 

game
.L00;  player0:

  LDA #<playerL00_0

  STA player0pointerlo
  LDA #>playerL00_0

  STA player0pointerhi
  LDA #8
  STA player0height
  if (<*) > (<(*+9))
  repeat ($100-<*)
	 .byte 0
  repend
  endif
playerL00_0

  .byte 0
  .byte	%00000001
  .byte	%00000011
  .byte	%00000111
  .byte	%00001111
  .byte	%00011111
  .byte	%00111111
  .byte	%01111111
  .byte	%11111111
  echo "	",[(scoretable - *)]d , "bytes of ROM space left")

(I edited the lines slightly by changing the tabs to spaces, and making sure that each line of code begins with 3 spaces, or a multiple of 3 spaces, but other than that the code is exactly as generated by the batari Basic compiler.)

 

First, you'll notice that the actual player data isn't stored with the "player0" statement; it's actually stored at the end of the program (but before the score graphics), with a line label of "playerL00_0." That's just a unique line label that the batari Basic compiler made up; the "L00" in that line label refers to the line label ".L00" (i.e., line 0) where the "player0" statement occurred. The actual code that "loads" the player data-- or, more accurately, that tells batari Basic's kernel where to read the player's data from, and how many bytes to read-- is contained in the 6 lines that come after the ".L00" line label:

 

   LDA #<playerL00_0

  STA player0pointerlo

This pair of lines loads the accumulator with the value of the "lo byte," or least-significant byte, of the address "playerL00_0." So if line label "playerL00_0" were located at address $F823, the accumulator would be loaded with the value #$23. Then it's stored in "player0pointerlo" (i.e., the lo byte of the pointer to player0), which is one of batari Basic's "system variables."

 

   LDA #>playerL00_0

  STA player0pointerhi

This next pair of lines loads the accumulator with the value of the "hi byte," or most-significant byte, of the address "playerL00_0." Continuing the previous example, that would be #$F8. Then it's stored in "player0pointerhi" (i.e., the hi byte of the pointer to player0).

 

   LDA #8
  STA player0height

Finally, we load the accumulator with the height of the player-- #8, since we defined the player as being 8 lines tall (i.e., 8 lines or bytes of data)-- and store it in "player0height."

 

   if (<*) > (<(*+9))
  repeat ($100-<*)
	 .byte 0
  repend
  endif

This section is just making sure the graphics data for the player doesn't cross a page boundary, since that would cause the "LDA (player0pointerlo),Y" instruction to require an extra machine cycle when a page crossing occurs, and we want the instruction to always take the same number of cycles. If there aren't enough bytes left on the current page, this code will fill up the rest of the page with zeros, so that the player data will be located at the beginning of the next page. Otherwise, if there are enough bytes free on the current page, the player data will be located on the current page.

 

playerL00_0

  .byte 0
  .byte	%00000001
  .byte	%00000011
  .byte	%00000111
  .byte	%00001111
  .byte	%00011111
  .byte	%00111111
  .byte	%01111111
  .byte	%11111111

Here is the actual player data that we'd typed into our program. Note that a zero is placed before the actual beginning of the player data. Or rather, it's at the end of the data, since batari Basic will read the data in reverse order (i.e., the last byte of data defines the first line of the graphics shape, since the data is stored upside down in memory).

 

By studying how batari Basic compiles the "player0" statement, we can learn all that we need to know about how to control the player shapes manually. This lets us save ROM by doing things like setting two players to the same shape, by pointing them to the same data, without needing to define the shape twice in memory. In "Combat DX," each tank cycles through 16 shapes as it rotates, so if we define each shape in memory, that's 32 shapes (i.e., 16 for each tank). But the two tanks have exactly the same shapes, so if we let player1 use player0's data, we can cut that down to just 16 shapes. And almost half of the shapes are just mirror images of the other shapes, so if we manipulate the REFP0 and REFP1 registers ourselves, we can use just 9 shapes. So we can save quite a bit of ROM that way. The only other thing you need to understand about what that code in "Combat DX" is doing, is that it's using each tank's "directional" value to determine which shape that tank needs to be pointed to, and how the REFPx register needs to be set.

 

Actually, I haven't looked at that code in a while, but if it's written the way I remember it (i.e., with a series of "if" statements), then I could have saved even more bytes (and simplified the program logic) by using indexed tables. When I start working on "Combat DX" again for Dragnerok X, I'll make that change if it isn't already written that way.

 

Would be nice if there were something baked into bB that allowed for p0 and p1 to easily share player definitions, but it is pretty cool that you can do all of this stuff.

In a sense, there already is, because all you need to do is the following:

 

   player0:
  %00000001
  %00000011
  %00000111
  %00001111
  %00011111
  %00111111
  %01111111
  %11111111
end
  player1pointerlo = player0pointerlo
  player1pointerhi = player0pointerhi
  player1height = player0height

The only way that could be any simpler is if the compiler were programmed to look for the statements "player0 = player1," and "player1 = player0," and generate the appropriate assembly code. It doesn't seem like that would be too difficult for batari to do.

 

As for the Combat DX game itself, minus all of the many, many playfields available, it could benefit (maybe) from use of the 2 player score and life counters, and add something to the select menu to allow you to choose desert/arctic. But I also like Michael's split screen idea. Also, would be cool to have 2 tanks per player like Armor Ambush (pull back on joystick to change player).

Those all sound like great ideas, but I haven't looked at the latest version of the code yet, and I'm not sure how much ROM is free. The first thing I plan to do is see if the existing code can be optimized to free up any ROM and/or cycles, or otherwise reorganized to be easier to understand/modify. Then, when we see how much time and space is available, we'll be in a better position to consider any modifications.

 

Also, I don't remember how close Dragnerok X came to completing the program, but I think he was working on the AI routines for the enemy tanks.

 

Michael

[Dragnerok X]

Sorry for the somewhat late reply, everyone; I just haven't been here for quite some time, just today thought I should check back (good timing, I guess...). So, to respond, I'd be more than happy than to let you (Michael), along with a team of people, finish Combat DX. To tell you the truth, I've considered taking up the task, now that I'm a bit more free than I was, just before I noticed this; so (I'm probably being a bit repetitive, but) if you need any help, I'm here. Also, as of the last code "clean-up", I was about halfway through sound and was also testing a few AI concepts.

[Fort Apocalypse]

Sorry for the somewhat late reply, everyone; I just haven't been here for quite some time, just today thought I should check back (good timing, I guess...). So, to respond, I'd be more than happy than to let you (Michael), along with a team of people, finish Combat DX. To tell you the truth, I've considered taking up the task, now that I'm a bit more free than I was, just before I noticed this; so (I'm probably being a bit repetitive, but) if you need any help, I'm here. Also, as of the last code "clean-up", I was about halfway through sound and was also testing a few AI concepts.

 

Jimmy, just let us know if there is anything we can help out with. I think it would really be cool for us all to work together on a project. I think if we're serious then working out the logistics like Michael was saying would be the next step. Let us know what you think.

[Dragnerok X]

Jimmy, just let us know if there is anything we can help out with. I think it would really be cool for us all to work together on a project. I think if we're serious then working out the logistics like Michael was saying would be the next step. Let us know what you think.

 

I agree. This would make a pretty good collaborative project.

 

As for the game itself, I think that if we are going split-screen, it's going to be all or nothing (I'm for it if it can be done), so with that in mind, most of the current game should work almost immediatly, but there are a few things we (whoever's going to be working on this project, thus far I'm assuming SeaGtGruff and I, but if you or anyone else could contribute, that's fine too) must consider. First of all, the game could use, as suggested, quite a bit of optimization, not only in terms of rom space by cutting the if-then statements, but even more in terms of of free variables as we incorperate the split-screen side of things/all the logic associated with that (currently, there are only 3 variables free, all of which are split up into sections of bits). Second, it appears the levels I'm currently using may need to be (*Gasp*) shrunk or we'll need to implement some kind of scrolling engine into Michael's T! YI! concept, and I'm not sure how that might effect the game's already somewhat shaky performance, but if something like that could be done (say,your tank would be in the middle of the screen, and everytime your tank moves 8 pixels up, the screen jumps 8 pixels up, thus accounting for the playfield blocks and similar for the other directions) the possibilities for level design would really open up. Finally, some minor physics tweaks may need to be accounted for, for example instead of having the missile destruction borders being the extreme sides of the screen, let them be the sides and the center divider, or perhaps, let them move about the map until they hit a target. Once all of that's finished we could focus on getting the sound up, setting up a decent AI (this should definetly be done AFTER the split-screen system is incorperated, for obvious reasons) and add some final polish, maybe a few menus and/or a title screen and we're done!

 

Of course, this is all assuming we're going with the split-screen idea.

 

What do you all think? Who's in?

Edited January 4, 2008 by Dragnerok X

[SeaGtGruff]

Of course, this is all assuming we're going with the split-screen idea.

 

What do you all think? Who's in?

I think I should try to create a simple split-screen tank demo to see if it would be feasible. I thought about the scrolling idea, too, but I'm not sure how it could be made to work. Basically, if each tank/player has his/her own window or half of the screen, then if the two tanks are in the same zone as each other, they would both need to be in both windows, the way the two people in "Tag! You're It!" do. And the way that's done is by using two copies of the players, set at wide spacing. So the scrolling would have to be a zone or "windowful" at a time. For example, if the entire playing area were 3x3 zones in size, as follows:

+---+---+---+
| 1 | 2 | 3 |
+---+---+---+
| 4 | 5 | 6 |
+---+---+---+
| 7 | 8 | 9 |
+---+---+---+

then the window would shift from 1 to 2, or 1 to 4, all at once, with the tank seeming to go off one edge of the window and reappear at the opposite edge, like moving from room to room in "Adventure." That could still be pretty neat, especially if the entire playfield is like a maze. For example, even if the two tanks are both in the same zone, there might be a wall between them, and the only way to get to the other side of the wall would be to go off the screen into other zones to find your way around.

 

If possible, it might be interesting for each tank to have a certain number of hit points, and it would lose a point each time it's hit. And maybe each side could have a home base, and you could repair your tank (restore your maximum number of hit points) by making it back to your home base before you got hit and lost your last hit point. Then the strategy would change a bit, because if you have more hit points left than your enemy's tank, you might be more aggressive and try to chase him down and blast him, otherwise you might be more defensive and try to evade him so you won't get blasted and lose your last hit point. When a tank gets destroyed, the replacement tank could be dispatched from the home base, rather than respawning at a random location.

 

Of course, there could also be several different variations to choose from-- a single-screen variation, a multi-screen variation, a single hit point variation, a multiple hit points variation, etc. And as far as variables are concerned, some of the variables might be defined differently depending on which variation is selected.

 

Michael

[Dragnerok X]

Of course, this is all assuming we're going with the split-screen idea.

 

What do you all think? Who's in?

I think I should try to create a simple split-screen tank demo to see if it would be feasible. I thought about the scrolling idea, too, but I'm not sure how it could be made to work. Basically, if each tank/player has his/her own window or half of the screen, then if the two tanks are in the same zone as each other, they would both need to be in both windows, the way the two people in "Tag! You're It!" do. And the way that's done is by using two copies of the players, set at wide spacing. So the scrolling would have to be a zone or "windowful" at a time. For example, if the entire playing area were 3x3 zones in size, as follows:

+---+---+---+
| 1 | 2 | 3 |
+---+---+---+
| 4 | 5 | 6 |
+---+---+---+
| 7 | 8 | 9 |
+---+---+---+

then the window would shift from 1 to 2, or 1 to 4, all at once, with the tank seeming to go off one edge of the window and reappear at the opposite edge, like moving from room to room in "Adventure." That could still be pretty neat, especially if the entire playfield is like a maze. For example, even if the two tanks are both in the same zone, there might be a wall between them, and the only way to get to the other side of the wall would be to go off the screen into other zones to find your way around.

 

If possible, it might be interesting for each tank to have a certain number of hit points, and it would lose a point each time it's hit. And maybe each side could have a home base, and you could repair your tank (restore your maximum number of hit points) by making it back to your home base before you got hit and lost your last hit point. Then the strategy would change a bit, because if you have more hit points left than your enemy's tank, you might be more aggressive and try to chase him down and blast him, otherwise you might be more defensive and try to evade him so you won't get blasted and lose your last hit point. When a tank gets destroyed, the replacement tank could be dispatched from the home base, rather than respawning at a random location.

 

Of course, there could also be several different variations to choose from-- a single-screen variation, a multi-screen variation, a single hit point variation, a multiple hit points variation, etc. And as far as variables are concerned, some of the variables might be defined differently depending on which variation is selected.

 

Michael

 

How's progress on said demo (I hope I haven't kept you waiting for a reply )? Something like that would help me (and others) better get a feel for how this would work, so we could make revisions to the previous thoughts as necessary.

 

BTW: The Single/Dual screen idea sounds promising, but how would we separate the two engines during run-time and how might that effect rom space? I'm looking foward to starting this just as much as you are, I just need a good platform to start from.

[SeaGtGruff]

How's progress on said demo

I haven't been working on it yet. I'll get to it soon.

 

Michael