ActionRPM

Matt Gorelik - mgoreli5@jhu.edu
Tuvia Lerea - tlerea1@jhu.edu
Carlo Olcese - colcese1@jhu.edu
Joshua You - jyou8@jhu.edu

To run our game, go into the directory actionrpm/ and run the command "python 
game.py"

Current Assignment Notes
12/16
To play with a joystick, you must have a joystick connected before running python game.py.

If you disconnect your joystick while playing, I have no idea what happens. Please don't do that. It will probably crash.
We could have fixed this by checking if the gamepad is None every time, but that just didn't seem like it was worth the decrease in speed of our game. So just keep your gamepad plugged in.

What can you do with the gamepad? Play the game! AKA, you can:
Move (Left thumbstick - all 8 directions supported) 
Shoot (A button on Xbox controller, whatever the '2' button is mapped to), 
Brake (B button on Xbox controller, whatever the '1' button is mapped to)

According to https://piazza.com/class/hzmv3b15sn15cb?cid=98, support for anything other than the game itself was not mandatory so we did not think it would be the best usage of our time.

Note: Console output is present because of Pygame's built-in methods (get_axis and get_buttons, which apparently print something to the console every time they are called).

ADDITIONAL CHANGES:
Breaking added ((Left) Shift Key or B button/whatever 1 is mapped to)
Terrible sound effect nixed
Graphics tweaks (fireball animations improved, lag reduced in Level 4)
Refactoring code
Adjust Visual Brightness Added (3 settings & a default)
Adjust Volume Added (slider that sets the volume)
Cutscenes after beating boss & beating the racer

Previous Assignment Notes
11/23
Problem 1) Level 4
We have a BIG drinking problem on campus. Kill the kegs by shooting your fireball (space bar)!

Problem 2) Technical, Artistic and Gameplay Progress
-Added more music/sound effects
-Made some graphics fixes (but also noticed a new bug that we have to work on for next week in terms of how sprites are rendered)
-Implemented shooting fireballs after you kill racer & added more enemies to levels.
-Added new keg enemy that hurts the player a lot. After you kill a certain number of kegs you will beat the level/game.
-Made it possible to get a reasonable highscore
-Made adjustments to our maps to make them make more sense (ie can't drive off the map, stuff like that)
-Cheat code for you! After you start the game, if you press the number 1, 2, 3, or 4, it will transport you to that level. Level 4 is obviously our most recent one.
- Also added markers in level 3 so that a player can know the race path without having to have played it before.

Previous Assignment Notes
11/16
Problem 1) Level 3
We made some pretty serious headway this week. Level 3 is a RACE level where you have to follow around your dad's boss! If you beat him, you get your house back and you're on to the last step of getting your whole entire life back. But if you don't, your girlfriend leaves you (cuz who wants to date a homeless bum?) and you become a depressed mess. So beat your boss! You can do it! The Racer boss lives in the Enemy and shoots FIREBALLS which do damage. He also gets faster & stronger (shooting fireballs more frequently AND they do more damage) as you pass checkpoints.

Ultimately, we're gonna implement a mechanic where if you beat him, you get MAD bonus points and also possibly get to use his gun! (Although we might give you his fireball gun anyways, depending on how hard Level 4 is without it). But for now, if you beat him, you just get a nice little cutscene and a new high score. You also now get a cutscene between level 2 and 3 which is pretty cool.

Problem 2) Technical, Artistic, and Game Play Progress

We made a ton of progress in our visuals. No longer laggy, no longer glitchy when stuff collides. Our radio dashboard looks a lot better now too. We're working on implementing an inventory, although we have a few more urgent priorities before that. We added a bunch of cutscenes between levels 2 and 3. Also, we continued adding music to our game. Our next step is trying to implement a mini-map, although that's proving to be a lot more difficult than we expected. However the module will ultimately be something that the Player can bring up by pressing a key (like the Return/Enter key or something), and it'll show a mini-map over where the Speedometer is for a few seconds, something of that sort. Also we now have a 'shooting' animation (although so far only the enemies can shoot fireballs, because we haven't made level 4 yet, but our cutscenes between level 3 and 4 will describe how you impress the boss, your father lets you back in the house, and you steal the boss's guns). Oh, we also got rid of that heinous screech.wav sound we had before for when you collided with a wall. We're working on finding a good one to replace it.

--NOTE: We need to revamp our scoring system. This will be a simple level where you get points based on how quickly you beat the race (and also how much health you have upon beating it). But for now, our scoring is a little bit whacky. But we will work to fix this in the coming days.

11/9

NOTE BEFORE THE LISTS:
Our Radio may throw a warning on your setup in the console. We posted about this on Piazza and didn't get much of a response, so we're going to assume it's fine, but if this is an issue we can make a demonstration on one of our computers. We think the issue is related to the sound card & installed plugins, but it shouldn't crash and should still work (although the sound may not be as good).

Part 1) List of Things We Need To Do (GAMEPLAY & CODEWISE)
GAMEPLAY:
1) GRAPHICS. Our game looks like it's in a bizarre parallel universe. We're working on making it feel "cartoony" but also real.
2) No music = No bueno. You're a car! How can you not have a radio?? Driving with the music off is miserable. We need to play music.
3) Not really much "exploring" to do - so far the levels we have are pretty simple, and there isn't much depth to the story. While we aren't supposed to add any features, we are going to work on making our future levels larger & have more features.
4) No AI for enemies; they're very predictable. We're going to need to implement a better mechanic for their motion than using an array of repeatable behaviors, because otherwise the game won't have any replayability since it happens the same way every time. We need to implement enemy AI & logic (but this is also going to occur next week)
5) Our crash sound is the worst thing that the world has ever seen. It literally sounds like death. We desperately need to find a good car crash sound and implement it.
6) For now it's not a big deal, but it could get confusing if we don't have an actual inventory implemented. Since we are gonna have a badass HUD, we should display all items in our inventory in the corner there or something.
7) We need to implement weapons! This counts as a new feature so it won't be for this week, but it's going to be one of our first priorities next week.
8) Need to add some depth to our story; maybe even animate a cutscene or something? But none of us are good at art so this might be a challenge, but needs to be done.
9) Might not be incredibly intuitive how to actually kill the boss; because collisions damaged YOU and not the enemy in the previous level, maybe people will be confused about having to ram the boss in level 2. Maybe brief instruction before the level would go a long way?
10) Need a better way to get more points. Right now the high score is based only on how quickly you do things, but we should have some hidden bonuses somewhere that you have to discover.

CODE-WISE (not a list, but a general summary of what we thought needed to get done):
Since this week we weren't supposed to be adding features, many of these are going to be taken care of early next week rather than for this submission. We plan on doing SERIOUS refactoring; we're going to rethink our logical process - stuff like the HUD & Player being reinitialized every level just makes no sense at all. We're going to try to implement a Play state, which will store the Levels (which will all be implementations of a Level "interface") and switch between them appropriately, rather than have a Level1 state that switches to a Level2 state and passes the player, score, and health. Also, it would be much better if the score & health belonged to the player, but even if it belongs to the Play state, that's much better. We are going to make our code a LOT less spaghetti; our previous assignments were pretty much all finalized last-minute and this made our code very difficult to expand upon. We're going to rethink our design and try to avoid breaking everything.

2) Record of what we had to do to make improvements
GAMEPLAY
1) We added different types of wall sprites that resemble an actual sidewalk, we added texture to our streets, and we pretty much made it feel like it's no longer in some strange, strange place. Lots of new images this week, and a lot of changes to our map to implement these.
2) We added a radio module in our hud! We have 19 .midi songs now that play like a CD (or cassette, whatever). This IS a new feature, but it was in the works before this assignment was announced so we wanted to finalize it. Rather than considering it a new feature, you can consider it a part of the HUD (which we already had). Features of the radio: Left plays previous song, Right plays next song, Numpad 0 plays a random song, Up increases volume, Down decreases volume, O (the letter) turns the music off/on. NOTE: With midis, unfortunately, you can't pause using pygame.mixer, so it stops the playback and then if you hit O again, it will play the next song (can change to current song if you think that's better)
3) We made our map bigger and added ways to get points (this also applies to #10 - the EZ Pass, for example)
4) We did this for our boss. He now chases the player. We didn't do this for all enemies, but we considered different ways of making it work. One idea was trying to get as close to the Player as possible linearly (so calculate the distance, and move in the direction closest ... but then we run into the issue of obstacles. So then we thought about calculating whether or not there are obstacles in the way every update cycle and then calculating a path). We need to think about this.
5) Found a good crash sound to replace ours. Thank the lord, now we don't have to mute our game whenever we play.
6) We haven't done the drawing for it yet, but a Player now has an Inventory which is just an array of Collectables (which we had to implement to make this possible).
7) We're going to be able to add "spikes" to the front of our car, you get those by killing the boss. They make you immune to damage from the front and increase the amount of damage you do.
8) Instead of just instructions, we now have a couple of cutscenes before Level 1. But we haven't made the animation for it or anything.
9) Done.
10) See #4.

Most of our changes were either related to graphics or our code design. We wanted to put ourselves in the best position to succeed moving forward, so instead of making sure that we do everything in our check list that we talked about, we wanted to make sure our code base is organized, readable, and well-commented so that any of us can make changes to it moving forward. As mentioned in our To Do list, we did a lot of refactoring and restructuring of our logic. It's difficult to describe each of our changes, but the Git commits should be able to tell the story. This was actually one of our busiest, most productive weeks code-wise, despite the fact that we weren't supposed to add any new features.

3) Pep8 is happy. Pylint is happy about just about everything except "spelling". We used conventions (underscores, etc.) so we're not concerned about the quality of our code moving forward. We also ignored "parameter unfilled" warnings because they don't actually mean anything according to the Python documentation.


4) Our art isn't all that great, but it gets the job done and fits our style. We will continue to improve as we make progress.

11/2

Problem 1: Level Two (60%)
For this assignment we added a second level to our game. The second level is
only reachable through the ezpass booths on the top right of the level 1 map.
When the player collects the ezpass and goes through the booth, level 2 begins.
Right now there is no way of returning to level 1 but that will be implemented
soon. The idea for level 2 is there is a boss that must be defeated. This boss 
follows and tries to attack you. If he succeeds and hits you, you get dealt 
damage. Every couple of seconds the boss will stop moving and flash. During that 
time you can attack the boss, if you do, you will damage him. When you kill the 
boss, you beat the level, and since there are only two levels, the game. 

Problem 2: Technical, Artistic, and Game Play Progress (40%)
For this part of the assignment several different things were added/changed.
First off, a lot of the graphics have changed. The roads now look nicer, and the
buildings are still in a working progress, but they are getting there.
Additionally, a HUD was added. Right now the only element of the HUD is the
speedometer, but we plan to have a radio station added, and there will be
information about that in the HUD as well as your inventory, and maybe even
weapons available. The HUD is on the bottom of the screen and besides for the
speedometer is black. Additionaly, the controls for moving the player have been
moved to a standard awsd as well as a break implemented with the space bar. 


10/26

Problem 1: Level One (70%)
For this assignment, we didn't have to change too much in terms of our level 
design. We want level one to be a tutorial level in which the player can get 
familiarized with the mechanics. There are two enemies, one "protecting" the 
Toll Booth (discussed later) and one circling the EZ Pass.

Our cutscenes are kind of lame, but we demonstrate that we know how to build 
them & animate them, which establishes a framework that we will confidently be 
able to follow as we continue our development. We explain the backstory (of why 
you're in a car doing random tasks), and give the player instructions on how to 
beat our tutorial level (and how to avoid losing).

Problem 2: Technical, Artistic, and Game Play Progress (30%)
We made some pretty heavy changes this week, mostly from a technical 
standpoint. While previously we didn't really have much discussion or 
collaboration, which led to people writing Spaghetti code that couldn't really 
be extendable for future development, this week we spent some time developing a 
plan of attack. We did some heavy refactoring, which makes our code easier to 
read & understand. We also developed interfaces for Item (something you can 
collect, IE the EZPass, which goes into an inventory) and Openable (the 
EZPass), which is a Tile that can be opened. We made improvements to our 
graphics by having different types of Street tiles and fixing bugs about 
player/enemy sprites having outlines.

We discussed how we will continue to work with scrolling and concluded that we 
will use the Tile mechanics which we built. We also added a spedometer which 
will be part of the HUD Layer which we wanted to implement, but due to time 
constraints probably will not get to until next week. We also made it possible 
for our game to include Triggers by creating the Openable & collectable (Item) 
interfaces; we can have an invisible Item, and when it is present in a player's 
inventory, something Openable can open or an Enemy's AI can change.

We also added some music, got rid of that horrible crash sound, and improved 
the visuals to make our game a more fun experience.


Previous Assignment Notes
10/19
Problem 1: Enemies

We have one main enemy, guarding the garage. He moves in a 4-step cycle around 
the garage and hitting him does significant damage to your car & severely hurts 
your score. This is akin to how most of our enemies will act; they will move 
cyclically around our map & doing damage upon contact.

Problem 2: Damage, Win, Lose

We have a system in place for damage & a system in place for score; the two are 
now separate. Health starts at 100% and as your player collides with walls/the 
enemy, his health declines. As the health drops below 75%, the label turns 
orange, and when it hits 25%, it turns red indicating that you are getting 
close to dying. Once you hit 0%, your game ends.

The other system is the score. The player's score starts at 1000 and decreases 
every update cycle. It can be increased by getting keys. It also decreases when 
you collide with a wall. Your score is the score you have when you are done 
collecting the keys & entering the garage. If your score goes to 0, you also 
lose.

Problem 3: Scores High & Low

High score system has been implemented. You get points & if you win with a high 
score, you get to enter your name and enter a high score. Cool!



Problem 1: Level Zero

We have built our level using 9 screens (1.txt through 9.txt in the map/ 
directory). The overlay is something like:

______________________
|                     |
|  SSSSSSSSSSSSSSSG   |
|  S              S   |
|  S              S   |
|  S              S   |
|  S              S   |
|  S       SSSKSSSS   |
|  S       S      S   |
|  S       S      S   |
|  S       S      S   |
|  SSSSSSSSSSSSSSSS   |
|_____________________|

The Key is the key, and the Garage is the G. Feel free to drive around the map 
and explore. You have to grab the key before you go into the garage. When you 
enter the garage, if you did it faster than the 10 previous fastest times, you 
will be given the high score screen.

Problem 2: Camera and Scrolling
We do scrolling by keeping the player's position constant unless the map cannot 
scroll anymore, in which case he moves around the screen. This introduced a 
minor bug which we are looking to work out where the player is slightly "in" 
the wall when he collides. However, we took care to ensure that he never gets 
stuck in the wall and can always move in the opposite direction. To avoid 
needing thousands of collision checks, our Map class has a function to return 
the set of tiles within 5 tiles of the player's top left corner.






Notes from assignment 4:
For this assignment we believe we completed everything. For the animations, we 
have that our car continues to get more
and more damaged as he loses health. You will notice that when he gets to a 
lower health (~20%), he will look as though
he is all banged up. In order to lose health, try to move the player outside of 
the game screen. For the other animation,
we have our enemies headlights flashing on and off.

For part 2, we used the states model to create our screens. We believe we 
followed all of Oeter's instructions.

NOTE: Our high score does actually work! For now, your points keep moving 
upwards as time goes on. When you run out of health,
our game will check if your score is higher than any of the saved scores, and 
if so, you can enter in a name for the high score.


The code is organized into directories/packages:
-audio: contains audio files for the game (will probably be organized into 
subfolders later)

-images: contains image files for the game (organized into sprites and other 
images)

-sprites: contains python code for any of our custom implementations of 
Pygame's Sprite class (currently, Enemy, Label, and Player) 

-states: contains python code for all of our state-model logic. Play.py is our 
gameplay state. All of these classes are named intuitively and should be simple 
to find out how they interact. One note is the Menu state can always be 
accessed from any State by hitting 'Control + M'. The Play state can be exited 
at any time by hitting the 'q' key, which ends the game (even if you don't have 
0% health).

-util: contains the code to parse a SpriteSheet, which is currently being used 
to animate an enemy.


Notes from assignment 3:
-Our animations are: the car (player) is 'animated' in the sense that as it 
gains damage, it progressively gets more and more banged up. The three 'stages' 
of health are full health (100-75%), moderately damaged (75-25%), and severely 
damaged (25-0%), and these are represented by the color changing label and also 
the more damaged-looking sprite. The player's sprite also changes based on the 
direction in which the player is moving. The enemy sprite responds to the 
player's keypresses and instantly faces the opposite direction (NOTE: his 
motion can reflect the direction he's moving by modifying the 
should_change_motion_direction flag in Enemy.py). Also, the enemy's motion 
involves a headlights cycle in which his headlights toggle from off to half-on 
to on to half-off to off again, and this repeats indefinitely.

-Our high score system is based solely on the duration a player has been able 
to survive. Since our interval is 0.01, every update cycle raises the user's 
score by .01. When a game ends (either by the player reaching 0% health by 
colliding with the walls, or by hitting 'q' from the Play screen), the game 
checks if this score is a high score (top 10), and if it is it prompts you to 
input your name, then showing your position on the high score chart by coloring 
your text green. Otherwise, it displays the game over screen and shows you all 
the previous high scores.

Notes from assignment 2:
-We chose to follow the leftover-interval based approach so our gameplay should 
not change depending on the hardware. 

-Note that game.py has a few constants at the top (BEEN MOVED TO 
states/Constants.py). These can be changed, but the game has not been 
extensively tested with settings other than the ones we are submitting (800 x 
600, with PLAYER_SPEED = 500, ENEMY_COUNT = 13, and ENEMY_SPEEDS = 6), with a 
difficulty of 10 and interval of 0.01.

-Also, if you want to see how our game worked before (with enemies moving away 
from the player), feel free to change should_change_motion_direction = True in 
Enemy.py (line 8).

-The original red & yellow car sprites were found on openclipart.org, and the 
policies can be found here: https://openclipart.org/policies . The 'damage' art 
was added by our team after the fact.