2600 Homebrew Quality Dropping:Proposed Solution

[+Gemintronic]

What do you mean with "positive" reviews?

I guess that's what we're going to have to figure out as a community. That's not a cop out answer. There has to be a way to provide constructive criticism and provide a filter for those who have particular ideas about quality.

 

By the way I *am* very impressed with the tool. I think it's a great way to provide information on titles that would otherwise be hidden from history.

 

There is no right or wrong with the tools used. But how you are using them.

 

The difference Enthusi is (IMO rightly) pointing out is, that a tool with a higher learning barrier automatically filters some people. This filter can be good (e.g. lazy people who would create lazy games) or bad (e.g. creative people, who cannot handle the technical barrier).

I missed this. I totally agree. Thank you for putting up with me sometimes missing your main points

Edited November 4, 2016 by Gemintronic

[Thomas Jentzsch]

I think we should restrict voting to AA members with a certain minimal post count (~100) and/or membership (e.g. 6 months) only. Also it should be allowed to change the vote and add more comments later on.

 

And maybe we could use some maths to make the votes more relevant. E.g. someone who votes lower on average than the average voter else should get his vote raised automatically during total rating calculation (and vice versa).

[enthusi]

This will be hard to implement though

While there is a different idea of 'good' and 'bad', some people just play the top titles and some just everything.

Top-Title-Player would after a while effectively down-vote top titles if their average would be adjusted.

I btw would not vote if my vote would be altered automatically afterwards

People will always use different aspects to base a vote on. Gameplay, replay-value, graphics, audio, extend, etcetc.

You will end up mixing apples and oranges and in the end it WILL be a first order ranking nontheless that might prove useful.

One simple to implement filter _could_ be that only those vote, that did contribute to the list, as an author of one of the titles in there.

Or (weaker) as one who helped building such list.

 

The former would make sure that voters are in some way 'experts' to evaluate 2600 games as they wrote one themselves (by whatever means) AND it would

motivate game authors to put their titles into that list to be able to vote, too

 

It might also be seen as elitist bullshit by core gamers which then would be cut off voting on a game which also is not very productive admittedly

Edited November 4, 2016 by enthusi

[Thomas Jentzsch]

I know that any adjustment is critical. Probably we can get away without such corrections. And if not, we can still discuss them later.

 

Regarding the "Expert" voting, I would do that only as a secondary list (or result). The primary list should contain the results of all voters. Because the main target of the list should not the be developers but the people really playing the games.

 

To avoid "elitist bullshit" the secondary list could e.g. be the result of a predefined filter. Or only available to those who are allowed to vote there. Then we can exercise our elitism behind the scenes.

[Thomas Jentzsch]

BTW: The Video Game Critic allows voting for all the games he has reviewed. Sometimes with quite different results. And you can even get rankings of the currently most over- (Golf) and underrated (Stellar Track) games compared to the reader's votes.

 

Not sure though, how he prevents abuse.

[enthusi]

Then we can exercise our elitism behind the scenes.

I have not yet released a game for the 2600.

[Thomas Jentzsch]

Cool! You will have some extra motivation then.

 

Or simply any release will count...

[iesposta]

Of course it comes down to the creativity and use of the tools you understand how to use.

batari Basic with the DPC+, RevEng fixes and addition, is very powerful. I joined when it was just released and actively bug-fixed.

I was surprised many batari Basic users didn't immediately start to use the DPC+ kernel.

Maybe it was just too new, buggy, and different?

 

My early use of it was just to make graphic and sound mock-ups, not games, while I learned how the 2600 works.

Sure, it is unable to do assembly kernel tricks because the kernel routines are fixed.

Kernels can be added, but again, you would have to code them in assembly.

 

Plus you don't have to use the built-in routines in the standard way if you get creative:

I showed the scrolling can actually flip two double line playfields. Started Q*bert mock-up with that.

With included assembly, I added sample playback to Flappy which is 4K and the Multi-Sprite kernel -- pre-DPC+.

In my DK Arcade 2600, the TitleScreen is used as the in-game "How High Can You Try?" screen, and that game's Title Screen is just Playfield and DPC+ Virtual Sprites.

Sure some parts have annyoing flicker, but so does the assemlby DK VCS which uses flicker to make super-detailed characters.

I set out to just get the basic game play implemented, and let it flicker. The top of level 1 everything happens horizontally, but I asked and was able to add a few more playfield lines than the normal 172 and that was enough to separate the spirtes and reduce the flicker.

 

batri Basic can also be a tool.

Can't write a complex mathmatical routine in pure assembly? Write it in basic, with your tables, and loops within loops,, and it comples into assemlby.

You can read that assembly file, take the "complex mathmetical routine" that's now converted to assembly, and use it in your assembly program.

 

The more I learn the more powerful batari Basic gets.

My latest work, i removed the score.

Instead of wasting that area at the bottom, I extended the playfield down by hacking the framework.

It's actually commented in the files you can change the screen and that not all values will work.

[gauauu]

I love the rating system idea you all are talking about.

 

Because for all the discussion about homebrew quality, and high-or-low-level tools, the issue is: people make games for their own reasons. (some for the fun of making something, some to just say "I made an Atari game!", some for the challenge, some for a quick buck, etc). Some people want to push the Atari as far as they can with new stuff, some want the fun of trying to make something that would have been possible in 1980. With all the varied reasons, you'll never pin people down enough to say what "should" be done as far as development, because everyone has a different motivation. So once you move past that, what's left?

 

What's left is just having a good system where games can be organized and rated, so that consumers/players of the games can find what they are interested in. Which means that the rating system should maybe also include filters for what sort of hardware and/or language the game used. Some hardcore purists might think Darrel's awesome bus stuffing is "cheating", and want to filter out games that use it. Some people irrationally hate all bb games. Others will just want the coolest games they can find. If we're providing ratings, maybe also make that information filtertable/searchable as well?

[enthusi]

People managed to organize such information in the past (no rating there, though

http://2600scene.net/sizes.txt

 

Game name, binary source/shop, size, hardware, type, vote

To me that would be uber-great already.

type being game, demo, preview or such.

 

Edit:

that would be extremely helpful already without any votes.

Also it would be fully legal to host, too.

Edited November 4, 2016 by enthusi

[Thomas Jentzsch]

Maybe the sheer amount of new releases stopped people from updating (or reviewing)?

 

Even http://www.atari2600homebrew.com/seems dead now.

[Albert]

It would be pretty easy for me to add a section in the forums here specifically for homebrew games, with information about each game, and the ability to rate the games. The forum has the ability to add database-driven pages of this nature. Invision has an entire issue-tracking system they've done like this. If people want such a thing, this should probably be discussed in a new thread? Also, I do plan on opening up the Downloads section when I get the forum moved over to the latest software. This will allow developers to have a central place to post their builds, with integrated discussion, versioning, and much more. Binaries can be organized by system and we can also break down original titles versus hacks. Screenshots and videos can be included, description for each version, link to relevant discussion topic in forum, etc. It's pretty nice. The relevant link to the Downloads section could be included in a new Homebrews section.

 

..Al

[GemWare Games]

I like that idea, but I think that developers shouldn't post their latest build, but reserve that for the cartridge.

[enthusi]

yeah, a proper database does not mean that each title has to be available for free to download.

I.e. BoulderDash should certainly be in there.

[Albert]

I like that idea, but I think that developers shouldn't post their latest build, but reserve that for the cartridge.

 

That's up to the developers, of course. There is no requirement for game binaries to be posted at all for any specific entries.

 

..Al

[Thomas Jentzsch]

If the users could fill the database themselves, then the administrative effort should be minimal.

 

Games could be entered as stubs (e.g. just the name) and others could fill in the missing information. E.g. fill other categories (the more the better) like:

• type (original game, homebrew, demo, hack, pirate...)
• company
• size (ROM/RAM)
• release year
• developers (code, graphics, music, packaging, distribution...)
• rarity(?)
• links, screenshots etc.

It would be cool to be able to filter for categories (e.g. 4k games ranking, games of 1982 rankings, Activision games rankings...)

And ratings could be collected in any state of entry completeness.

[Albert]

Well, I don't know that I want to have this list include anything outside of titles that have been written by the community in the last two decades. There is already an extensive database of games on the MAIN site, so I don't want to really duplicate that at the moment. In time, I can integrate this new database int the main site, but I have significant changes to complete on the main site before that would happen. This is an easier project I could get done in the shorter term, so I don't want to over complicate it.

 

I would not put "Links, screenshots, etc." into a bullet point, I would list them out separately. This will help me design a proper database schema. Not sure I'd include a rarity value at this point. Perhaps "Copies Produced:" for games that had a set run. Such as Boulder Dash for the 2600 with the 250 copies we sold. Or the 100 copies of Lady Bug: Collector's Edition. I'd add "Supported Controllers" as another item.

 

..Al

[+KaeruYojimbo]

This seems pretty up-to-date:

 

http://www.videogamehomebrew.com/index.php?board=4.0

 

A lot of the same information as atari2600homebrew.com but expanded to other systems.

Edited November 4, 2016 by KaeruYojimbo

[gauauu]

This seems pretty up-to-date:

 

http://www.videogamehomebrew.com/index.php?board=4.0

 

A lot of the same information as atari2600homebrew.com but expanded to other systems.

 

The data there is good, but I don't like the organization based on forum threads. Makes it harder to search/sort/filter based on various criteria.

[InsertCoin25]

This seems pretty up-to-date:

 

http://www.videogamehomebrew.com/index.php?board=4.0

 

A lot of the same information as atari2600homebrew.com but expanded to other systems.

Actually, that is the same person who was running atari2600homebrew.com. The owner of the site wanted to focus on all console homebrew, instead of just 2600. It's a great site imo. The forum thread organization does take sometime to get use to. But, overall there is great info on there. I don't know if the owner has publicly announced the new site yet. I believe he is trying to get most of the game info in, which is time consuming, before announcing it.

Edited November 4, 2016 by InsertCoin25

[gauauu]

 

I would not put "Links, screenshots, etc." into a bullet point, I would list them out separately. This will help me design a proper database schema. Not sure I'd include a rarity value at this point. Perhaps "Copies Produced:" for games that had a set run. Such as Boulder Dash for the 2600 with the 250 copies we sold. Or the 100 copies of Lady Bug: Collector's Edition. I'd add "Supported Controllers" as another item.

 

..Al

 

I like the "copies produced" and supported controllers idea.

 

Other potential fields of interest:

 

- License (might be somewhat implied by whether the developer uploads a rom, but doesn't hurt to specify)

- # of players

- Supported accessories (Atarivox/savekey, etc?)

[Mr SQL]

 

Wrong. It does.

 

EDLIN vs MsWord do the same job, but work differently. They are merely ways to record a thought. Both can produce the same output.

 

In 6502 Assembler vs BASIC, there are two different ways of thinking for each tool. And 6502 requires more thought. 6502 can produce output BASIC cannot.

 

 

But, again: It's labeling users of high level languages and their content overall as worse. That's counterproductive.

 

The tool does not determine quality - the programmer and community behind him does. We spend a lot of time talking about quality in terms of our own preffered method. We need to focus on improving the ecosystem regardless of language.

VCS Assembly programming is like being in the Matrix with Neo or on the game grid with Tron - programming doesn't really get more exestential and ethereal than asm on the 2600 because there is literally only a void with an alalog light creating shapes in the ether; 3 lights unless you've got a black and white Television set. You're caught in a loop that repeats 60 times a second and anything goes in the loop, even changing the video signal but you'd better be quick on the draw, the system is in realtime.

 

Programming Assembly on the C64 or Apple is relatively much easier because there is additional hardware like a screen buffer.

 

BASIC is a tremendously creative language and imo not too removed from that kind of Assembly where there is supporting hardware, but much different than VCS Assembly; BASIC on the VCS adds that hardware back for the programmer as virtual hardware.

 

And BASIC programmers get better at programming over time and become more advanced just as assembly programmers do, I don't get why Assembly programmers are supposed to be "more advanced", seems to me it always has more to do with the individual programmers experience and apptitude and not any specific language.

 

And BASIC programmers have a new tool to push the envelope like Assembly programmers are doing on the VCS with vwBASIC - it harnesses both vertical blanks for running code and has a virtual blitter

[YANDMAN]

I admire anybody that is trying to make new games and i think to say that we will run out of ideas is like saying after friday everyones brains will stop working. There are obviously differing degress of skill set in game creators, but there is fun to be had at all levels. like all things in life if you simply do not like someones game then do not play it.