Jump to content

  • Log In with Google      Sign In   
  • Create Account

Retro Grade



[Development] Hooded Development #4: Refactoring!

Posted by , 30 October 2012 - - - - - - · 530 views

We are refactoring my code. More correctly, I am refactoring my code for Hooded. It is honestly terrible. What do I mean? Examine:

I didn't Pre-Visualize. My previous article stemmed from this, because I didn't pre-visualize and thus have scrapped all of my code. Literally all of it. I now am ten pages into my development journal (For every project I start, I pre-visualize by getting a 100 page journal and writing down the framework. I also jot down any solutions to problems I come up with at random.), and may I say it's coming along nicely. A lot of the things I've "put off" in the first development I have though extensively about, and thus this time I hope to throw away zero lines of code. Also, I never told you guys what Hooded *was*. So, here it is:

Hooded is a 2D tile-based platformer. Your character is in a hood the whole game, and you do not know who he is, however you see his life under a veil. You will navigate largely puzzle / maze based maps with combat mixed in. The combat will consist of swords and, in a update after release, *maybe* bows. The game will be made by me, Thomas Hobohm.

There it is. That is really the premise of Hooded. There is more, however that should be enough, for now...


[Beginners] Pre-Visualization Is Important!

Posted by , 29 October 2012 - - - - - - · 1,051 views

Hello everyone. This post should be pretty long (and heavy). I feel that this mistake is being caused largely by the more seasoned developers on here (Also known as, not me) using the wrong words to describe how the pre-visualize. This led to me making a large amount of mistakes in software development and has made me scrap so much code. So, without further ado, I present to you: The Importance Of Pre-Visualization

Many a beginner on gamedev.net (including me) has trouble with their software in the beginning. I had no idea how to plan for projects or what was even included in projects. I would look for posts about how to plan out projects. Generally when these questions get ask the seasoned developers on here (Also known as people who have worked on many finished projects) answer with responses like:

I have a really iterative design

I don't really pre-visualize, I try to sort out more details at implementation


Now, that's not to say these developers are in the wrong at all. For a beginner however, these terms can be very daunting and confusing. For me, I thought I shouldn't really pre-visualize at all and that everything would sort itself out eventually (Boy how wrong was I Posted Image). In this article I plan to explain to you how I pre-visualize my projects, how much you should really be pre-visualizing, and why it's important. So let's jump right in with the third one: Why Pre-Visualizing Important?

Pre-Visualizing allows you to plan how your classes interact. Imagine this: In many projects, your Collision and Physics interact, and almost all of your classes have to access a singular Map for the level you're on. How they will interact and how the map will be handled must be thought out so that the code you write at the beginning will be prepared for how the other classes use the Map. This must be sorted out in pre-visualization because you write certain code (classes) at different times, which means if you don't think about this you'll end up re-writing enormous amounts of code.

Pre-Visualization also defines project scope. Knowing what you plan to accomplish and what accomplishing that includes helps with development (For one thing, you will be able to gauge your progress and define what needs to be done next). When making a Side-Scroller, understanding the scope of the enemies A.I. is important so you'll know the work involved. If you make simple A.I., you can compensate with adding bows to a Side-Scroller that was originally only going to have swords. Now that I've made that analogy however, let us move on to another important topic involving why pre-visualizing is important: Understanding the Mechanics of your game.

This ties into project scope. The mechanics are part of project scope because the more complex the mechanics the more time it will take to implement them. Imagine this: Having a Bow involves a lot more coding (Handling projectiles shot, their collision, how fast they move, animation for them, etc.). So at project scope, you define if you'll have a bow or if you'll only have swords. This lets you only plan for swords. The first part of planning should always be defining your scope.

Now on to the second part: How much you should be pre-visualizing. My general rule is figuring out your hierarchy and how your classes will interact, however I leave out the actual coding details. I know how to code, and a large part of my actual software-design is figuring out how to solve problems or thinking about the best way to solve a problem. Figuring out what those problems are and how you'll solve them is pre-visualization. Actually planning out my code, what my functions will pass in, etc. shouldn't be defined in pre-visualization (Except for small, single-task programs like converting one form of a linear equation to another form.). Solving these problems before you start coding make sure that all the code you right already had that problem in mind (So when a problem turns up or when you are implementing something, you don't have to scrap existing code).

Some problems are bound to be encountered while coding, and trying to write down and fix every minute detail of your program is an example of bad pre-visualization. You can't anticipate everything, however anticipating what you can (AKA the bigger problems and ideas) will help exponentially.

Now, what you've all been waiting for: How do I pre-visualize? It's simple really. I get a notebook, write down the name of my project. I define the scope, the mechanics, and then take one or two pages in the notebook I label "Classes". I figure out the basic classes and write down their responsibility (Defining responsibility make sure you understand what all of your classes are actually supposed to be doing). Then, I take maybe a page for each class or important mechanic and think about it hard. I think about how it'll handle it's responsibilities and how it will interact with other classes. The key word here is interaction. Interaction is a huge part of software design (Especially video game software design.). This allows me to anticipate the basic structure of my code and the problems I'll run into. Then for a day or two I'll read over what I have and reflect. After I do this, I take my journal to the computer and start coding. This whole process is one to two weeks.

The main point of this article was to stress how important pre-visualization is to beginners. Now, it might just be tic-tac-toe, however still get in the habit of pre-visualizing. It'll pay off in the long run.

If you enjoyed this article, please post down below. If you have any recommendation about how you plan or any corrections, feel free to share them with everyone. Cheers Posted Image!


[Development] Hooded Development #3

Posted by , in Development 28 October 2012 - - - - - - · 1,399 views

Hello everyone! Welcome to the third Hooded Development update! What has been added today, I wonder? Well, right now this is what's happened since last time:

+Added Graphics Manager
+Refactored some lazy code

I'll start off with first one. I have added a Graphics manager that is responsible for containing the current Tiles for the screen's "board". (In SFML, Sprites and Images are divided. So for display purposes, I need an array of sprites whose images change depending on the position of the player. Thus, the map is updated every time the player moves.) There's a struct called Tile who contains a Tile's image, a Tile's Sprite, and a Tile's Type (labeled terrain). So the idea is that my Graphics Manager class has a 2 dimensional vector of Tiles which I change whenever the player moves.

I'm taking an approach where the player has 2 hit-boxes making it possible for him to go between tiles (No slopes for the win (Maybe next time (This is getting really nested Posted Image ))). My Collision class will handle collision, and if it finds collision it'll pass a set of points and a type of collision to my Physics class, which is responsible for determining the physics (Where the player should end up when they collide with a block / Figuring out Velocity and doing Algebra problems, the general stuff). Physics will determine where the Player should be. For pure ease of use, readability, and expansiveness purposes, there is a separate class that handles movement which the Physics class calls. Then, my Graphics Manager's Map will be set and it'll render everything where it should be.

Now to move on to the elephant in the room, the second one. My code for the Graphics Manager and the Map manager was pretty bad, so I'm still refactoring (I really didn't think through my Map Posted Image). Overall, I believe that development is coming along (albeit pretty slowly, I keep on browsing the web trying to figure things out.)

I believe these development posts are really helping me get my thoughts together and continue development. Any recommendations for handling things and / or corrections are welcome in the comments below. cheers :)!


[Structure] Stop The Catch All's!

Posted by , in Case 28 October 2012 - - - - - - · 699 views

How do you write your classes? Are they neatly divided into different member functions, each one handling a small responsibility that plays into the larger responsibility of the class? If they are, good for you! You're following one of the main Principles of clean code, the single responsibility principle. However you're taking it a step further. Instead of only applying it to your class, you're applying it to your functions too.

Wait, do you have the common Update() function? Or how about the Logic() function? You might have your classes neatly divided up, however this will ruin your whole class. The point of the single responsibility principle is to make your code easy to read and to make it easy to understand why you're doing what you're doing. Calling
Collision.Physics().CheckCollision(Collision.GetNextTile(), Collision.GetNextTile())
would be almost impossible to understand, that's why you divide you Tile Manager, Physics Manager, and Collision Manager into separate classes. So calling Collision.Logic() or Collision.Update() ruins the harmony. What does Logic() do, what does Update() do? Wouldn't it be far easier to read if your code was calling if it was structured like this:
for (int CurrentTile = 0; CurrentTile < Collision.NumberOfTiles(); ++CurrentTile)
{
	  Collision.CheckTile(CurrentTile);
}
if (Collision.ThereWasCollision())
{
	  Physics.AcceptCollisionPoints(Collision.GetCollisionPoints);
}
It would be. That's why calling an Update() or Logic() function is bad. No-one will have any idea the sum of what that function does. Imagine going back to your code in a month (Wait, do I still have to give my Physics object the collision points, no Update() does that, what about testing Collision on slopes?....). You'll have no idea what functions you need to call, and it would probably result in you searching through your Physics and Collision classes trying to figure out what's doing what.

This often becomes and issue of coding the right way or going the lazy path. A lot of times you just want to write the "catch-all" Logic() or Update() function because you're lazy or don't want to write down the extra code. Now, if you're going to be doing what I did in the code above many times, then it would make sense to create a function that does it for you. You just need to give it a proper name (Collision.CheckCollisionandSendPoints(Physics)). Now, there is probably a better name for it, however I just couldn't think of one (Stupid Me Posted Image!).

Even if it's more code, coding the right way will pay out in the long run. Resulting in adding features extremely easy. For example, when I made breakout my code was filled with these functions, all kinds of extremely specific properties, and a code-base that resulted in needing fifty classes passing to each other, making adding power-ups a futile attempt. You often need to strike a balance. My code-base would have been more expansive and readable had I been more lenient on the principles I was using. You can never "always" apply a principle, however when it applies, it applies (When using it strictly makes sense, it really helps your code).

I hope you enjoyed this article, and please comment below with how you handle your functions. If you disagreed with it or have a correction, feel free to criticize me and mock how amateur I am Posted Image!


[Intro] Instant Gratification (And Why It's Important)

Posted by , 27 October 2012 - - - - - - · 918 views

Many people start an endless amount of projects to no avail, finishing a small amount of them because they get bored halfway through development and/or have an onslaught of new ideas. They don't see the idea of instant gratification, and they don't apply it.

What do I mean by instant gratification? Think about this: How much more happy would you be to work on your game if every time you programmed something new you saw the effects? The idea behind instant gratification is to develop small things that snowball together, meaning that you won't stop development because every step of the way you'll see the effect it has on your program. Wouldn't it be far easier to work on the coding for your game if you knew at the end of a few hours of work the new feature would be something that you could see or hear.

Now that we know what instant gratification is, how do we apply it? If you don't apply the idea of instant gratification right, then your code will either become a mess or you'll end up with half-done features that would be better left out. You have to apply instant gratification correctly for it to work for you. How I generally apply it is by testing these out in small interactive ways. I just wrote a new Input Manager, so I make an extremely small game using it (A pickin' sticks clone with two squares). With instant gratification, instead of bending features to see their effect (Coding a graphics library with unnecessary things so that you can see the effect all the time), you need to take the code you need and utilize it for something to keep you going. It would be dumb to code in special functions into my Input Manager so that as soon as I start coding I'll see the effects.

Now, using the technique above you may find there are still things you need to hard code before the gratification, however that's software design. The idea behind instant gratification is that with every new feature you make, you'll see the effect. So, that means you have to actually make the feature before you apply it. Now, what I mean is once I've actually made a feature to catch mouse clicks and see if the position of the mouse is inside a box can I write a mock up main menu.

This effect can also be considered as the SnowBall effect we'll talk about in another article. The snowball effect is where you start with expandable basic features and then expand, making sure you can see the changes for every expansion. The instant gratification effect works in tangent with that, and it's smart to make them work together.

Now, why is it important to apply this technique? It's important because as a developer, you need to be motivated. Once you're out of the learning stage and you're making games that you honestly want to see being made and love, it'll be harder to get motivated to continue on projects. Applying this will make it so that you're always happy to continue coding and developing your games.

If you liked this post, please comment down below about what you do to stay motivated, and if you didn't like it or have corrections, post them down below. Cheers :)!


[Development] Hooded Development #2

Posted by , in Development 27 October 2012 - - - - - - · 517 views

Hello all! Since my last hooded development post I have succeeded in loading a map from a file! Here's how I did it:
Map.h:
#pragma once
class Map
{
public:
Map(std::string MapFileName);
~Map(void);
const TileType& GetTile(int PosX, int PosY);
const std::vector<std::vector<int>>& GetWholeMap();
private:
int MapSizeX;
int MapSizeY;
std::vector<std::vector <int>> MapVector;
std::ifstream MapFile;
};
Map.cpp:
#include "StdAfx.h"
#include "Map.h"

Map::Map(std::string MapFileName)
{
MapFile.open(MapFileName);
if (MapFile.is_open())
{
  MapFile >> MapSizeX >> MapSizeY;
  MapVector.resize(MapSizeX);
  for (int index = 0; index < MapSizeX; ++index)
  {
   MapVector[index].resize(MapSizeY);
  }
  int LoadPositionX = 0;
  int LoadPositionY = 0;
  while (!MapFile.eof())
  {
   MapFile >> MapVector[LoadPositionX][LoadPositionY];
   ++LoadPositionX;
   if (LoadPositionX >= MapSizeX)
   {
    LoadPositionX = 0;
    ++LoadPositionY;
   }
  }
}
else
{
  std::cout << "Could Not Load Map File:" << MapFileName << std::endl;
}
}

Map::~Map(void)
{
}

const TileType& Map::GetTile(int PosX, int PosY)
{
return (TileType)MapVector[PosX][PosY];
}

const std::vector<std::vector<int>>& Map::GetWholeMap()
{
return MapVector;
}

So essentially, I have my map.txt files structured as such:
8 4
1 1 1 1 1 1 1 1
4 5 2 3 5 5 7 3
8 5 6 1 5 7 2 9
1 1 1 1 1 1 1 1
The top two numbers are the X size of the file (Number of Columns) and the Y size of the file (Number of rows). Then, the numbers under it specify certain block types! Currently you can request a certain tile in my std::vector of tiles, or you can get the whole map! What do you think of this, seasoned developers? Is it smart, or is there anything I'm forgetting / not planning for?


[Development] Hooded Development #1

Posted by , in Development 27 October 2012 - - - - - - · 629 views

Hello guys! If you don't know, I've been working on a new game called Hooded. It's a Side-Scroller with some basic RPG elements that I'll be working on for at least a month or two from now. This is my first development blog! Right now I've finished the Linear Algebra and General Math sections, and the Input handler. The development is coming along nicely (I've been working on it, my YouTube tutorial series, and this blog all day!). If anyone wants a nice SFML input handler, feel free to message me, because I'm very proud of what I've made! The plan is to make it tiled and load levels from files. If I feel like going for something harder at the end of development, I might put in a level editor!


[Engine] Handling Input

Posted by , in Engine 27 October 2012 - - - - - - · 502 views

Handling Input. For many it seems simple, and it relatively seems to be. However finding a good way to structure you're input management can be hard. Mainly because for a lot of libraries input is either handled by the Window or an Event object. When it's handled by the window, it's hard to figure out where to place your resources (Should the Input object have a pointer to the window, or should it have the window so my Draw class can have a pointer to it?). Here's some small things I recently found out when writing my own input manager.

1) Single Responsibility Is Important
I've already talked about the Single Responsibility principle, however I feel, especially in this case, that I should emphasize it. It may be tempting to have your input manager also draw everything to the screen (I mean, it already has the Window and Event, right?!?!). However, as we've already seen, that can have adverse affects. You want to make it so that everything is completely isolated to it's own object. It'd be misleading also. Imagine having your Input object also draw everything. That's confusing, isn't it! It get's even more important when you're making a tile based game, like I am, because there are more complex algorithms and functions that I use to figure out what I need to draw and how I need to draw it.

2) Being Specific Isn't Bad
In my Input class, I have a function that can get key presses by taking in the type of key press (As an sf::Key::Type) as a parameter. Then it's simply seeing if that sf::Key::Type is equal to the current key being pressed. Now, arguably, I could use this for many cases by just programming them in whatever is using Input. But that makes for a bad interface and badly written code that no one can read. So instead, I have a plethora of functions that compliment that one. The same goes for getting mouse input. I made many functions for different cases I knew I'd need instead of going through having one complicated and hard to read function. This is important because it makes your code easily readable. Imagine your game getting huge. If you get fellow programmers to help you, having that one hard to understand function that's trying to "catch-all" will make it nearly impossible for them to understand what's going on without looking through an insane amount of code.

Overall, your Input class should handle input, and only input, and should have a large amount of options for you to check different kinds of input.

If you enjoyed this blog post, please comment down below about what you'd do different and share your tips.


[Beginners] How To Move From Tutorials To Your Own Game Part 1

Posted by , in Beginners 26 October 2012 - - - - - - · 756 views

One thing I see constantly on these forums are people who are having trouble actually making a game. They understand the language and library they're using, however making their own game is hard because they are so used to either tutorials, or they don't understand the large amount of knowledge you need to have to even get started. This series of articles aim is to resolve that issue.

A game needs a State Machine.

State machines allow your program to do different things depending on whether you're in the main-menu, playing the game, paused, or the game is over. Let's look at two common types:

1) Enumerated State Machines

//STATE MACHINE DECLARATION
enum GameState { Loading,
InMainMenu,
InCredits,
Playing,
InGameOver,
Exiting }
//GAME LOOP
if (GameState == Loading)
{
    //Display Loading Screen
}
else if (GameState == InMainMenu)
{
    //Check for Button Clicks
    //Display Main Menu
}
else if (MyGameState == InCredits)
{
    //Display Credits
}
else if (MyGameState == Playing)
{
    //Game Logic
    //Game Draw
}
//////////////////////////////////
// You Get The Idea //
//////////////////////////////////

Normally these are an enumeration that is equal to whatever State your game is in. However sometimes you want a more flexible system. When you want that you can use:

2) Objective State Machine

An Objective State Machine is an object that will handle whatever Logic and Rendering it needs depending on it's state and Updates itself. Here's an example of one:

class StateMachine
{
public:
void UpdateState();
void HandleLogic();
void HandleRendering();
private:
bool MainMenu;
bool Playing;
bool Exiting;
Window * DrawWindow;
Event * CheckEvent;
GameLogic MyLogic;
GameDraw MyDraw;
}

Of course this code isn't really though through, but it should give you an idea.

That's it for today, if you have questions ask below. A great area of reference for this if you want to read further is LazyFoo!


[Structure] When To Seperate Classes and Functions?

Posted by , in Structure 23 October 2012 - - - - - - · 793 views

In the programming world (Object Oriented and Procedural) there is this meta-cognitive idea that if a class or function is too big, we should divide it into smaller classes and functions. From this spawned the basics of procedural programming. This way of thinking carried over to object oriented programming in the form of the Single Responsiblity Principle and more Principles I can't name.

So, when do you know when a class is too big? The single responsiblity principle nails it, however to me there seems to be a fuzzy line. The single responsibilty principle says every class should have one responsiblity. In my pong example, I had a GameLogic and GameDraw class to seperate these componets of my program. But imagine this: If my paddle stores it's own sprite, why don't I just have the Paddle draw my Sprite? Surely that won't interfere with handling the GameLogic!

However I kept the single responsibility principle? Why? Because without that line between what's doing what, my code would become extremely confusing. And like I said in my pong example, I want to make sure a change in my GameLogic doesn't mess Up GameDraw. Well, since the Paddle class' responsibility is to handle it's own logic, that means that making a change to my Paddle class' logic can affect how I draw the paddle. And even though I know I probably won't change the Paddle class, it's best to make sure that no matter what I'm keeping my code clean and expansive.

So back to the topic of seperation. There should be seperation between classes, since they should have one responsiblity. When you start getting into more detailed programming, we have to bring in composition. What's composition? Composition is idea that a class is "made-of" rather than "is a". However a class can be both.

If there's ever a blurry line for you, try thinking about what your class is made of and if anything in it should be it's own object. Likewise, if my Paddle Had four floats instead of a normal Rectange, I should create a new class called rectangle that my class is "made-of". My Paddle class is made of an image, a sprite, a position (Vector2f if we want to get more detailed ), and not much more. My Paddle isn't "made-of" a ball, so when I handle collision detection in my paddle I pass in a ball to the CheckCollision() function. You should always make sure the objects in your class make up the class, rather than the objects in your class being what the class uses.

I hope you enjoyed this, and if you don't know what my pong example is, you can find it here: Pong Example!








PARTNERS