2600 RPG - codename, "CiE"

[brpocock]

Bruce-Robert Pocock and Jason D. "MayDay" are proud to announce the ongoing development of a the second* Atari 2600 Rôle-Playing Game.

 

The project, code-named "CiE" for now, is a turn-based RPG and uses a menu-based combat and conversational engine and a tile-based map system for traveling through the game world.

 

Perhaps unique among 2600 games (?), this game uses compiled scripts to drive Non-player character interactions and other gameworld events, allowing the game's designer to write high-level instructions for game events which are then interpreted at runtime. The language (in both source and binary forms) is nicknamed "Ursa."

 

Source code for the game engine will be available under the GPL. Game data (art, sound, maps, and conversations) will not be included in the distribution to make it slightly more difficult to cheat.

 

ROMs will be available for download. Pending acceptance of the final product by AtariAge, we intend to offer it to AtariAge for publication on cartridge with manuals.

 

* (after Paul Slocum's HomeStar Runner game, also in progress)

 

Working Title: CiE

Designer, Maps, Scripts, and Digital Art: MayDay

Programmer, and Documentation: BRPocock

Build tools: dasm, m4, perl, NetPBM, gmake

Source languages: 6502 assembly, about 75% generated by perl/m4 from source text files

Target ROM budget: 64kiB

Estimated size of game world: a total of over 30 maps.

License: GNU GPL v2 (source code, program code); game data: free for personal use, to be exclusively licensed to AtariAge for commercial distribution.

 

Some more detailed notes:

 

Traveling through the world map is a tile-based engine similar to [a stripped to the bare metal version of] an RPG like Ultima, or Final Fantasy.

 

Combat uses a joystick-driven menu system.

 

Conversation is text-based, using a 12'ish characters per line system. The font system is actually semi-proportional... characters may be "narrow" or "wide," so e.g. "M" is wider than "I" but "I" and "A" are the same width.

 

The game supports use of various weapons and magic spells, and has player stats for things like attack, defend, hit points, gold, and the like.

 

Game save will be supported using a (rather painfully long ) "code entry" system. Support for AVox or similar memory devices is possible but not guaranteed. (In particular, depends on whether I get a hold of one before alpha test.)

 

Joystick for general control. Color/B&W switch is abused to select NTSC or PAL/SECAM mode. Actual color/B&W or PAL/SECAM switching available from the main menu. Difficulty switches are being used for difficulty handicapping of the combat system. Game Select switch is used to pause the game and review player stats.

 

Video TouchPad (as a second controller) will be supported as an alternative "hot key" system for making menu selections.

 

Due to the script-based nature of the engine, translated versions for other Latin-alphabet languages (but, sorry, in ALL CAPS with no accented characters...) are possible in future.

 

Tentative builds schedule

 

Note: Milestone test releases will demonstrate various software behaviours but will not be using the actual game world data. You'll be able to walk around maps and talk to people but they'll be designed to stress various parts of the game engine and not so much to tell a story. Alpha test release will be in limited circulation with game world data. Beta test release will be posted to AA with game world data. Please be courteous about posting plot spoilers...!

 

Milestone 1: March

Milestone 2: April

Milestone 3: May

Alpha test: July

Beta test: August

Release: October

 

Included in the digital release kit will be printer-ready PDF versions of the "How to Play" manual as well as a second "manual" describing the game world, a 64k binary, and the source code for the engine, allowing anyone (with access to a Mac or Linux machine) to write their own game using the engine without writing any kernel code.

 

And, before anybody asks:

 

No, I don't have a ROMfile or screenshots to post just yet. Code for Milestone 1 is still being tuned. For those of you who are programmers on "modern" systems: consider this: more than half of the ROM is being generated by Perl scripts, and the tile-based drawing kernel required more complex macro code than dasm could provide (or would have required so much cutting and pasting that I'd never find all the typos), so I've resorted to using m4 to preprocess the main drawing routine... which is, presently, running an average of about 80 cycles per scanline with sprites. The amazing cruelty to TIA that is the tile-based drawing code is perhaps best described as "an 18lk", because each group of 18 scanlines passes through 18 slightly-different iterations of an unrolled loop. However, the bitmaps are more-or-less 2 lines of resolution with various levels of colour detail depending on the type of object and where it appears on the map. The very moment that I get the display kernel stabilized I'll post something to the 2600 Programming forum here.

[vdub_bobby]

GPL? You might read this: http://www.atariage.com/forums/index.php?s...54entry838654

 

 

And this looks pretty cool, though I'll wait to see anything before getting too excited. Or before getting excited at all.

 

EDIT: And...just my two cents here, but I think switchable NTSC/PAL binaries are kind of a waste of code space. Who is ever going to want to switch back and forth? Better to just make two separate binaries, IMO.

Edited January 27, 2006 by vdub_bobby

[brpocock]

GPL?  You might read this: http://www.atariage.com/forums/index.php?s...54entry838654

 

I understand the theory behind gut negative reactions to GPL, but the advantages are better. In this case, there's no CNP code, since (afaik) this has never been done before, so the only content from a third party is vcs.h, which is included with dasm, ergo excempt.

 

The reason for GPL is practically the same reason as AA's programmers fora and the Stella list: to ensure that the source code must survive. Hopefully, in future, someone will find a new use for the program or its build utilities, and I don't want any potential problems with licensing to prevent him or her from building his(her) own game from the sources.

 

More to the point, my day job is programming videogames, so I cannot release this unless it's GPL'ed without getting legal paperwork from my employer, because of the wording of my contract. My employer is kind enough that there's an "escape clause" for GPL'ed (or LGPL'ed) projects.

 

All of that being said: I may change my mind to LGPL to allow someone to link my code with CNP code from elsewhere that might be under a different license. However, the post you link to indicates a fundamental misunderstanding as to how copyright law (at least in USA) works. Including any source code from someone else (more than a few "trivial" lines... in 6502 assembly, that might be about 10 or 20 operations) requires a license -- source or binary. Something released with "no license" is automatically, "all rights reserved to the author or his(her) successor" which basically puts it off-limits if the author can't or won't sign a release. Placing something into the public domain might be "doable," but it does introduce a slew of other problems.

 

Not that I plan to sue anyone for using my code or downloading a ROM image, but if I didn't put some kind of license there, anyone who did so would potentially face civil and criminal penalties under copyright law and the DMCA.

 

I will take a closer look at LGPL as an option, though. That at least ought to protect legitimate (in my mind) uses such as yanking the map kernel and stuffing it into batariBasic or something.

 

And this looks pretty cool, though I'll wait to see anything before getting too excited.  Or before getting excited at all.

 

Naturally! I'm still tuning important things like the number of tiles and number of colour changes trying to get it all in, and to stabilize it so that each row takes precisely 76 cycles rather than varying from about 70 to a max of 90[!] right now, without running out of RAM for player stats.

 

EDIT:  And...just my two cents here, but I think switchable NTSC/PAL binaries are kind of a waste of code space.  Who is ever going to want to switch back and forth?  Better to just make two separate binaries, IMO.

1008012[/snapback]

 

Right, switching is silly, but I'm concerned about production costs for the ROM's. And, it's easier (since every colour of every tile, sprite, ... has to be encoded twice) for my map compiler, tile data compiler, and so forth, if the three colours (NTSC, PAL, and SECAM=B&W) are written out at once.

 

Once the time draws nearer I may reconsider and just code a build macro or something to produce two binaries, but NTSC and PAL versions still want 2 palettes (NTSC + B&W, PAL + SECAM=B&W), so there's very little complexity added other than selecting the number of lines to blank on the display. One extra compare/branch/load set during VBLANK is pretty trivial altogether... plus a 50% bloat in COLUM values.

 

* In case that sounds silly, I didn't realize until late in the game that each SECAM colour has a different (fixed) luminance, so the SECAM palette can be used as the B&W palette for NTSC and PAL both. Since SECAM boxes have the SWCHB setting permanently set to read "B&W" and are otherwise basically PAL systems, that works out to getting PAL B&W for free and NTSC B&W just requires changing the number of scanlines and using the SECAM palette. It also means we -- and by "we" I mostly mean MayDay as he's doing the artwork -- don't have to worry about setting up four colours per colour block...

 

The other reason is that certain tables (e.g. tile maps) have to be aligned certain ways (to avoid e.g. crossing page boundaries). The current estimation is to align maps on 128B boundaries (half-pages). This means that if the third palette were absent, there would be more "padding" and less "useful data" in the ROM, so there wouldn't be much savings. Individual test maps are running between 90..118 bytes with all three palettes, wasting up to 38B per map, but I'm experimenting to see how many tiles I can crank out of the drawing routine before I guarantee that format. The current working theory is 8 columns, 10 rows, with some horizontal "letterboxing" on the left and right because there isn't enough time to decode bitmaps for more than 8 tiles per row and still handle multicolour sprites and such.

[vdub_bobby]

A couple of things regarding color schemes:

 

First, who in the world actually uses SECAM anymore? Very few, if any, homebrews have been released that support SECAM and I have never seen any requests for SECAM support.

 

Second, and similarly, why support B&W? Again, who has a B&W TV? Use the B&W switch for something more useful.

 

My two cents.

[brpocock]

A couple of things regarding color schemes:

 

First, who in the world actually uses SECAM anymore?

 

France, and North Africa... but, yes, it's an even smaller subset of an already tiny "market."

 

Very few, if any, homebrews have been released that support SECAM and I have never seen any requests for SECAM support.

 

True enough, but (not to sound sarcastic, not my intention) why limit oneself to what others are doing? It is, ultimately, a ridiculous undertaking to try to cram what is an (exceptionally pale) imitation of the Ultima format onto a 30-year-old console system that was designed to play Pong and Space Invaders.

 

I do gather that most (nearly all) PAL games are playable, but just look silly...

 

Second, and similarly, why support B&W?  Again, who has a B&W TV?  Use the B&W switch for something more useful.

 

My two cents. 

1008056[/snapback]

 

True, it's a silly extension.

 

Ultimately, though, I'd liefer to have the extra support in there than to just waste the ROM space due to alignments. Hopefully not wasting too much of MayDay's time in picking colours from the other palettes in his artwork, but ... *shrug* Plus, dealing with conditional compilation of thousands of lines of code, much of it machine-generated, could be a nightmare, and it may end up being a nightmare that I have to go through still if I can't optimize the bloody kernel to run just a wee bit faster. (The map kernel itself now weighs in at 3,831 lines of assembly code total, plus lots of comments -- and that's just to draw the map screen, no setup, no input, ...)

 

I think, though, probably the above are rationalizations, and I'd just feel heartbroken if there was something that the 2600 could do that it wasn't doing. The game might be perfectly playable with just big coloured blocks and a square "man," but pushing the machine is part of the reason for such things.

[brpocock]

... I'd just feel heartbroken if there was something that the 2600 could do that it wasn't doing...

1008073[/snapback]

 

Although, for reasons of ROM space limits, I'm 90% sure we won't be supporting the AVox for speech

 

I can't say I'm heartbroken about that, but I'm at least disappointed.

[vdub_bobby]

I would say that supporting *at least* the EPROM in the AVox/Memcard is a far, far better use of ROM space than supporting little-used color schemes.

 

Supporting the speech of the AVox...I dunno if it would fit in a fantasy-themed RPG anyway, it kind of sounds like a robot.

 

EDIT: And Richard H. might send you a AVox/Memcard for free if you will be developing for it. Can't hurt to ask!

 

EDIT II: And why all this talk about wasting ROM space? Surely you will have some short tables or short pieces of code that can fit in the unused portions of pages!

Edited January 27, 2006 by vdub_bobby

[brpocock]

EDIT II: And why all this talk about wasting ROM space?  Surely you will have some short tables or short pieces of code that can fit in the unused portions of pages!

1008081[/snapback]

 

May be... there aren't a lot of useful things that can be done with variable-length irregularly-spaced gaps varying up to a max of about 30 bytes, not relative to the number of them that'll exist.

 

EPROM support is a fairly big undertaking, but it's high on the priority list, right under the milestone requirements.

[+batari]

GPL?  You might read this: http://www.atariage.com/forums/index.php?s...54entry838654

 

I understand the theory behind gut negative reactions to GPL, but the advantages are better.

You seriously underestimate Andrew. He would not give a "gut negative reaction." He's a highly experienced programmer. He even programmed commercial NES, A8, C64 and other games more than 20 years ago, that sold millions of copies. No offense, but without knowing your experience level, I am skeptical that you know better than he does regarding the implications of using the GPL for 2600 code.

 

I don't know enough about the GPL to be certain, but for me, Andrew's points were well-taken.

 

I will take a closer look at LGPL as an option, though. That at least ought to protect legitimate (in my mind) uses such as yanking the map kernel and stuffing it into batariBasic or something.

Perhaps Andrew will chime in sometime and give his opinion on the LGPL.

 

But as I understand, bB code is considered an entirely different animal than asm code in terms of licensing, so it's probably OK, but others probably know better than me...

Edited January 28, 2006 by batari

[fabventure2600]

[Cybergoth: Pointless fullquote deleted]

 

Simply Awesome,thats what i talk about New Homebrews....

 

[Cybergoth: Pointless attachment removed]

[MayDay]

Okay, for the dumb guy in the conversation, what are the implications of releasing something as GPL? I know open-source coding is optimal, I just don't know what this all means. I can assure everyone that I have no desire to screw up what people have spent a long time creating for us. Would NOT releasing the source code at all make it okay for you Robert? Would that be better for the community, as I understand it?

 

-Jason

 

PS- I'm very excited about the actual game, and it seems to be coming along quite nicely. For some of the basic ideas behind it, see the dragon warrior thread or check out my blog for basic info on an RPG idea.

[Cybergoth]

Hi there!

 

I'm fine with GPL'd software. That would allow that *I* can "distribute it for a fee"! Way cool, can't wait until it's done

 

Greetings,

Manuel

[Bruce Tomlin]

The difference between GPL and LGPL is that GPL forces you to license your own code as GPL if you use GPL code with it. LGPL gives you more choice, by allowing you to use it witn non-GPL code as long as you make the LGPL source code and any changes to it available. (The "L" stands for "Library", such as the C runtime libraries.) This is why the GPL is referred to as a "viral" license. The GPL enforces Richard Stallman's political views about software freedom upon the rest of the world, while the LGPL gives users the freedom to keep their own code private.

 

Then there is the BSD-style license which does not require any re-distribution of any source code, only acknowledgement of where you got it from.

[Tom]

Actually the L in LGPL stands for "Lesser" nowadays. Was changed somewhen because "Library" confused some people to think the LGPL was applicable for libraries only or that the GPL was not suitable for libraries.

[+batari]

The difference between GPL and LGPL is that GPL forces you to license your own code as GPL if you use GPL code with it.  LGPL gives you more choice, by allowing you to use it witn non-GPL code as long as you make the LGPL source code and any changes to it available.  (The "L" stands for "Library", such as the C runtime libraries.)  This is why the GPL is referred to as a "viral" license.  The GPL enforces Richard Stallman's political views about software freedom upon the rest of the world, while the LGPL gives users the freedom to keep their own code private.

1008573[/snapback]

Thanks for spelling this out for us. I read the GPL FAQ last night and some of it didn't sit too well with me. I can see how it's useful for some kinds of software but I can see how it doesn't work for 2600 coding. The FSF has no such LGPL FAQ, just the license, but I couldn't digest all that legalese. Anyway, from what you are saying, the LGPL sounds reasonable to me.

I know open-source coding is optimal, I just don't know what this all means. I can assure everyone that I have no desire to screw up what people have spent a long time creating for us. Would NOT releasing the source code at all make it okay for you Robert? Would that be better for the community, as I understand it?

The issue here is not about open source at all. The community here will always prefer open source, and you can make your projects open source without using the GPL.

 

As I understand it, the GPL doesn't just require YOU to license your software one way. The problem is the viral aspect that Bruce pointed out. This is troubling for 2600 coding. It forces the license on others. If one wants to release their own game under some license, that seems fine to me, but since basically every game nowadays uses code derived from others, the GPL will spread to other projects, even when the authors don't want it.

 

In short, the GPL can force 2600 coders to lose control over their own projects. I think that 2600 coders should retain control over their own projects and not expect that someone else will be releasing carts of their games without royalties or even permission (unless they specifically allow it) and should not be expected to release their source (though most do anyway, or would upon request.)

 

As a side note, I did not release bB under the GPL on purpose. The GPL mostly fit my needs but the problem I had with the GPL was that it allows others to sell bB or derivative works for money. I haven't found an appropriate license for it yet.

[MayDay]

The issue here is not about open source at all. The community here will always prefer open source, and you can make your projects open source without using the GPL.

 

As I understand it, the GPL doesn't just require YOU to license your software one way. The problem is the viral aspect that Bruce pointed out. This is troubling for 2600 coding. It forces the license on others. If one wants to release their own game under some license, that seems fine to me, but since basically every game nowadays uses code derived from others, the GPL will spread to other projects, even when the authors don't want it.

 

I sort of understand- this is why I asked if not including the source code would make it better? If we didn't do a general release of the source code, no one would technically be using the same code as we did... even if the processes are the same and such. My line of thought was we wouldn't force anything upon future programmers by doing it that way. Is there any validity to this line of thought? Or would doing LGPL make this a moot point?

 

-Jason

 

EDIT- rereading the entire thread, I think there is no validity... because if I understand correctly, making it GPL means we would HAVE to release the source code... possibly forcing other homebrewers who would use similar processes to do the same. Then they could have their games sold against their will without compensation and be forced to release their code. Not that anyone is going to get rich or intentionally horde their code, but I understand the implications now. Does LGPL have the same implications?

Edited January 28, 2006 by MayDay

[Shawn]

Is this game large ebough that a save feature will be required? I hope it is cause that would be awsome.

 

And about the comment of who uses B&W tv's still? I do on my homemade Atari Table top machines. I actually use B&W AV TV's the little camper ones.

[MayDay]

Is this game large ebough that a save feature will be required? I hope it is cause that would be awsome.

 

And about the comment of who uses B&W tv's still? I do on my homemade Atari Table top machines. I actually use B&W AV TV's the little camper ones.

1008644[/snapback]

 

Possibly...

Game save will be supported using a (rather painfully long  ) "code entry" system. Support for AVox or similar memory devices is possible but not guaranteed. (In particular, depends on whether I get a hold of one before alpha test.)

 

For a non-programmer, this means... maybe. Whether we have a save feature or not, the password system WILL be a part of the game for sure.

 

-JD

[supercat]

Is this game large ebough that a save feature will be required? I hope it is cause that would be awsome.

1008644[/snapback]

 

I would imagine that the EEPROM would be useful not just for "save-game" functions, but also as a limited-use RAM expansion; Strat-O-Gems uses it in this way to allow for instant replays. An RPG could use the EEPROM to allow the player to wander around a map larger than RAM could support. Effective handling of large numbers of NPCs might be difficult (since data would have to be read from EEPROM every time an NPC moved or even "thought" about it) though there might be ways of making even that practical (e.g. if an NPC is far away from the player, keep a counter for many turns it has gone without moving; when the NPC accumulates enough turns to almost come within the player's field of view (with a limit of, say, eight), it could process them all at once). This wouldn't be quite as good as having NPCs make all their moves in proper turn, but it would probably cut system loading in half.

[Shawn]

I pray to God this project goes all the way. I would love to have an RPG for my Atari 2600. With a Map(s) per chance and all that jazz. I'm willing to be ready to fork out the cash for copy with maps for sure. Pay extra for maps that is. I would buy this RPG even if it's just a cart with no label even. I want a 2600 RPG that bad. I am sure TONS of others would too. When this game is done I would assume demand for it will be VERY high. Perhaps the most in demand homebrew ever.

Edited January 30, 2006 by silver_surfer

[ZylonBane]

I pray to God this project goes all the way.

Yeah, screw all the starving and suffering people in the world. Pray to God for a videogame.

 

 

brpocock, what exactly is the point of having milestones on a homebrew development project? It's not like you're getting paid to make this. It's not like there are marketing and manufacturing departments depending on you to stay on schedule. It just seems... pointless. And more than a little self-important. "Ooh, look at us everyone! We've set MILESTONES!". The only date next to each of those milestones should be "when it's done".

[brpocock]

The difference between GPL and LGPL is that GPL forces you to license your own code as GPL if you use GPL code with it.  LGPL gives you more choice, by allowing you to use it witn non-GPL code as long as you make the LGPL source code and any changes to it available.  (The "L" stands for "Library", such as the C runtime libraries.)  This is why the GPL is referred to as a "viral" license.  The GPL enforces Richard Stallman's political views about software freedom upon the rest of the world, while the LGPL gives users the freedom to keep their own code private.

 

Then there is the BSD-style license which does not require any re-distribution of any source code, only acknowledgement of where you got it from.

1008573[/snapback]

 

Well, "viral" is a real flamebait word, but I'll let that slide.

 

The critical difference between GPL, LGPL, and BSD/X/MIT-style licenses is what someone who gets the code, can then do with it.

 

GPL code is guaranteed to be free, forever. Any modifications must always remain GPL. However, non-GPL/LGPL code cannot be used with GPL code.

 

LGPL code is also guaranteed to be free, forever, but can be mixed with non-GPL code to a greater extent.

 

BSD/X/MIT licenses allow anyone to copy the code and use it without releasing their changes.

 

The original objection to GPL Andrew T. made was that most projects are based on hacking existing projects, which means that you can't GPL them now unless they were in the public domain before, or were already GPL'ed, or one gets relicensing permission from every author whose work was included.

 

On the other hand, unless the author explicitly released his work to the public domain, or under an open license like one of the above, it'd be illegal for me to include his (or her) work in my own without such a release, anyways.

 

GPL'ing it is the safest for posterity. The only reason I can think of for LGPL'ing something would be if there were an existing body of open source works under a BSD/X/MIT or LPGL license, or under a proprietary license (meaning that it's not declared as GPL, LGPL, BSD/X/MIT, or explicitly placed in the public domain), that someone would want to combine bits and pieces.

 

I gave bB as an example because it's proprietary, I believe. I didn't see any explicit license declaration, so by default, it's under standard copyright terms, and nobody but the author is permitted to modify it. If Batari wanted to copy the tile-based kernel, it'd have to be released to him by the author (myself), or placed under the LGPL.

 

In order to protect the public from, e.g. me being hit by a bus, I could LGPL it to remove the onus of each potential future author contacting me to get my release.

 

As far as, "freedom to keep their own code private," neither the GPL nor LGPL affect anyone's code but mine. The GPL simply does not give anyone the right to make changes to my code without also sharing those changes. But, neither does any license except BSD/X/MIT.

 

Since 90% of the code people have posted here is not explicitly licensed, by default, none of it can be used ... so I haven't.

[brpocock]

Hi there!

 

I'm fine with GPL'd software. That would allow that *I* can "distribute it for a fee"! Way cool, can't wait until it's done

 

Greetings,

Manuel

1008551[/snapback]

 

Yes, feel free :-)

 

However, we're only talking about license for the game engine. The game data -- art, maps, conversations, scripts -- will be licensed exclusively through AtariAge.

 

But, you can use the engine and design your own game using it, and then sell that game data. Which is exactly the idea :-)

[vdub_bobby]

The number of active 2600 coders, using "active" loosely, is about 20-30.

 

The number of homebrew games you are likely to sell is around 100-200, assuming you even complete this.

 

Given those numbers, your concerns seem a bit...ridiculous. You haven't used *any* code posted here, because of licensing concerns?

 

You're inventing problems that don't exist and then solving them with a sledgehammer.

[brpocock]

... Then they could have their games sold against their will without compensation ...

1008629[/snapback]

 

No, the game itself is just data in this case.

 

The game engine just supports the data that you're designing. It doesn't include the artwork, music, sounds, maps, scripts, ... just the actual assembly-language code.

 

So the game itself can't be sold.

 

But, if someone wants to come along and spend a few months designing their own game using the toolchain I've developed, more power to them.

 

On the other hand, if they find a bug or limitation in the engine ... say, find a way to crank out an extra colour change that I didn't find ... they have to share that improvement with me, you, God, and everybody, if they distribute the change.

 

Also note that only people who legally obtain the binary have a right to the source. If the game is only sold via AtariAge, only people who buy it have a right to get the source code. But, as I said earlier, I'll probably just post the source on the www for everyone to share. That also applies to modifications. If someone were to modify the sources for their own use, only someone who legally obtained their binary would have a right to their sources.