Page 1 of 1

Playtesting and Prototyping (especially with a game board)

Posted: Sun Oct 27, 2013 2:04 pm
by Imperial
So, we are working on a game for NES! And while I'm working on the programming and learning the ins and outs of NES (currently have a build with a plain grey screen, so yeah...) we decided to design and play test the game using a set of dice, some charts and notes, and that Super Mario Bros chess set you can get at various stores for $20 or so.

The idea is that while we can't handle the free spacial movement of sprites in the final game, we can determine whole outcomes somewhat randomly with separate dice. An algorithm or logic diagram could be written up to describe the game at any given moment, and code could be written up from that. Even if the program doesn't work ever, we may end up with a playable tabletop game instead. Win!

Anyone else do it this way or something similar? I'm just curious. :)

Re: Playtesting and Prototyping (especially with a game boar

Posted: Sun Oct 27, 2013 2:42 pm
by tepples
Sometimes I prototype things in Python before translating them to assembly language.

Re: Playtesting and Prototyping (especially with a game boar

Posted: Sun Oct 27, 2013 9:44 pm
by Imperial
tepples wrote:Sometimes I prototype things in Python before translating them to assembly language.
Nice. Btw, I've written a script in Lua where the assembly as a whole is an object. This object has a method for each 6500 instruction. I've gone a little overboard with that in trying to mimic a 6502 processor, with members for the registers and a hash table for previously accessed memory locations... But that's a little flawed and I'll probably have to trim that away.

What this assembly object does is keep a record of each line, and it attempts to track the size as well. It also has a 'write' method to iterate through the lines and write to a string, which it returns, and which can be printed to standard output or written to another file.

You can pass this assembly object to other functions and let them call its instruction methods, and thus break down assembly code into much more manageable parts. Things that are a little harder to do in assembly could be passed on to Lua to some extent. Essentially, the Lua code builds the assembly code, and of course something similar could be done in Python.

And that's how the game is built. :) link.