Jump to content
  • Advertisement

N.O.W.

Sign in to follow this  
  • entries
    3
  • comments
    6
  • views
    6993

About this blog

Random Thoughts and Progress

Entries in this blog

 

Game State

Well the good news is that I was given a reprieve on the 3 month overtime death march for two weeks. Unfortunately for my kick ass progress it looks like we will be starting it up harder and longer within the week. I was able to get some decent work done to my art assets. I have been looking into picking up the Genius G-Pen F610 drawing tablet to speed up art production, once I get a few dollars ahead. If anyone has any input on this little guy let me know.

Anyway, a few weeks ago I saw a blog on Gamasutra about using design patterns in your game. I personally think that is an awesome topic with loads of possibilities. The gentleman writing the blog briefly touch on a few. Now due to the nature of design patterns I personally think that it is hard to say whether someone else' implementation is right or wrong. As long as your implementation does not cause poor performance and solves your problem without causing other problems I call it a win.

[heading]What three things do almost ALL interactive software have in common?[/heading]

So before we get started discussing what is a design pattern I would like you to consider something. What 3 things do practically every piece of interactive software have in common? We'll come back to this later.

A design pattern is a solution to a problem that occurs over and over in software. I believe the idea was originally taken from the world of architecture. The awesome thing about design patterns is that they are very loose by nature.

[subheading]What the hell does that mean!?!?[/subheading]

Good question! it means that aside from some generalized concepts there is no cut and dried, "This is the only correct way!" The initial reaction is probably along the lines of, "how is that helpful in any way if the solution is not the same for everyone?" And there in lies the beauty and the power of design patterns. In software we run into problems that are pretty much the same things over and over. The real problem is that they are not the exact same problem over and over but have many of the same aspects. The solution to that problem needs to be specific to that problem in order for it to be successful.

What some really smart people did was put together groups of patterns of problems and solutions and called them design patterns. These problems are somewhat generalized as are the solutions. The design patterns also define the pros and cons of using them! Holy cow! That means there is a catalog in the mystic aether that solves all of our problems!

[subheading]No not really. But sort of.[/subheading]

There is a catalog of patterns and it is getting larger everyday and some of them begin to get more specific to a problem. Design patterns are not a silver bullet. They do not solve every problem and using as many as you can in one project will probably be more of a pain and less useful than it is really worth. To borrow a phrase.. We need to use intelligent design. One of the basic ideas in the patterns are abstraction and encapsulation. By adding some abstraction we can handle more problems with the same methods. By encapsulating things that don't change we can implement them across the board and change them across the board too.

I am doing a huge disservice by over generalizing but you will need to do a bit of research on your own to really get the nitty gritty of it all.

All of that being said I would like to talk about the State Pattern today. The state pattern describe the state of an object. So it's not just a clever name. Ironic isn't it. It consists of an abstract class using only virtual functions to describe the behavior of the class. Then a concrete class implements those virtual methods according to it's intended function. Two short sentences but there really is a lot of stuff said between them. Check out the above link to see a diagram.

[subheading]My problem[/subheading]

Yes I know... I know I have more than one and not all of them are psychological. Seriously though. When I first started making games I tried keeping track of all of my states using enumerations and switch/case blocks to handle them. This works great! For very small programs with very few states. Now take you average small game, like a tetris clone for example. Off the top of my head I can think of about 14 different states for the game as follows:

New Game Game Active Game Over Title Screen Load Images Load Sounds Load Cut Scenes Intro Level Completed Level Loading Level Clearing Display High Scores Instructions Enter Initials for High Score
So this is for a very basic game. Each of these game states needs to be handled differently. You are going to want to handle input, rendering and game updating differently for each state. Think about this... A switch/case block to handle rendering 14 different states. A switch/case block to handle updating 14 different states. A switch/case block to handle input for 14 different states. That just sounds messy thinking about it. That is okay. I am not going to post any code from some ancient project show casing this. But that was how I used to do it.

Remember when I asked what three things almost all interactive software have in common? They all do these three things:

Handle input according to the current state Update the software model according to input and state Render information to the screen according to the input and current state
And you know what. Every piece of software does this for every pass through the main loop. I can also bet that you saw the one reoccurring theme in those three things. The word state (I know. I made them bold font). The point is this is one of the most perfect candidates for the state pattern. We can use abstraction to make a template that will handle the functions and concrete classes of that template to encapsulate the functions for each separate state.

So what does this look like?

[subheading]The Game State[/subheading]


#pragma once

class GameState{

public:



virtual void HandleInput(void) = 0;
virtual void Update(void) = 0;
virtual void Render(void) = 0;
virtual void onEnter(void) = 0;
virtual void onExit(void) = 0;

GameState(void){};
virtual ~GameState(void){};

};


So there are a few things here that I didn't mention to begin with. OnEnter and OnExit. More than likely you will find that as you change states within your game there are specific tasks that need to be performed when you enter or leave any one state. Maybe loading media assets upon entering a state and releasing them just as you exit the state? Depends on your state and it's function, but they will come in handy.

So the header for a concrete game state would look something like:


#pragma once
#include "GameState.h"
#include "Game.h"

class stateINTRO :
public GameState
{
public:
stateINTRO(Game *g);
~stateINTRO(void);

void HandleInput(void);
void Update(void);
void Render(void);

void onEnter(void);
void onExit(void);

private:
Game *game;
bool completed;

};


Pretty simple now you can handle input, update your game model and render independently for each game state. Just to give you an idea of how this simplifies the main game loop here is the main.cpp from bash.


#include "SDL.h"
#include "Game.h"

int main( int argc, char* args[] )
{
//Try to create a new game
Game *bash = new Game();

//Check to make sure the game systems initialized correctly
if(bash->Initialized){

//While the game is not requesting to quit run the game
while(!bash->ExitRequested){

bash->HandleInput();
bash->Update();
bash->Render();

}

}

//Clean-up the memory used by the game
delete bash;

return 0;
}


So yes there is a lot more crap stuffed into the game object. BUT the game object is the game engine. It only provides services like managers for input, audio and graphics. It also provides functions that span across many different states. This in itself makes the game engine a bit more reusable and flexible. Meaning the engine is not the game.

So the interface to the game states in the game engine it could look something like:


void Game::HandleInput(void){

//Always handle the user trying to quit the game
if(this->kb->isKeyDown("QUIT")){
this->ExitRequested = true;
}

//Let the current state handle the other input
this->currentState->HandleInput();
}

void Game::Update(void){
//Update the keyboard so the current state doesn't have to
this->kb->Update();
//Update the gamepad
this->pad->update();
//Allow the current state to chose what systems to update
this->currentState->Update();
}

void Game::Render(void){

//clear the drawing surface
SDL_FillRect( this->screen, NULL, GColor::BLACK);

//Let the current state draw what it needs to
this->currentState->Render();

//Update Screen
SDL_Flip( this->screen );

}

void Game::SetState(GameState *s){
this->currentState->OnExit();
this->currentState = s;
this->currentState->OnEnter();
}



[subheading]Pro's and Con's[/subheading]

That about sums of the majority of the game state, or at least my current implementation. But as with all design patterns there are drawbacks associated with them.

What are they?

Class Explosion
The major problem with this pattern is that EVERY SINGLE STATE requires a new class. Ouch. That can get pretty messy. You are basically trading a messy class for a mess of classes. With proper naming conventions this will help mitigate the organization problem. But it also makes it hard to see the design as a whole without creating a diagram of the state machine. BTW I recommend doing this even if it is just on paper.

Brittle Interface
Yep it's true. Without proper foresight in your design this pattern can muck things up quick. Why? Because if you need to add another interface in the pure virtual class you need to add it to EVERY concrete class. This is also why I recommend putting a design on paper or in UML prior to tearing into it. That being said I think as far as the game state goes, it doesn't get much more basic than what I presented.

So the pro's! What are the good things about this and why is it even worth making a metric ton of classes?

Harder to Break
It is harder, though not impossible, to break any other state by making changes to any single state using this pattern. You have encapsulated your functionality and cannot muck about with any other state.

Distributable
Really big plus here. This pattern forces the programmer to design to an interface. Meaning since you only have 3 functions you need to interface to the game as a whole you can have multiple programmers working on separate states all at the same time and not have to worry about them breaking another state.

Organization
Although it is hard to see the whole picture it is doable. It is very very hard to look at one single class that handles every single state of input, logic and rendering. Piecing those bits into one manageable whole is harder than being able to look at one file for one state and knowing what it does.


[subheading]No Silver Bullet[/subheading]

This is no silver bullet. This is not the thing you want to use all over your program unless you are prepared to deal with the negative aspects of this little devil. But it does solve some specific problems and it does it well enough in my opinion.

I highly recommend two books for further reading.

Head First Design Patterns
This book is truly awesome! It is a pleasure to read injecting humor and thoughtfulness into every chapter. This is not your typical dry stereo instructions programming book. Go buy it today.

Design Patterns: Elements of Reusable Objects
This is the original gang of four book that everyone mentions. It really is an excellent read and presents the topics in a well thought out manner. I would recommend reading this book after you have read Head First Design Patterns.

Wrathnut

Wrathnut

 

overtime and an SDL joystick / gamepad

So for a few weeks I have been working on coloring the art for the over world map from the sketches I received from my artist. Apparently my skills with photoshop could use some serious improvement! I have put in about 20 hours so far and I think I still have at least that many to go. I am getting the effect I was looking for so I am pretty happy.

[size="3"][heading]"Time is an illusion... lunch time doubley so!" - Douglas Adams[/heading]

As is the way of it, I started doing some serious overtime at work two weeks ago( looks like it will continue for a couple more weeks too). Due to my ridiculously long commute it was easier to stay in town at my brother's place than to come home. Otherwise a 12 hour day turns into a 16 hour day. Needless to say I don't have a laptop that has any of the art programs I need to continue work. But I do have visual studio on it. So I decided to figure out a gamepad for Bash.

I have never worked with a joystick or gamepad before as this is the first platformer I have worked on. Looking around at examples of input control for SDL on the net all I seem to find is event based control systems.

[size="3"][subheading]Burn the witch![/subheading]
I don't particularly like event based control systems. Now before the pitchforks and torches are passed around and appropriate chants are agreed upon let me say that they ARE useful. Event based systems(not just keyboard or controller input) solve a fair number of problems. It just seems to me that they are a bit over-used(is it just me??) and not the best solution in every case. Being programmers we should evaluate our tools in our toolbox and pick the best one for the job and not just go along with the latest fad.

The above rant aside I figured what the hell it can't be that hard! And it really isn't! The code posted below it the result of an hour or so's work. It is not a fully fleshed controller class but it is functional enough to replicate the Super NES controller. Meaning I am more interested to know if something is being held down or just pressed. Hence the identifiers DOWN and PRESSED. Down is being actively held down. Pressed will only register 1 time when it is pressed. It won't register a press until it is released and held down again.

SDL Controller

gamepad.h

#pragma once
#include
#include
#include "button.h"
#include "SDL.h"
#include "vector2d.h"

using namespace std;

class gamepad
{
public:

string name;
bool available;
int availableButtons;
int availableHats;

vector2d axis, axis_old;
int hat, hat_old;
float threshold;

gamepad(void);
~gamepad(void);

void init(void);
void update(void);

void addButton(string name, int number);
void setButton(string name, int newNumber);

bool isButtonDown(string name);
bool isButtonPressed(string name);

bool stickUp(void);
bool stickDown(void);
bool stickLeft(void);
bool stickRight(void);

bool stickPressedUp(void);
bool stickPressedDown(void);
bool stickPressedLeft(void);
bool stickPressedRight(void);

bool hatUp(void);
bool hatDown(void);
bool hatLeft(void);
bool hatRight(void);

bool hatPressedUp(void);
bool hatPressedDown(void);
bool hatPressedLeft(void);
bool hatPressedRight(void);

bool state(int num);

private:
vector Buttons;
SDL_Joystick* stick;


};



gamepad.cpp

#include "gamepad.h"
#include "SDL.h"
#include "button.h"
#include
#include
#include "vector2d.h"

using namespace std;

gamepad::gamepad(void)
{
this->available = false;
this->name = "";
this->availableButtons = 0;

//Zero our the joysticks and hats
this->axis.x = 0.0f;
this->axis.y = 0.0f;
this->axis_old = this->axis;
this->hat = SDL_HAT_CENTERED;
this->hat_old = SDL_HAT_CENTERED;
this->threshold = 500.0f;
}

gamepad::~gamepad(void)
{
if(this->available){
SDL_JoystickClose(this->stick);
}
this->Buttons.clear();
}
///Init must be called after SDL is initialied
void gamepad::init(void){
int num_joy;
num_joy=SDL_NumJoysticks();
//See if there is a joystick connected
if(num_joy > 0){
this->name = SDL_JoystickName(0);
this->available = true;
this->stick = SDL_JoystickOpen(0);
this->availableButtons = SDL_JoystickNumButtons(this->stick);
this->availableHats = SDL_JoystickNumHats(this->stick);
}
}
///Update must be called if the gamepad is going to be polled
void gamepad::update(void){
if(this->available){
SDL_JoystickUpdate();

//Update all the buttons
for(int i=0; i Buttons.size(); i++){
unsigned int n = SDL_JoystickGetButton(this->stick, this->Buttons->number);
if( n == 0){
this->Buttons->release();
}
else{
this->Buttons->press();
}
}

//Update the direction pad
this->axis_old = this->axis;
this->axis.x = SDL_JoystickGetAxis(this->stick, 0);
this->axis.y = SDL_JoystickGetAxis(this->stick, 1);

this->hat_old = this->hat;
this->hat = SDL_JoystickGetHat(this->stick, 0);

}
}
///Returns true if the button of a index 'num' is being held down
bool gamepad::state(int num){
unsigned int n = SDL_JoystickGetButton(this->stick, num);
if( n == 0){
return false;
}
else{
return true;
}
}
///Add a new button to track. Number is the index of the button on the controller
void gamepad::addButton(string name, int number){
button *tmpB = new button();
tmpB->name = name;
tmpB->number = number;

this->Buttons.push_back(tmpB);
}
///Sets the number value of the button(the index of the button on the controller)
void gamepad::setButton(string name, int newNumber){
for(int i = 0; i Buttons.size(); i++){
if(this->Buttons->name.compare(name) == 0){
this->Buttons->number = newNumber;
}
}
}
///Return the current state of the button
bool gamepad::isButtonDown(string name){
bool retval = false;
for(int i = 0; i Buttons.size(); i++){
if(this->Buttons->name.compare(name) == 0){
retval = this->Buttons->isDown();
}
}

return retval;
}
///Returns true if the button was just pressed since the last time it was updated
bool gamepad::isButtonPressed(string name){
bool retval = false;
for(int i = 0; i Buttons.size(); i++){
//Find the button requested
if(this->Buttons->name.compare(name) == 0){
//return true If the button was just pressed
if(this->Buttons->isDown() && !this->Buttons->wasDown()){
retval = true;
}

}
}

return retval;
}
///See if the stick is pointing up
bool gamepad::stickUp(void){
return this->axis.y threshold;
}
///See if the stick is pointing down
bool gamepad::stickDown(void){
return this->axis.y > this->threshold;
}
///See if the stick is pointing left
bool gamepad::stickLeft(void){
return this->axis.x threshold;
}
///See if the stick is pointing right
bool gamepad::stickRight(void){
return this->axis.x > this->threshold;
}

///See of the stick was just pressed up
bool gamepad::stickPressedUp(void){
return (this->axis.y threshold) && !(this->axis_old.y threshold);
}

///See if the stick was just pressed down
bool gamepad::stickPressedDown(void){
return (this->axis.y > this->threshold) && !(this->axis_old.y > this->threshold);
}

///See if the stick was just pressed left
bool gamepad::stickPressedLeft(void){
return (this->axis.x threshold) && !(this->axis_old.x threshold);
}

///See if the stick was just pressed right
bool gamepad::stickPressedRight(void){
return (this->axis.x > this->threshold) && !(this->axis_old.x > this->threshold);
}
///See if the D-pad is in the up position
bool gamepad::hatUp(void){
return this->hat & SDL_HAT_UP;
}
///See if the D-pad is in the down position
bool gamepad::hatDown(void){
return this->hat & SDL_HAT_DOWN;
}
///See if the D-pad is in the left position
bool gamepad::hatLeft(void){
return this->hat & SDL_HAT_LEFT;
}
///See if the D-pad is in the right position
bool gamepad::hatRight(void){
return this->hat & SDL_HAT_RIGHT;
}
///See if the D-pad was pressed up
bool gamepad::hatPressedUp(void){
if((this->hat == SDL_HAT_UP) && (this->hat_old == SDL_HAT_CENTERED)){
return true;
}
return false;
}
///See if the D-pad was pressed down
bool gamepad::hatPressedDown(void){
if((this->hat == SDL_HAT_DOWN) && (this->hat_old == SDL_HAT_CENTERED)){
return true;
}
return false;
}
///See if the D-pad was pressed left
bool gamepad::hatPressedLeft(void){
if((this->hat == SDL_HAT_LEFT) && (this->hat_old == SDL_HAT_CENTERED)){
return true;
}
return false;
}
///See if the D-pad was pressed right
bool gamepad::hatPressedRight(void){
if((this->hat == SDL_HAT_RIGHT) && (this->hat_old == SDL_HAT_CENTERED)){
return true;
}
return false;
}


[subheading][size="3"]Something is missing...[/subheading]

So there are a few things I wanted to add that I have not had the time to throw in there..
Auto-calibration:
More of a misnomer I think. You cannot really do an auto-calibration on a joystick unless you know some specifics about it. Otherwise you will need the user to place to joystick in it's maximum position on both axis so you can normalize the input.(hence the vector for the stick position) As such this would need to be a function of the game and not the joystick. Now the threshold value IS something that we can take care of though.

What is this threshold you speak of? An analogue joystick is actually just that. Depending on the construction of the board and because it is analogue there will be a tiny amount of jitter in the system unless it is compensated for at the board level or the driver abstraction. The computer reads the position of the joystick by the amount of voltage being passed to it. This voltage is in direct proportion to the position of the stick on either axis. In order for this value to be read by the computer it needs to be digitized by being passed through an A/D converter. An A/D converter reads in an analogue voltage in discrete steps. This is the resolution of the A/D. The general rule of thumb for the stability of an A/D is approximately 2-3 of these discrete steps about any point IF the steps are small enough(in this case they probably are). So we get a bit of jitter in the system once we excite it!

Why do I care?
We probably don't care very much.. except when the user sees his character moving when he is not directing the input! Fortunately there is a relatively easy way to deal with this. Take several samples of the input, maybe 50, maybe 100. The more samples the better. Just don't let the user get bored or accidentally move the stick while you are sampling. Find the maximum and minimum values for each axis. These are almost your threshold values for each axis. Statistically unless you have a metric shit ton of samples you are probably not have the largest amount of jitter in your sample set. The good news is that you are probably not too far off. If you calculate the standard deviation and add 1 or 2 standard deviations to your maximum and minimum values you are in really good shape to say, "I can almost guarantee that there will be no false positives on stick readings!" So you might want to pad you guess a little more depending on the stickiness that you want to see in your joystick.

Hopefully I will get sometime this weekend to implement this.

[size="2"]Serial Killer:
Serialization. Going along the lines of auto-calibration, is configuration. Since there really isn't a standardized gamepad and the index of the buttons aren't either it makes sense to give the user the ability to configure the buttons of each of their gamepads to your game. USB controllers are nice enough to provide you with the name of the controller provided by the vendor. This is perfect for creating a unique identifier specific to any gamepad. So saving the index for each defined button in your game is somewhat trivial.

Once again when I get some more of that precious time I am going to throw this together also!


As per request. Here are the button and vector2d sources:

button.h

#pragma once
#include

using namespace std;

class button
{
public:

string name;
int number;


button(void);
~button(void);

bool isDown(void);
bool wasDown(void);
void press(void);
void release(void);

private:
bool down, downPrior;

};



button.cpp

#include "button.h"
#include

using namespace std;

button::button(void)
{
this->name = "";
this->number = 0;
this->down = false;
this->downPrior = false;
}

button::~button(void)
{
}

bool button::isDown(void){
return this->down;
}

bool button::wasDown(void){
return this->downPrior;
}

void button::press(void){
this->downPrior = this->down;
this->down = true;
}

void button::release(void){
this->downPrior = this->down;
this->down = false;
}



vector2d.h

#pragma once

class vector2d
{
public:

float x;
float y;

//Define the operators
friend vector2d operator+(vector2d& v1, vector2d& v2);
friend vector2d operator*(vector2d& v1, float scalar);

vector2d(void);
~vector2d(void);

float magnitude(void);
void translate(float x1, float y1);
vector2d unitVector(void);
vector2d unitVector(vector2d v2);
vector2d unitVector(vector2d *v2);
static vector2d unitVector(vector2d v1, vector2d v2);
static vector2d unitVector(vector2d *v1, vector2d *v2);
static float angle(vector2d v1, vector2d v2);
static float magnitude(vector2d origin, vector2d endpoint);
static float magnitude(vector2d *origin, vector2d *endpoint);
static float dotProduct(vector2d v1, vector2d v2);
static float dotProduct(vector2d *v1, vector2d *v2);
static vector2d projection(vector2d v1, vector2d v2);
static vector2d projection(vector2d *v1, vector2d *v2);

};



vector2d.cpp

#include "vector2d.h"
#include


vector2d::vector2d(void)
{
this->x = 0.0f;
this->y = 0.0f;
}

vector2d::~vector2d(void)
{
}

vector2d operator+(vector2d& v1, vector2d& v2){
vector2d retval;

retval.x = v1.x + v2.x;
retval.y = v1.y + v2.y;

return retval;
}

vector2d operator*(vector2d& v1, float scalar){
vector2d retval;
retval.x = v1.x * scalar;
retval.y = v1.y * scalar;

return retval;
}

void vector2d::translate(float x1, float y1){
this->x += x1;
this->y += y1;
}

float vector2d::magnitude(){
return sqrt((this->x * this->x) + (this->y * this->y));
}

float vector2d::magnitude(vector2d origin, vector2d endpoint){
return sqrt(((endpoint.x - origin.x)*(endpoint.x - origin.x)) + ((endpoint.y - origin.y)*(endpoint.y - origin.y)));
}

float vector2d::magnitude(vector2d *origin, vector2d *endpoint){
return sqrt(((endpoint->x - origin->x)*(endpoint->x - origin->x)) + ((endpoint->y - origin->y)*(endpoint->y - origin->y)));
}

float vector2d::dotProduct(vector2d v1, vector2d v2){
return ((v1.x * v2.x) + (v1.y * v2.y));
}

float vector2d::dotProduct(vector2d *v1, vector2d *v2){
return ((v1->x * v2->x) + (v1->y * v2->y));
}

vector2d vector2d::projection(vector2d v1, vector2d v2){
vector2d retval;

retval.x = (dotProduct(v1, v2)/(v2.x*v2.x + v2.y*v2.y))*v2.x;
retval.y = (dotProduct(v1, v2)/(v2.x*v2.x + v2.y*v2.y))*v2.y;

return retval;
}

vector2d vector2d::projection(vector2d *v1, vector2d *v2){
vector2d retval;

retval.x = (dotProduct(v1, v2)/(v2->x*v2->x + v2->y*v2->y))*v2->x;
retval.y = (dotProduct(v1, v2)/(v2->x*v2->x + v2->y*v2->y))*v2->y;

return retval;
}

vector2d vector2d::unitVector(){
vector2d retval;

retval.x = this->x / magnitude();
retval.y = this->y / magnitude();

return retval;
}

vector2d vector2d::unitVector(vector2d v2){
vector2d retval, current;

current.x = this->x;
current.y = this->y;

retval.x = (v2.x - this->x) / magnitude(current, v2);
retval.y = (v2.y - this->y) / magnitude(current, v2);

return retval;
}

vector2d vector2d::unitVector(vector2d *v2){
vector2d retval;

retval.x = (v2->x - this->x) / magnitude(this, v2);
retval.y = (v2->y - this->y) / magnitude(this, v2);

return retval;
}

vector2d vector2d::unitVector(vector2d v1, vector2d v2){
vector2d retval;

retval.x = (v2.x - v1.x) / magnitude(v1, v2);
retval.y = (v2.y - v1.y) / magnitude(v1, v2);

return retval;
}

vector2d vector2d::unitVector(vector2d *v1, vector2d *v2){
vector2d retval;

retval.x = (v2->x - v1->x) / magnitude(v1, v2);
retval.y = (v2->y - v1->y) / magnitude(v1, v2);

return retval;
}

float vector2d::angle(vector2d v1, vector2d v2){
float retval;
vector2d u = unitVector(v1, v2);

retval = atan(u.y/u.x);

if(v1.x > v2.x){
//Add 180 to the angle
retval +=3.141592653589793;

}

return retval;
}



Wrathnut

Wrathnut

 

Introduction

I suppose I will start this off with a bit of information about myself and my current project. I have been programming in some form or another for over 15 years. Either professionally or as a hobby. I have always been working on some sort of game, I suspect as most hobbyists, never completing all of my projects. While working on my AS degree for electrical engineering I got a job as a software developer and decided to skip the rest of a 4 year degree to work doing what I loved at a start up company. Long story short, a few years later the start up tanked. I spent a few years trying to get stable then decided to finish my electrical engineering degree and work with one of my other passions.

Now all of this is leading into the current project BASH. I had the idea of creating a parody game about pokemon about 7 years ago when my oldest son was really getting into them. Unfortunately keeping up the GPA(~30 hours a week) and working 40 hours a week and having a family left zero time to complete this project. In January of 2011 I decided it was time to resurrect this idea I had and finish it.

At the time I was using C++ and the PTK library to do the graphics, sound and input. I did some research before starting the project back up and decided to use SDL. I gave myself 6 months to get the game done and assumed I should be done by July of 2011....

Anyway I think that is a good preface to the current project. More to come later.

Wrathnut

Wrathnut

Sign in to follow this  
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!