agkountis / gfxi Goto Github PK

• Study Json parsing libraries.

• Create a sample program that parses a configuration file.

• Create System Skeleton
• Create Behaviour Component
• Only Behaviour component contains Steup(), Update() and Teardown()

• Player movement

• Keyboard controls

• Shooting mechanism

• Weapon logic

• Multiple players

• Player behaviour shoot response

• Pickups weapons

• Health bars

• Multiplayer logic LOCAL

• Multiplayer logic P2P

• Lobby & Menu both local and p2p

• Menu

• Credits

• Audio

• Socket abstraction

• NetworkManager

• Study serialization libraries.

• Integrate it in the engine.

Windows utilises "stdafx.h" as a standard precompiled header file (the file name can be modified under project properties, but the option to include PCHs is simply Boolean) to allow the compiler to avoid recompiling system headers time and time again when building a project. This will speed up compilation time anywhere from slightly to a lot.

We would need to ensure this only applies to Windows specific code (a good rule of thumb is anywhere a HWND is used), I haven't checked the Orbis toolchain yet, but I'm assuming it's GCC, so setting this up on PS4 will be very different.

Proposal is to use #ifdef to differentiate platforms.

Implement the connection and play multiplayer using the engine peer-to-peer architecture.

Create the Basic project skeleton.

• CameraSystem

• CameraComponent

• Viewport implementation (abstract/concrete per system).

• Implement behaviour component and system.

• Move the behaviour already implemented in behaviour components.

• Move the teardown and setup functionality from the Entity to the Behaviour system.

• LightSystem

• LightComponent

• 3 light descriptions

• Manage how to send to shaders.

Create a Player class which is an entity.
The configuration file will contain the local player's information(name, colour,). Additionally it will contain the information of all the peers it is going to connect to.
The application will load all the players' information and store them in some kind of map.
When a new player connects the name and colour will be fetched from the local storage and will be handled locally.

• Port input skeleton implementation to the blade engine

• Port joypad functionalities

• Adjust friction and response

• Add bit-mask for collisions

• Add different models

• Create emitters configuration

• Attach new emitters on pickup

• Create emitters on collision

• Change particle system implementation

• Weapons damage

• UML of the input system
• Imlementation of the Input system.

• Emitters component

• Particle system (behaviour) -> Update the particles

• Shader in the battleArena

• Last color pass (BattleArena) with particles rendering.

• Our gitignore cut out all the .lib files, so: we decide to put the .lib file in deps or we add the $(DXSDK_DIR)include;

• The release configuration isn't setted: neither library directory nor include directory.

Based on https://gamedevelopment.tutsplus.com/tutorials/building-a-peer-to-peer-multiplayer-networked-game--gamedev-10074

Implement the skeleton of a basic weapon component. With the shoot functionality.
Multiple weapon components can be attached to the same entity.
Create a skeleton of a player entity class -> Maybe getters and setters for the weapons.

Implement the rendering system of the engine.

Implementing scene FSM with menus.

The component has a static int and uses that as the unique id.
This integer gets incremented each time a new component is constructed and as a result the ids change for all the components.

The component id needs to be unique.

When spawn rate is one, the emission of particles doesn't work (it emits 2 particles and then stops)

• Add missing Doxygen (04/06/2017)

1. Document

2. Video