This first piece will be my initial design plans for my Lights, Camera, Action/RPG project (or rather, projects) – discussing some thoughts, some initial ideas on gameplay and development, etc. Readers will notice that my development style is very iterative – I don’t like to plan things out too detailed ahead of time, because it screws me up in the end, when I find a more efficient way of implementing a system. I prefer to focus on certain portions at a time, building on and optimizing what was present before.

Here is the first part of my build process – determining my initial plans.

As far as the design of the game goes, I intend to make the prototype an isometric, third-person 3D Action/RPG, much in the style of Titan Quest, Diablo, Torchlight, and similar games. I plan to use a cel-shaded graphics style, and will be using bright, stylish colors for characters, items, monsters, and spells along with dark, murky environments and static geometry to give a slightly contrasted mood in the game.

Character Classes
I’m planning on implementing three classes, each with a specific role in the game. These are Wizard, a ranged caster class that focuses on controlling/restricting enemy movement and area-of-effect damage spells, Warrior, a melee fighter that brings large blades to bear against hordes of enemies, and the Scout, whose focus on stealth and fast attacks allows him to quickly eliminate targets.

Multiplayer
I am planning on implementing a cooperative, multiplayer game mode. It will be a party-based gameplay system, played with two to four players over either remote internet connections or a local LAN. The Torque 3D version of the prototype will utilise the internal networking library, while the in-house engine will likely use the RakNet Multiplayer Game Network Engine.

Bye-ni~!

Sample use of the Virtual D-Pad Component

Just finished working on a pretty basic virtual d-pad for the Zune HD/XNA Framework 3.1. It’s really rough around the edges, and certainly isn’t optimized, but it works.

Download
Source
DPadHD.dll (Managed Library)

Description
A simple, kind of messy virtual d-pad for your ZuneHD games. You can feel free to add it to your games, with or without crediting me, just don’t distribute the D-Pad or modifications of it without at least giving word that it came from me. It’ll need a fair bit of optimization and editing before it’s ready for any game that you wish to distribute, however.

Features
Position can be configured
Works similarly to the default XNA input systems
Built as an XNA DrawableGameComponent

Usage Sample

			dPadManager = new Segfault.DPadHD.DPadManager(this);
			dPadManager.Landscape = true;
			this.Components.Add(dPadManager);

Creating the system is easy. First, you create it as you would any other component. You can set whether or not you want to use it in Landscape mode (which merely rotates the inputs counter-clockwise – I assume a “back-button-to-the-right” landscape view) by setting a simple boolean value, and then you add the D-Pad Manager to the components list. It will update automatically, just as the XNA input managers do by default.

Its position can be set on screen with the following code:

dPadManager.Position = new Vector2(50.0f, 12.0f);

And finally, the state of the D-Pad’s four cardinal direction buttons can be checked by retrieving the current game state:

if (this.dPadManager.GetState().IsButtonDown(Segfault.DPadHD.DPadButton.Up))
				pos.X += (gameTime.ElapsedGameTime.Milliseconds);

			if (this.dPadManager.GetState().IsButtonDown(Segfault.DPadHD.DPadButton.Down))
				pos.X -= (gameTime.ElapsedGameTime.Milliseconds);

			if(this.dPadManager.GetState().IsButtonDown(Segfault.DPadHD.DPadButton.Left))
				pos.Y -= (gameTime.ElapsedGameTime.Milliseconds);

			if (this.dPadManager.GetState().IsButtonDown(Segfault.DPadHD.DPadButton.Right))
				pos.Y += (gameTime.ElapsedGameTime.Milliseconds);

Enjoy. :D

Starting out with the Nuzelock Challenge in Fire Red

So, I’ve started reading a friend’s blog recently (http://www.walnut100.com </shamelessplug>), and he’s started playing through a hacked version of Pokemon Emerald doing something called a “Nuzlocke Challenge.” I’m guessing that the name originates from the user who first came up with the challenge (or something), but here’s the basic rundown:

You play through a Pokemon game, but you add some personal, arbitrary rules to make it more challenging:
1) If your pokemon faints, it is “dead” and must be released. If all of your pokemon die, the game is over.
2) You can catch only the first pokemon you encounter in each new area.
3) No healing items may be used outside of battle.
4) You must use the SET battle mode, meaning you can not change your pokemon while opponent is switching (when you knock their pokemon out)

He’s added the following house rule, which I think I’ll play around with, as well:
-) If you white out at any point in the game, it’s game over

Since I’m already pretty far along in Soul Silver on my DS, I decided I’ll run it through Pokemon Fire Red, and I’ll be publishing my progress here. This is going to be a pain in the ass. >.>

Downloads
Please note that I’ve switched to using 7-zip in place of WinRAR for compression
Binary Only (20.4KB)
Full VS2010 Project Dir (26.8KB)

SVN Repository
As of this tutorial, I have created and added a Subversion repository on Assembla to store the code for the tutorial series. I will continue to upload the source for each tutorial – the SVN will merely contain the code as I write it, so you can feel free to play around with the code that I’m working on before I release a tutorial. Mostly, this is to help people play around with things if there’s a point where I’m slow to create the tutorial following the code (as was the case with this tutorial).

SVN URL: http://svn2.assembla.com/svn/d3dpong

Starting Words
Notice: This tutorial continues from where “C++/D3D Pong Tutorial 03” article left off. Please read it if you have not already.

Libraries
You will need to add a single library to the project to build with the code in this tutorial:
dinput.lib

Code Listing 1: CInputManager.h

#pragma once

// Global Header Files
#include <Windows.h>
#include <d3d9.h>
#include <d3dx9.h>
#include <dinput.h>

// Local Header Files
#include "CGameEngine.h"
#include "CKeyboardState.h"

namespace D3DPong
{
	class CInputManager
	{
	private:
		/** Constructor & Destructor **/
		CInputManager(void);						// ctor
		CInputManager(CInputManager const&) { }		// copy ctor
		~CInputManager(void);						// dtor

		static CInputManager* _instance;

		// DirectInput Devices
		LPDIRECTINPUT8			_device;	// Core DirectInput Object
		LPDIRECTINPUTDEVICE8	_keyboard;	// Keyboard

		// Keyboard-related Variables
		CKeyboardState* _preKeyboardState;
		CKeyboardState* _curKeyboardState;

		// Device Initialization
		bool initKeyboard(void);

	public:
		/** Singleton **/
		static CInputManager* Instance(void) { return CInputManager::_instance; }

		/** Public Functions **/
		bool Init(void);
		void Update(void);

		/** Keyboard Functions **/
		bool IsKeyDown(int);
		bool IsKeyUp(int);
		bool WasKeyPressed(int);
		bool WasKeyReleased(int);

		/** Accessors & Mutators **/
		LPDIRECTINPUT8 GetDevice(void) { return this->_device; }
		CKeyboardState* GetCurKeyboardState(void) { return this->_curKeyboardState; }
		CKeyboardState* GetPreKeyboardState(void) { return this->_preKeyboardState; }
	};
};

Here is the framework for our Input Manager. Again, we’re back down to lower source sizes – because we’re not trying to implement the world here. As we did with our Game Engine class, we’ve turned our Input Manager into a singleton – we only want one of them to be created throughout the application.

		// DirectInput Devices
		LPDIRECTINPUT8			_device;	// Core DirectInput Object
		LPDIRECTINPUTDEVICE8	_keyboard;	// Keyboard

		// Keyboard-related Variables
		CKeyboardState* _preKeyboardState;
		CKeyboardState* _curKeyboardState;

		// Device Initialization
		bool initKeyboard(void);

The first two variables are input devices – the first, as with our Direct3D object, we have an object that we will use to access the DirectInput system. The second is the actual object that we will use to access the keyboard device – when adding a Mouse or a Gamepad/Joystick, you will add another LPDIRECTINPUTDEVICE8. If you’ve noticed the 8, you’ll notice that this is something from DirectX 8 – DirectInput hasn’t changed since then. In all honesty, the use of DirectInput isn’t recommended by Microsoft, but it will suffice for our purposes. We then add two variables to store the keyboard state – the current keyboard state, which will contain the state as of the current frame, and the previous, which will (if you haven’t guessed) store the state of the last frame. We do this so that we can not only check whether a key is currently being pressed, but also whether it was pressed or released between the current and last frame. This makes things easier on us, in the long run, because we can wait for (for example) the escape key to be released before we end the game, and it will make managing our game menus much easier when we want to handle selection of menu options game console style. Finally, we define a private function that will initialize our keyboard. It will help keep our Init() function tidy for the future addition of controllers, mice, and other input devices.

		/** Public Functions **/
		bool Init(void);
		void Update(void);

These two functions are pretty obvious in what they do. Init() will initialize all of our input devices, and update will update the current/previous states of our devices. I’ll explain them more when we actually flesh them out.

		/** Keyboard Functions **/
		bool IsKeyDown(int);
		bool IsKeyUp(int);
		bool WasKeyPressed(int);
		bool WasKeyReleased(int);

Last on the list of things to look at is our key-checking functions. The first two will return whether the key is currently pressed or released, which can be useful for continuous motion checking, such as what we will be doing with our pong paddles. The latter two check if they key’s state has changed between this frame and the last (if the key has been pressed or released).

Code Listing 2: CInputManager.cpp

#include "CInputManager.h"
#include "CKeyboardState.h"

namespace D3DPong
{
	CInputManager* CInputManager::_instance = new CInputManager();

	CInputManager::CInputManager(void)
		: _device(NULL), _keyboard(NULL),
		_curKeyboardState(NULL), _preKeyboardState(NULL)
	{
	}

	CInputManager::~CInputManager(void)
	{
		if(this->_keyboard != NULL)
		{
			this->_keyboard->Unacquire();
			this->_keyboard->Release();
			this->_keyboard = NULL;
		}

		if(this->_device != NULL)
		{
			this->_device->Release();
			this->_device = NULL;
		}
	}

	bool CInputManager::Init(void)
	{
		// Initialize the DirectInput Device
		if(FAILED(DirectInput8Create(GetModuleHandle(NULL),	// Instance Handle
			DIRECTINPUT_VERSION,							// DirectInput Version
			IID_IDirectInput8, 								// Device Type
			(LPVOID*)&this->_device,						// Pointer to device storage
			NULL)))
		{
			MessageBox(NULL, L"Error initializing Input Manager", L"Error", MB_OK);
			return false;
		}

		// Initialize the Keyboard
		if(!this->initKeyboard())
			return false;

		// Call update once to populate the input states
		this->Update();

		return true;
	}

	bool CInputManager::initKeyboard(void)
	{
		if(FAILED(this->_device->CreateDevice(GUID_SysKeyboard,
			&this->_keyboard,
			NULL)))
		{
			MessageBox(NULL, L"Error initializing Keyboard", L"Error", MB_OK);
			return false;
		}

		if(FAILED(this->_keyboard->SetDataFormat(&c_dfDIKeyboard)))
		{
			MessageBox(NULL, L"Error setting keyboard data format", L"Error", MB_OK);
			return false;
		}

		if(FAILED(this->_keyboard->SetCooperativeLevel(CGameEngine::Instance()->GetWindowHandle(), DISCL_FOREGROUND | DISCL_NONEXCLUSIVE)))
		{
			MessageBox(NULL, L"Error setting keyboard cooperative level", L"Error", MB_OK);
			return false;
		}

		if(FAILED(this->_keyboard->Acquire()))
		{
			MessageBox(NULL, L"Error acquiring keyboard device", L"Error", MB_OK);
			return false;
		}

		// Create the keyboard states
		this->_curKeyboardState = new CKeyboardState();
		this->_preKeyboardState = new CKeyboardState();

		return true;
	}

	void CInputManager::Update(void)
	{
		// Update the keyboard
		this->_preKeyboardState->CopyKeyBuffer(this->_curKeyboardState->GetKeyStates());

		// Make sure we reacquire the keyboard if the device was lost
		if(this->_keyboard->GetDeviceState(this->_curKeyboardState->GetBufferSize(), this->_curKeyboardState->GetKeyBuffer()) == DIERR_INPUTLOST)
			this->_keyboard->Acquire();
	}

	bool CInputManager::IsKeyDown(int keyCode)
	{
		return this->_curKeyboardState->IsKeyDown(keyCode);
	}

	bool CInputManager::IsKeyUp(int keyCode)
	{
		return this->_curKeyboardState->IsKeyUp(keyCode);
	}

	bool CInputManager::WasKeyPressed(int keyCode)
	{
		if(this->_curKeyboardState->IsKeyDown(keyCode) && this->_preKeyboardState->IsKeyUp(keyCode))
			return true;
		else
			return false;
	}

	bool CInputManager::WasKeyReleased(int keyCode)
	{
		if(this->_curKeyboardState->IsKeyUp(keyCode) && this->_preKeyboardState->IsKeyDown(keyCode))
			return true;
		else
			return false;
	}
};

Here are the guts of our system. Not everything will need covered, because it will be pretty obvious based on other parts, but here goes:

	bool CInputManager::Init(void)
	{
		// Initialize the DirectInput Device
		if(FAILED(DirectInput8Create(GetModuleHandle(NULL),	// Instance Handle
			DIRECTINPUT_VERSION,							// DirectInput Version
			IID_IDirectInput8, 								// Device Type
			(LPVOID*)&this->_device,						// Pointer to device storage
			NULL)))
		{
			MessageBox(NULL, L"Error initializing Input Manager", L"Error", MB_OK);
			return false;
		}

		// Initialize the Keyboard
		if(!this->initKeyboard())
			return false;

		// Call update once to populate the input states
		this->Update();

		return true;
	}

This method initializes our input management system. The first thing that we must do is initialize our DirectInput device, because it will be used to create any DirectInput-based input systems later (keyboard, mouse, and joypad, for example). We then call initKeyboard() to initialize our keyboard (when adding a Mouse or Joystick, you would also add an initMouse/initJoystick function, just to keep things clean), make sure it worked properly, then capture the current state of the input system.

	bool CInputManager::initKeyboard(void)
	{
		if(FAILED(this->_device->CreateDevice(GUID_SysKeyboard,
			&this->_keyboard,
			NULL)))
		{
			MessageBox(NULL, L"Error initializing Keyboard", L"Error", MB_OK);
			return false;
		}

		if(FAILED(this->_keyboard->SetDataFormat(&c_dfDIKeyboard)))
		{
			MessageBox(NULL, L"Error setting keyboard data format", L"Error", MB_OK);
			return false;
		}

		if(FAILED(this->_keyboard->SetCooperativeLevel(CGameEngine::Instance()->GetWindowHandle(), DISCL_FOREGROUND | DISCL_NONEXCLUSIVE)))
		{
			MessageBox(NULL, L"Error setting keyboard cooperative level", L"Error", MB_OK);
			return false;
		}

		if(FAILED(this->_keyboard->Acquire()))
		{
			MessageBox(NULL, L"Error acquiring keyboard device", L"Error", MB_OK);
			return false;
		}

		// Create the keyboard states
		this->_curKeyboardState = new CKeyboardState();
		this->_preKeyboardState = new CKeyboardState();

		return true;
	}

Not much to see here, in spite of the length – most of it’s error checking. First, we use the DirectInput device to create our Keyboard device, then we follow up by setting the data format and cooperative level. The cooperative level sets how our application works with the operating system and other applications running, when it comes to handling input on the device. Setting a Foreground cooperative level makes it so that our game only responds to input when the game window is our active window. This way, if the player were to open Notepad and press the escape key, it wouldn’t close our game. Setting this to background, on the other hand, allows this to happen. The second piece of our cooperative level determines whether other applications will be allowed to access the input device when the game is using them. Nonexclusive means that the input device can be shared with others, and that works best to keep our application on friendly terms with any software our players may be using. The only time you really want to use exclusive mode is when using a mouse in a three-dimensional shooter game, to prevent our mouse from slipping out the side of the window when we’re turning. Finally, we capture (acquire) our input device, and create two empty instances to store the state of the keyboard.

	void CInputManager::Update(void)
	{
		// Update the keyboard
		this->_preKeyboardState->CopyKeyBuffer(this->_curKeyboardState->GetKeyStates());

		// Make sure we reacquire the keyboard if the device was lost
		if(this->_keyboard->GetDeviceState(this->_curKeyboardState->GetBufferSize(), this->_curKeyboardState->GetKeyBuffer()) == DIERR_INPUTLOST)
			this->_keyboard->Acquire();
	}

The update method updates our keyboard states. First, we use the CopyKeyBuffer (which, as you will see when we design our Keyboard State class, simply copies the key buffer array from another array). We then check to make sure that the device was not lost (for example, if the window is switched). If it is, we re-acquire it. When we use the GetDeviceState() function within the if() statement, we are also capturing the keyboard state – first, we pass the size of the buffer, then we pass a pointer to the buffer array. GetDeviceState will copy the state of our keyboard to the key buffer array.

Because the IsKeyUp and IsKeyDown functions directly map to functions of the same name on the current keyboard state, we’ve only one last thing to cover:

	bool CInputManager::WasKeyPressed(int keyCode)
	{
		if(this->_curKeyboardState->IsKeyDown(keyCode) && this->_preKeyboardState->IsKeyUp(keyCode))
			return true;
		else
			return false;
	}

This is pretty obvious, but I want to be completely clear on how we’re working this. If the state has been changed between the current frame and the last, we return true. In the case above, we are checking if the key has been pressed. We check the current state of the key against the previous state – if it was released (up) on the last frame, but is pressed (down) now, we return true – the key has been pressed between the current and last frames. Otherwise, it hasn’t, so we return false.

Code Listing 3: CKeyboardState.h

#pragma once

#include <Windows.h>

namespace D3DPong
{
	class CKeyboardState
	{
	private:
		char _keyStates[256];

	public:
		/** Constructor & Destructor **/
		CKeyboardState(void);
		~CKeyboardState(void);

		/** Public Methods **/
		bool IsKeyDown(int);
		bool IsKeyUp(int);
		void CopyKeyBuffer(char*);

		/** Accessors & Mutators **/
		char* GetKeyStates(void) { return this->_keyStates; }
		LPVOID GetKeyBuffer(void) { return (LPVOID)&this->_keyStates; }
		DWORD GetBufferSize(void) { return sizeof(this->_keyStates); }
	};
};

The only member variable here is our key buffer – which is a simple char array, exactly what will be set by the keyboard device’s GetDeviceState function. I’ll cover the functions below:

Code Listing 4: CKeyboardState.cpp

#include "CKeyboardState.h"

namespace D3DPong
{
	CKeyboardState::CKeyboardState(void)
	{
	}

	CKeyboardState::~CKeyboardState(void)
	{
	}

	bool CKeyboardState::IsKeyDown(int keyCode)
	{
		if(this->_keyStates[keyCode] & 0x80)
			return true;
		else
			return false;
	}

	bool CKeyboardState::IsKeyUp(int keyCode)
	{
		return !this->IsKeyDown(keyCode);
	}

	void CKeyboardState::CopyKeyBuffer(char* buffer)
	{
		for(int i = 0; i < 256; i++)
			this->_keyStates[i] = buffer[i];
	}
};

Here we go!

	bool CKeyboardState::IsKeyDown(int keyCode)
	{
		if(this->_keyStates[keyCode] & 0x80)
			return true;
		else
			return false;
	}

To check whether or not a key is up, we simply do a BITWISE AND operation against the key state (stored in our buffer) at the keycode in our array against 0×80. The keyCode integer will be a pre-defined DirectInput keycode, such as DIK_ESCAPE or DIK_HOME – you can find a list of DirectInput keycodes here. To find out if the key is up, we need only check if it is not down – so our IsKeyUp merely returns !IsKeyDown.

	void CKeyboardState::CopyKeyBuffer(char* buffer)
	{
		for(int i = 0; i < 256; i++)
			this->_keyStates[i] = buffer[i];
	}

Here, we actually copy the key buffer. There are only 256 indexes in the key buffer array, so that’s all we need to copy. In case you’re surprised, yes, arrays are simply glorified pointers with fixed sizes – and you can easily use an array as a pointer.

Wrapping it into our engine
Now, we need to make some ties to bring our singleton into the application. Open up WinMain.cpp, and let’s get started.

#define InputManager D3DPong::CInputManager::Instance()

Just as we did with the instance of the game engine, we are going to create a Macro to access our Input Manager singleton. Now, we can just use InputManager->WasKeyPressed instead of going out of our way to type D3DPong::CInputManager::Instance()->WasKeyPressed.

	// Initialize the Game Engine
	GEInstance->SetWindowHandle(hWnd);
	if(!GEInstance->Init(GEInstance->GetScreenWidth(), GEInstance->GetScreenHeight(), GEInstance->GetColorDepth()))
		return 0;

	if(!InputManager->Init())
		return 0;

	// Message Loop
	while(GEInstance->GetGameRunning())
	{
		while(PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
		{
			TranslateMessage(&msg);
			DispatchMessage(&msg);
		}

		InputManager->Update();
		GEInstance->Update();
	}

The only changes here are the lines regarding the InputManager – these parts are all we need to tie the input manager into our engine. They’re quite obvious in what they do – initialize and update the input manager – so I doubt that I need to give much explanation.

Adding input to our test game
I’m only going to cover checking for the escape key on this, but if you look at the tutorial files, I’ve added some simple platformer-esque input handling to our earlier rendering and physics tests.

void GameUpdate(float delta)
{
	if(InputManager->WasKeyReleased(DIK_ESCAPE))
		GEInstance->SetGameRunning(false);

	// [...] The rest of our update method
}

Here, we check if the Escape key has been released – this will allow us to easily exit our window via a single keystroke. I choose to check for the release of the escape key out of personal preference, because I prefer acting on the release of most keystrokes, but you could achieve similar results by doing WasKeypressed – it would merely act when the key was pressed, instead of when it was released (</obvious>).

And there you have it, the (long awaited?) keyboard input tutorial. If I missed something between the downloadable source and what I’ve posted, please let me know so I can fix it – I wrote the code for this ages ago, and only finally got around to writing the tutorial portion recently.

Anybody who’s been to my blog more than one time will probably notice that I’ve changed the theme. I’m just playing around with some different themes and such, and I’ve been in a very Apple mood recently, so I decided to pop that up. Other than the time I’ve been able to spend with Erin, nothing’s really changed about my life, that’s worth mentioning, so I guess that about wraps things up here.

Sorry for those who are still waiting on the next tutorial! I’ve got a project that popped up that I’m playing around with as far as Torque goes, but I’m still planning on working through writing up the next tutorial. I’ll probably create a Google Code project for the tutorial series, so that people can get the most up-to-date code from a Subversion repository and play with things themselves, but I haven’t really gotten around to doing anything at all recently. >.>

Which brings me around to my next point. Unlike what I had planned, I am probably not going to be continuing this engine after the Pong clone is complete. I just don’t seem to have the time anymore, and I feel that my time is better spent with Erin and working on other life issues than releasing these tutorials. In short, I don’t feel that I could release the series in a timely manner. Don’t get me wrong, I’m still going to be programming, and I will still be developing tutorials – even a couple series tutorials. I’m just not going to be worrying about releasing the tutorials on any sort of deadline, and most of them will be one-shot tutorials (kind of like my XBOX 360 Controller Input tutorial at CodeProject).

Sorry if this is bad news for anybody, but you gotta do what you gotta do. I’ll still be available for help, if you want it. Best place to hit me up is #snoopy at Keyboard-Failure.

I’ve started working again on an IRC client – now under the name alienIRC (formerly SevenIRC, which was being planned solely for Windows). I’ve also decided to make it completely open-source, and intend to license it under LGPLv3, something it shares with the Qt framework that is going to power it. I’m going to be setting up a Git repository on Gitorious for the project, and will be setting up some development pages on this blog – including issue tracking, a wiki, and some other tools. Right now, my plan is to closely emulate the mIRC interface – mostly because mIRC is my favorite IRC client – and will be working to make sure it feels native on all supported platforms. I will personally be maintaining builds on Windows (32- and 64-bit), OpenSUSE 11, and Mac OS X Snow Leopard. I will primarily be using the IDE that comes with Qt, though I will work to ensure that it compiles in X-Code 3 and Visual Studio 2008/2010.

As far as alienIRC itself goes, I’m looking at the possibility of using WebKit for the chat windows’ messages. This would make it incredibly easy to add formatting, because I could easily change messages from the mIRC color character into HTML tags before adding the text to the message box. It all depends on how it runs compared to a custom text box. I also plan to implement a number of features that are popular with mIRC, such as scripting (Lua, specifically), “address books,” nick highlighting, file sharing, et cetera. I’m currently working on some UI concept work – since it will have to be different from SevenIRC’s WPF plans and the previous OS X-only alienIRC UI concept that relied on some UI elements only found on Mac (such as Drawers).

If anybody is interested in contributing to this project, send me some messages – I’d be happy to hear your input, especially on features that you feel would be good to implement. Make sure you sign up for an account on Gitorious – and that you upload your SSH keys and such. If you’ve never used Git, and you’re a Windows developer, this is a very useful link for seting it up on Windows: Git for Windows Developers: Part 1