Using the TIC-80 fantasy console simulator on your pi, implement a playable puzzle game, making sure to make use of the following features:

• controller buttons iOR mouse iOR keyboard
• audio (sound effects, music)
• sprites

The game itself can be something unique, or can draw influence from, or can be an outright mimicking implementation of:

• TETRIS
• Dr. Mario
• picross

The idea is to demonstrate your skills gained throughout the semester, by harnessing new concepts and problem solving experiences to pull off a program generally more complicated in its nature than others you've been doing.

You may want work out approaches by hand on paper to understand their details and steps of progression, then to implement it.

Additionally, the entire class will be participating in documenting and filling out this project page. It is the responsibility of EACH class member to:

• ask copious, clarifying questions (so you can better add content)
• craft a coherent and organized document, with information located under pertinent headings
• explain the fundamentals of the process, conceptual background, algorithmic approach, and you can even suggest particulars related to TIC-80 (certain functions that might prove useful- individual, unrelated snippets to do things like capturing time, or displaying text, etc.)
• to get full credit, each individual that submits must perform no fewer than 4 changes to this document as viewable from the wiki revision system (failure to do so will result in documentation penalties being applied)

As is common practice, your game may require the use of multiple screens. That is, you may want to include a title screen, death screen, and other such differing states of the game. Especially in the weeks of saf# and pnf#, it became quite apparent that the ability to present the user with varying screens was useful in order to convey relevant information as well as provide relevant functionality at different stages in the execution of our programs. This has led to the development in several examples of what may be called stateful programs where a variable is reserved in order to keep track of what screen should be displayed. By referencing that variable using some form of a switch statement, more organized functionality is achieved by compartmentalizing each individual screen to its own logical corner.

It is important to keep in mind how game ticks affect your ability to display different screens, what screens should be given priority? Should my screens have their own separate functions? these are important questions to ask yourself as you implement these things. It would not be wise to implement too much inside of your 'TIC()' function as that may cause clutter and confusion.

The key mapping system allows for keyboard controls as well as gamepad controls to be merged as the inputs are mapped to a set of constant values. This allows we as developers to develop for both keyboard and gamepad users simultaneously without much additional consideration except for ergonomics.

For said constant values, the bare minimum would be the x and y coordinates of the player “character.” If you wanted to start your sprite at (0,0), then the X and Y values would be 0, respectively. Keep in mind that the base sprite is 8×8 pixels, and these coordinates are also in pixels. So, if your map layer had a special spot on its 3rd sprite from the left and 1st from the top where your character starts the game, you would have to draw the sprite at (24,8) and not (3,1). You can also code it as (3*8,1*8) so it is easier to adjust the coordinate(s) without having to worry about the constant sprite dimension of 8. This can be adjusted to (x*8,y*8) for even greater ease.

In order to achieve a more natural sound than TIC80 provides in its waveforms by default, mocking a sine wave in the SFX editor and using that for your SFX is a decent strategy. It is also helpful to mimic the attack, decay, sustain, and release pattern in the volume section, as well as to add a small amount of arpeggio. Combining these strategies, a more instrument-like sound can be acquired.

https://github.com/nesbox/TIC-80/wiki

https://github.com/nesbox/TIC-80/wiki/Simple-Platformer-tutorial

https://www.lua.org/pil/contents.html

https://github.com/nesbox/TIC-80/wiki/palette

https://www.youtube.com/watch?v=V9oAccwjeDA

To submit the game file, our “tic” file, the file must be added to your lab46 somehow. This can be achieved through FTP software, such as FileZilla, or more easily by putting the file onto your Pi then pushing to your repo and pulling from lab46.

Of course, if you are using the TIC-80 application on your Pi then the file will exist there when saved.

To submit this project using the submit tool, run the following command at your lab46 prompt:

lab46:~/src/SEMESTER/DESIG/mpg0$ submit DESIG mpg0 GAMENAME.tic
Submitting DESIG project "mpg0":
    -> GAMENAME.tic(OK)

SUCCESSFULLY SUBMITTED

NOTE: “GAMENAME” here is the name of your game. Please do not literally submit a tic file named “GAMENAME”, come up with a creative name for your game.

I'll be looking for the following:

104:mpg0:final tally of results (104/104)
*:mpg0:no errors, program runs without issue in TIC-80 [13/13]
*:mpg0:specified functionality is implemented [39/39]
*:mpg0:adequate use of sprites, sound/music, controls [26/26]
*:mpg0:project page contributions as per project specifications [26/26]

Additionally:

• Solutions not abiding by SPIRIT of project will be subject to a 25% overall deduction
• Solutions not utilizing descriptive why and how COMMENTS will be subject to a 25% overall deduction
• Solutions not utilizing INDENTATION to promote scope and clarity will be subject to a 25% overall deduction
• Solutions lacking ORGANIZATION and are not easy to read (within 90 char width) are subject to a 25% overall deduction