Board Thread:General Discussion/@comment-24454571-20140204220440/@comment-24454571-20140509064643

Pixel-Voxel wrote: Your ideas are perfect for an environment like PTC. The gameplay concepts are simple to an extent and they don't sound boring in the slightest (at least for me). It doesn't sound like to much of a pain to code and this game would be a great start towards some of your more ambitious projects.

Also, this art approach makes me think this game leaves a lot to the imagination. Everything's just a block and yet it still represents something. I just... think it might be a pain to have to use GPSET for this... I'm unsure about a lot of things, like the exact variability of using commands like GPSET to accomplish tasks, like randomly grow grass on brown tiles, or to maintain a board filled with brown tiles, in the even that grass is eaten, etc.

I imagine that the players' codes would look something like this Erase Old Pixel, Relsolve issues with leaving tile?. Create New Pixel, resolve issues with entering new square.

Despite how little I actually know or am capable of putting things together to some novel end, I am eager to have the next 'ephiphany' if you will, of 'getting ideas'. - as when I created many loops to detect button presses within some frames and not others - that's really what inspires me to seek simplicity, was physically watching as thousands of lines of code looped within a very short time span. I thought, maybe there's more I could be aspiring to do with my codes with to make use of this incredible potential.

From my limited understanding, I imagine a code that I'm interested in making would looks something along the lines of... Loading the next however many variables that account for the screen panning in one direction, then checking many many times for user inputs, just to make sure that the users inputs are being taken nearly constantly, also periodically counting on a 'Timer' so that if any AI operated in tandem with that Timer, they would act on the appropriate time, then once it's detected an input stopping the program from accepting any more inputs until perhaps the next 'duty' of configuring the screen, or any of the game elements, which could be, in the example of a Mario like game for example, the player continued to progress towards one edge of the screen, then the screen would continue panning.

I think people may have figured out more sophisticated methods of doing similar things than I've come up with, in my vague description - Brizobst came up with a pseudo-Mario platformer that I should really be taking a closer look at.

If I could do some of those things though, even within the scope of single pixels, then I think I would be much more confident in my ability to use the machine - there are so many hang-nails of coding, though, and generally deceptive scenarios that can obscure one's understanding of what's happening - while I was detecting button presses within 1,000ths of frames, for example, the code that I used to "Detect" the button presses fired off thousands of times, as well, instead of just once as I had expected by using the appropriate BUTTON command - I never figured out how to prevent that while using 1,000ths of loops, though, because people simply told me to use VSYNC in the code - but I'm still curious about stream-lining the code to work with thousands of loops not using VSYNC.