Luís Miguel Correia - up201503342 ; Ventura de Sousa Pereira - up201404690

This one is the main class, where all the other classes are called.

This package contains all the game's logic and physics engines.

This class contains all the 2D physics in the game: it creates bodies and physic worlds. It handles collisions (implements a ContactListener from the libgdx library), impulses, forces (ex: gravity) and shapes. This physics engine is based on the libgdx extension, Box2D.

This class as all the logic around the game. Examples: dying when th health bar is empty, proceeding to the next level, beating a boss.

This class handles all the input made by the user, triggering animations and manipulating the physics world.

This is a abstract class that represents a screen of the game. It renders the background and all the layout of the screen. A screen will use a Screen from the libgdx library.

This screen will be a level of the game, it will have a map, textures and sprites.

This screen will be the menu screen, it will have buttons to navigate the game's structure, changing settings that suits the user.

This package contains the entities of the game: the Samurai, the enemies and the bosses.

This class has the sprites of the samurai and the Samurai body. The sprites are used for the Samurai's animation (jumping, walking, attacking).

This is an abstract class for the various enemies in the game. All of them have sprites, animations and a body.

This is an abstract class for the bosses in the game. Like the enemies, bosses have sprites, animations and body, but they also have some extra features as health bar, weak spots and attacking patterns.

The Engine Package and the main class are singletons. The SamuraiGame, Engine and GameController will be easily accessed

The Samurai Class will use a State depending on the user input.

The update method will be used because most of the objects are independent from one another and there's several objects running at the same time. This will enable the game to run smoother.

The template pattern is already used by libgdx. Therefore, the SamuraiGame class extends Game. The main loop is the same in every game. It runs until the user wants to quit, it handles input, updates the models and renders the displayed frame.

The observer pattern will be used to check for collisions. The physics engine will use a ContactListener from the libgdx library.

• Title
• Level option
• Link to Settings Menu

• Sound options
• Brightness option
• Fullscreen option

• Link to Settings Menu
• Health bar

• Meele collisions
• Projectile collisions
• Saving progress
• Killing enemies
• Killing bosses
• Bosses attacking pattern according to their health bar
• Checking bosses weak spots
• Game Over
• Transitions between levels

Setup/Installation:

Our project uses libgdx's library, being generated throught it. However, even though, in our executable, one of our components (music) is fully functional, in the compilation of the project, if in other computers but the one who implemented it, an error appears- which doesn't stop it from running. To play/run our game it's only necessary to execute the jar.

We decided to use fragments, in order to ensure the smoothness and good function of the game.

Our AI is implemented through this method. Both our bosses inherit the class Boss. This class has a move function, that varies depending on which type of boss is activated.

We have a class that creates the game, our instances. Only one instance of it can exist.

Our bosses and our hero have states that alter their behavior accordingly.

During this project we had some difficulties. In the early stages of development, we had some troubles getting used to the new library. Trying to implement the necessary requirements, we came across some challenges, such as the way collisions(the physics) were supposed to work, how to associate a fixture to it's sprite. Eventually this all led to some troubles trying to compose the MVC structure - we believe we haven't been keen on doing so. Furthermore, we had some issues trying to construct a competetive game due to the choice of it's category. Being a platform based game, we came across doubts whether was it competitibe enough or not. Lastly, due the MVC difficulties it was hard for us to run tests, as our view is somewhat connected to our model.

We believe that the biggest lesson we learned was about planning.

Even though we managed to create the game we wanted through good planning, we are convicted that we should improve our pre-development effeciency. Specially when it comes to the clear separation of a game's/program's components - Model , viewer, controller. Nonetheless, we also comprehend the need and how to get used to new working enviroments.

87 hours, approximated.

Luís Correia (50%)

• Sprite implementation
• Physics logic
• Box2d implementation
• Javadoc Ventura Pereira (50%)
• Screens
• Physics world
• AI
• READ.ME

This will appear when you run it. Use your mouse to click on it and start.

You'll be redirected to the screen!

To pause, press 'E' and you'll go to here

If you desire some tips to overcome your opponents, press the middle button