Sign in to follow this  
  • entries
    152
  • comments
    85
  • views
    98507

The Drudge of the Deadly Tool Delay

Sign in to follow this  
DecipherOne

259 views

Before I stepped away from Game Development in Late 2008 and started concentrating on web development, I had been working on a custom game engine and a set of tools for about two years. At that point in time I was beginning to get a bit burned out on writing things that I wasn't even getting to use. Simply put I was building things that would be helpful eventually, but they were simply sitting as I built more and more functionality.

Fast forward to almost two years exactly and I started back where I left off. I was making some good progress, but I was starting to notice the same trend as before. I was making tools, not games. If you read through my previous posts you may notice I discuss this a little bit, and it is something that I've struggled with. I work a full time job in addition to being a father and as I continued to move forward on the tools, things seemed to be moving rather slowly. The tools were meant to be a means to an end, game development, but they were proving to be more of an end in and of itself. Towards the end of March, I made a decision, I was tired of working on tools, I wanted to make games.

My game engine had been in a usable state for a while and after much debating about whether to use something like Unity, I decided to press forward with using my engine. I had spent years developing it, and with it streamlined for 2D already, it was geared towards the group of games that the development team I'm working with will be developing and last week, we started pressing forward.

Gloss_Screen1-300x234.png

As per the Screen Shot above, production on the game Barricade with PhyerSoft has picked up again. We should have a public demo within a couple of months here. I've managed to do quite a bit the last week or so on the game.

To all the guys out there that have said develop games, not tools, I have this to say :
Follow what it is you want to do. I set off on developing an engine because I wanted to learn the ins and outs of game programming. This was useful to a certain point. But at a certain point, you do have to get back to what it is you are really trying to do, which is making games. There are plenty of available tools out there for people who are wanting to start out in game development, so if games are what you ultimately want to do, it's a good idea to go a head and use what's available. If there is something specific that you want to do and a tool isn't already available, why not make it.
No one can tell you the approach that is going to end up working for you. They can only give you an idea of how it may go based upon experiences that they had or that other people have had. The most important thing is to try, experiment, and then come to your own conclusions about which path is right for you. Failure is only present when you either give up, or never even try.
As for me, we are currently moving a head with development with the engine in it's current state. Which is lacking the completed python interfaces for scripting. I will be going back and finishing those interfaces, but for now, getting a completed game under my belt seems like the best approach. Barricade, as it's stands has about 75% of the assets completed and is about a quarter of the way through for the completed demo. We will be releasing the public demo in the coming months and looking for some initial feedback, I'll post links when they are available.

I wrote a few functions that helped stream line the engine that maybe helpful to others, namely :
Pixel_2WorldSpace(float arg) which is a function that simply converts pixel space into opengl coordinates automatically so that object scaling, translation, and rotation can all be done with pixel dimensions. This is ideal for 2D.
I also wrote a couple of functions for automatically mapping uv coords, and they accompany the Animation Export Script for photoshop. They read in the sprite sheets based upon the size of the frame cells. Using these functions , one for static images, and one for animations, accompanied with a SetDimensions function, we can create an accurate in game representation of a game object with a few lines of code. This has sped up the engine itself and sped up getting things up and on the screen in a completely accurate fashion.

[source lang="cpp"]
/*/////////////////////////////////////////////////////////////////////*/

bool Sprite::Anim_Map_UV(int first_frame_row, int first_frame_col,float f_width, float f_height, int numFrames, int AnimationNum)
{
//calculate the initial uv positions

float initial_x = f_width/Texture.width;
float initial_y = f_height/Texture.height;

//How many cells rows and columns in our texture have.
int frames_per_row = Texture.width/f_width;
int num_of_cols = Texture.height/f_height;

//Bounds Checks
if(first_frame_row<1)
{
first_frame_row=1;
}

if(first_frame_col<1)
{
first_frame_col=1;
}

else if(first_frame_col>num_of_cols)
{
first_frame_col=num_of_cols;
}

//Make sure the animation exist in memory
if(AnimationNum > GetNumOfAnimations() || AnimationNum < 0)
{
MessageBox(NULL," The animation you are attempting to map is not valid.",
"Sprite::MapUV() Error!", MB_OK|MB_ICONERROR);
return false;
}

int count = 0;

//create our multipliers
int x_m = first_frame_col;
int y_m = first_frame_row;

do
{

(Animations+AnimationNum)->SetFrameTexCoord(count,
(initial_x)*(x_m-1),initial_x*x_m,initial_y*(y_m-1),initial_y*y_m);

//If we've reached the end of the row, move down to next row, first col
if(x_m == frames_per_row)
{
y_m++;
x_m=1;
}
else
{
x_m++;
}

count++;
}
while(count < numframes );

return true;
}

///////////////////////////////////////////////////////////////////////////////////

bool Sprite::Static_Map_UV(int frame_row, int frame_col,float f_width,float f_height)
{

//calculate the initial uv positions

float initial_x = f_width/Texture.width;
float initial_y = f_height/Texture.height;

//How many cells rows and columns in our texture have.
int frames_per_row = Texture.width/f_width;
int num_of_cols = Texture.height/f_height;

if(frame_row<1)
{
frame_row=1;
}
if(frame_col<1)
{
frame_col=1;
}

else if(frame_col>frames_per_row)
{
frame_col=frames_per_row;
}

//create our multipliers
int x_m = frame_col;
int y_m = frame_row;

if(!SetTexCoords((initial_x)*(x_m-1),initial_y*(y_m-1),initial_x*x_m,initial_y*y_m))
{
MessageBox(NULL,"The texture Coordinates could not be set.",
"SPRITE::Static_Map_UV Error",MB_OK|MB_ICONERROR);
return false;
}

return true;

///////////////////////////////////////////////////////////////////////////////////////////////////////////////

float Pixel_2WorldSpace(float arg)
{
float par = ((float)TrogWin.GetHeight())/((float)TrogWin.GetWidth());

par=par/100;

return (arg*par);
}
/////////////////////////////////////////////////////////////////////////////////////////////////////////////

void Sprite::SetDimensions(float x1,float x2,float y1,float y3)
{
x1= Pixel_2WorldSpace(x1);
x2= Pixel_2WorldSpace(x2);
y1= Pixel_2WorldSpace(y1);
y3= Pixel_2WorldSpace(y3);
SetVerticesScales(-x1,-y1,x2,y3,0.0f);

}

[/source]
Those functions have been extremely helpful and hopefully will be helpful to someone else out there. Of course there are some specific functions for the engine that these functions use, but they should be somewhat self-explanatory.



Source
Sign in to follow this  


0 Comments


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now