With an empty virtual void Update() method in the baseobject class we make sure we can call Update() to all object (wheter they have an implementation or not) ensuring compatibility with foreach and the like.

Then implement a basic Update() method inside GameObject that uses Velocity to update the position of the GameObject. Consider if it's needed to add a further speed float to further modify it like Velocity * speed (or for instance to quickly stop an object from moving with speed = 0).

Currently each Update() inside Command.cs will check for both SinglePress behaviour and ContinuedPress. That happens even if, for instance, only a SinglePress event has been linked to the handler.

Optimize this workflow in order to avoid checking for unwanted events.

Currently the Particle Engine only has one way to emit particles, the default GenerateNewParticle() method.

Devise a system to accept ParticleEmissionType so that one could configure his own "GenerateNewParticle()" methods iniside a separate ParticleEmission file (implementation of ParticleEmissionType) and then make the ParticleEngine constructor accept that file:

// Example
particleEngine = new ParticleEngine(textures, SmokeParticle(),Vector2.Zero);
particleEngine2 = new ParticleEngine(textures, SparksTrail(),Vector2.Zero);

The input handler will take care of creating Commands and updating them.

For example

// Create a InputHandler
InputHandler inputHandler = new InputHandler();

// Setup the GamepadX that will fire once
gamepadX = new Command(Command.GamepadButton.X);
gamepadX.SinglePress += GamepadX_SinglePress;

// Add commands
inputHandler.AddCommand(gamepadX);

// Update ()
inputHandler.Update(gameTime);

Mainly the inputHandler would take care of storing a list of commands and to update them all.

public void InputHandler.Update(Gametime gameTime)
{
   foreach(Command command in Commands)
   {
      command.Update(gameTime);
   }
}

Adding a module that contains some helper methods for the vibration.

GamePad.SetVibration(PlayerIndex.One, newGamepadState.Triggers.Left, newGamepadState.Triggers.Right);

For instance something that can vibrate both rotors for a given time or strenght:

// Vibrate for 5 seconds
Gamepad.Vibrate(5f);

// Vibrate for 5 seconds with intensity 0.4
Gamepad.Vibrate(5f, 0.4f);

At the moment the Command.cs module do not support the analog input from Thumbstick and Triggers.

Add this. For example:

// Move Kokichi with thubsitck
float maxSpeed = 10.0f;
Vector2 thumbMove = new Vector2 (newGamepadState.ThumbSticks.Left.X * maxSpeed, newGamepadState.ThumbSticks.Left.Y * maxSpeed * -1.0f);

kokichiPos += thumbMove;

// Use lefttrigger to do change kokichi scale
kokichiScale = newGamepadState.Triggers.Left + 1.0f;

// vibrate left and right rotors with triggers
GamePad.SetVibration(PlayerIndex.One, newGamepadState.Triggers.Left,      newGamepadState.Triggers.Right);

Rather than use puush to have images in the documentation, put them in a Documentations/Images folder on the repository itself.

Currently Command.cs deals with both Keyboard and Mouse events with an hybrid solution of two constructors.

It would be better to make the Command class abstract and then create two subclasses: Keyboard (with the current keyboard constructor and dealing with keyboard events) and Mouse (with the current mouse constructor, dealing with mouse events).

In my current Monotest project I have some basic functionality (Particles, Sounds) that should be moved to here.

It's all very basic, but I think that doing the next tutorials and learning Monogame using my Arta2DEngine as a base (and creating new engine related tasks directly inside it) is going to be good to start building its foundations.

From here: https://bitbucket.org/C3/2d-xna-primitives/wiki/Home

Add credits somewhere!

Update UserGuide with Button class and UI Framework.