I'll be blunt. I think the idea of a pure assembly contest is absolutely terrible, especially the idea of a sh4a contest that is separate from a C contest (It just sounds like pointless masochism to me, and an excuse to give games written in sh4a a chance at winning a prize by not subjecting them to competition with C games.)  I can (barely) see the point of a pure z80 separation, but a segregation between sh4a and C is absolutely ridiculous, especially considering that writing in assembly on the Prizm yields little to no benefit in terms of optimization over writing in C.  I also favor an Axe/z80 combined category -- games should be judged not on how difficulty of development, nor the amount extra work an author had to dedicate in the development phase, but rather the quality of the game.  It both encourages Assembly programmers to rise to the challenge before them, and allows Axe programmers to be accepted as serious contenders as well (since, if this will be a game contest... the overall goal will be to make a game, right?)  My thought is, regarding the sh4a idea again, that contestants should be allowed to pick between extra work and getting the job done with C -- but they should NOT get extra consideration for doing so.

Were BASIC not so flawed, I'd even subject games written in it to the same Axe/ASM supercategory; however, BASIC games cannot achieve the same technical standards as their ASM/Axe counterparts, so it would be immensely unfair.  Axe and Assembly games can produce comparable results, so they should be on a level playing field.

As for Compynerd's idea, it's not a bad one, but I don't see it being a popular one among contenders.  I like the idea of an open-ended, genre-limited guideline instead, as such an arrangement would attract the most entries.

We always perform judging in such a way that language-based advantages and disadvantages are balanced against what a skilled and clever programmer can do in the particular language even with those handicaps, so that shouldn't be a factor in choosing which languages should be allowed and how they should be segregated. I should mention that my impetus for suggesting a pure-ASM-only contest is that Cemetech's particular strengths and infamy are in pure TI-BASIC, pure z80 ASM, and Casio Prizm programming, so I was considering a contest that would play to those strengths.

Would you accept a program that pretended to be a calculator program, but ran on the computer? I'm too lazy to learn how to use assembly effectively! I'd be willing to write it in a cross-platform manner and write it in strict C89 so that if someone was willing to, they could get it to compile with SDCC with moderate modification! Pweaaaaase?

The closest I'll accept is a Prizm programmed in C, using RS-232 to talk to a computer (which is a solved problem), and implementing a quick-and-dirty adapter to connect that to gCn.

I'm game for a contest! I'd do some prizm c, it'd give me an excuse to get the darn SDK working right for myself and some more knowledge about it. not that what I submit would be even close to winning quality, but I do think I'd try!

What sort of data crunching will be done? (assuming that KermM is going to have the contest gcn-based)

If you do the AI idea in which a hub program will call a BASIC program (with "Ans" as the only argument, say the current game board or something in a string/matrix) and gets the value from Ans once the program finishes, I will actually enter.

ba-da-da-da-dum!

Actually, I'm open to suggestions on that. How about factoring a very small toy RSA key? That might be too complex of an algorithm, though.

It seems like factoring a prime or something is really just a matter of copying well known algorithms...

Well, not exactly factoring a prime, then. Perhaps finding the Minimum Spanning Tree of a subset of a graph? Solving a portion of the APSP problem (Dijikstra's)? Other suggestions?

I like the idea of BASIC/hybrid Utils and games?
I do have one thing I would really like to enter.
Or we could also do a calc game modding, because cemetech is alot about hacking and modding.

Let's come up with something that isn't an already well-characterized problem. Something that will require creativity and heuristics rather than looking up a known algorithm. Design an algorithm to control a squad of units in a strategy game where the moves from all players are applied at once based on the previous turn's layout (i.e., like an RTS, but with unbounded time to think between ticks of the game state). Have a simple rendering engine written in assembly, and have it call the bots from each entry by executing those programs passing data back and forth through string variables or something so that TI-Basic or Axe or assembly entries could compete against each other directly, and then play a double elimination tournament.

I really like this idea, except that I think that speed should be a factor somehow if all of the contestants are the same type (e.g. the last player to turn in their moves doesn't get to move), coupled with matching contestants of the same type at the beginning of the tournament. This would keep players from using strategies that take O(>9000^n) time to run. Later in the game, though, when TI-Basic is competing against Axe and ASM, this constraint can be removed.

I definitely like some variation of that. Perhaps even have it be a simple program with rendering and rules, and the AI plug-in program tells it where to move the units and what weapons )? to use. I like the idea of making the AIs compete against each other.

Spud: You mean like best modification of an existing game to make it better/faster/cooler?

That was almost exactly what I was thinking, accept have a squad of units with different abilities programmed in, and just have to tell the units where to go (like some slow but long range units, and some fast but short range units). It also should be the one to call the AI plug-ins in order so that it can measure how long they run for or things like that and automate the alternating of turns.


I was thinking the speed should be a factor in grading, but that there shouldn't be a cutoff to kill AIs that are taking too long.

I think that you should just have a speed limit. Say N seconds per tick.

Got two suggestions:

1) Game Reviver - Take your favorite old game (ie Uplink, Portal, even Pong) and reimplement it using TI-BASIC/C/Lua/ASM.

2) DCS7 utilities - using the DCS7 libs, make a useful program that helps users (dictionary, database editor, contact list, etc.) in TI-BASIC/ ASM.

EDIT: Woops, forgot that DSC7 isn't available on Nspire or Prizm!

EDIT #2: Entry #3: Beat Kerm to porting DCS7 to Prizm/Nspire!

I like that idea, although I'm also warming to Spud's proposal about taking an existing, released game and making it substantively better and more awesome.

This would be my personal favorite, although we already had one contest like this.

EDIT #2: Entry #3: Beat Kerm to porting DCS7 to Prizm/Nspire! Be my guest!

"Be my guest!"

Heh, if only I knew assembly reasonably well and had one of those devices in my posession... :3