|
| |
There are 130 guests and 3 MSX friends online
You are an anonymous user.
|
| | | | Tuesday, March 04, 2008 - 13:10 Submitted by: pitpan Topic: Challenges | | A new contest has been announced at the Karoshi forum! This new contest is a mini-game development contest that aims to provide a collection of Open Source 2KB games with commented code that will encourage new developers to join and will provide a valuable resource to improve assembly programming skills. The contest goal is to get full Open Source games for MSX, the prize will thus be the availability of the sources of all those games, commented by the authors.
The basic rules of this contest: - Every game genre and theme is allowed
- Start adress: $C000 (it must work on every MSX with 16KB RAM or more)
- It must load with a "BLOAD" command from BASIC
- It must return to BASIC with a RET
- Max file size: 2055 bytes (2048 for the game + 7 bytes for the file header)
- Submitting deadline: 26th of June 2008 at 23:59:59
When the contest is over, a PDF will be published including all sources of the games with comments by the authors, and a ROM version with a menu will be built in order to enjoy the minigames in the most comfortable way.
Relevant link: Karoshi forum |
| | |
|
| By ro on March 04 2008, 13:15 | 5 months 'till deadline? phew..
but, nice initiative!
(and NO, I'll not participate..)
| | |
| By pitpan on March 04 2008, 13:21 | Well, 2048 bytes aren't that hard to fill. I've started a mini-project myself and most of the first kilobyte is already gone. The big issue here is selecting projects that do fit in only 2 KB. I guess that some pretty games will arise, although PONGs, ARKANOIDs, PAIRs and SNAKEs will dominate for sure.
| | |
| By wolf_ on March 04 2008, 13:22 | ro? 5 months for a 2kb game?
| | |
| By viejo_archivero on March 04 2008, 13:23 | Actually is June, not July (english thread has been mistraduced by me  ). Please, correct the newpost: thnx 
{mod: fixed, thou paella! }
| | |
| By pitpan on March 04 2008, 13:26 | I'm a copy&paste victim, viejo!
| | |
| By manuel on March 04 2008, 14:18 | Cool, it might be even possible to package those games for a distribution like Debian. Joost Damad tried this before with Waves. (It got stuck because there were some binary blobs in it that the FTP masters didn't like...)
| | |
| By andrear1979 on March 04 2008, 15:48 | Friends, I think MSXers with below-64K-machines (and I'm in that number ) will sincerely appreciate; most of games released today (including majority of MSXDev entries) can't work on less-than-64K-RAM MSXes, unless you burn it on a ROM. Thanks for this initiative!
| | |
| By poke-1,170 on March 04 2008, 15:57 | why doesn't everyone in the world buy an msx2 at least ?
it's 2008 people, not 1986 
| | |
| By Skyblasc on March 04 2008, 16:20 | I think that the best news about this contest is the comented sources. A trully library of code for wannabe MSX game developers that I'm sure would help a lot of new programmers to try its firsts games 
| | |
| By PingPong on March 04 2008, 16:21 | It's not specified the generations of msx allowed...
| | |
| By hap on March 04 2008, 16:37 | It is: must work at least on every MSX with 16KB RAM.
Could you add a "comments must be in English" rule?
| | |
| By arnold_m on March 04 2008, 19:14 | For inclusion in debian (main) we would also need the games
* to be buildable with programs already in debian such as pas such as pasmo or binutils-z80,
* to run on openMSX with C-bios, and
* to have a licence that permits modification and redistributing.
(Off-topic: why doesn't everyone buy a pc with a 3 GHz quad-core 64-bit CPU and 8GiB at least?
It is 2008 people, not 1988 )
| | |
| By AuroraMSX on March 04 2008, 20:53 | Quote:
| - It must load with a "BLOAD" command from BASIC
|
DOes that imply that 2K BASIC programs are not accepted? 
| | |
| By wolf_ on March 05 2008, 00:03 | I assume that about the whole 2kb may be pletted/bitbusted data and may be unpacked to the 16kb ram?
| | |
| By sjoerd on March 05 2008, 08:34 | Well, you need to return to basic with a ret, so you can't use the whole 16K.
| | |
| By ro on March 05 2008, 10:32 | yes you can.
10 bload "mygame.bin",r
20 end
That basic will take, oh I dunno, max 1KB in total. So you'll have 0x8100 'till 0xDFF to fill. Thaz more than 16KBs
| | |
| By viejo_archivero on March 05 2008, 11:01 | [wolfenstein_: I assume that about the whole 2kb may be pletted/bitbusted data and may be unpacked to the 16kb ram?]
Erm, wolfie, I suggest not to lose focus on the main goal of the thing, that is have nice and clear asm sources for beginners to learn. I don't think compressing like crazy, obfuscate each byte to gain more free space, etc, would help on that main goal... but anyway, let's have some paella 
| | |
| By wolf_ on March 05 2008, 11:12 | It wouldn't make much of a difference!
- Make binary of oodle-size
- Plet it to 2kb
- Make 2kb ROM minus unpacking code
- User has 2kb game
- User has oodle-size sourcecode
I mean, face it: you can't make a fantasy-RPG in 2KB, now could you?
| | |
| By viejo_archivero on March 05 2008, 11:29 | Nah, I prefer making a small mini-game with clear sources (that will be the hardest part for me, imho)
| | |
| By wolf_ on March 05 2008, 11:35 | Imagine that the source doesn't get bigger, but the gfx are.., in that case there's nothing to worry about regarding clearness.
| | |
| By viejo_archivero on March 05 2008, 12:00 | Well, yeah. So, go for that rpg game then!
| | |
| By pitpan on March 05 2008, 13:01 | My sample RPG
10 SCREEN0:KEYOFF:WIDTH36:COLOR15,0,0
20 PRINT"TINY RPG GAME v.1"
30 PRINT"The plane is about to crash. There's fire all around you. What do you want to do?"
40 LINE INPUT">";T$
50 PRINT"Cool. Too bad you're already dead."
60 PRINT"-Push key to start-"
70 IF INKEY$="" GOTO 70
80 RUN
Too bad that BASIC code isn't allowed in 2KBOS contest
| | |
| By Edwin on March 05 2008, 22:11 | Hmmmm, do the comments actually have to say anything useful?
| | |
| By dvik on March 06 2008, 18:05 | What does "It must return to BASIC with a RET" really mean.
Does the game need an option to quit the game or is it ok to just add a ret at the end that never gets executed?
| | |
| By wolf_ on March 06 2008, 18:10 | While not speaking for the organization, I think a RET Z is also valid..
| | |
| By ro on March 07 2008, 10:29 | unless Zero flag is not set....
| | |
| By dvik on March 07 2008, 18:01 | ...ah, so RET NZ is not allowed 
| | |
| By viejo_archivero on March 13 2008, 13:44 | dvik: newpost ="...a ROM version with a menu will be built in order to enjoy the minigames in the most comfortable way."
So, I suppose the RET is needed to be executed (option inside a menu or something), in order the game to go back to the future menu that is planned to be added in that ROM version.
| | |
| By wolf_ on March 13 2008, 14:46 | Then the rule should be like: "game must have an exit function", instead of stating it must 'RET' ..
| | |
| By dvik on March 13 2008, 18:49 | I think wolf_'s wording is clearer. Its sortof a given though. The games we're working on will have a menu option to exit and that should be enough, right?
I suppose the menu application will restore the vdp to whatever state it wants, so exiting the games into screen 0 should be enough, right?
| | |
|
|
| | |
