Jump to content

  • Log In with Google      Sign In   
  • Create Account

Aurioch's Time Machine

Fighting the code backfire

Posted by , 30 July 2013 - - - - - - · 2,365 views

Hello

While it's on my mind, I wanted to write here few lessons I learned in last few days.
  • If the language supports polymorphism, USE IT.
  • Design before coding.
  • Having properly structured code helps. A LOT.
  • Keep the objects closely related on one heap.
Those points don't seem to be related, right? Allow me to explain.

I've started to hunt coop related bugs in the game. Code, on the first look, seems to work perfectly; however, most code is structured like:
if (multiPlayer == 0)
{
    // do single player behavior
}
else
{
    // do co op behavior
}
or a variation of that code, depending on player which "activates" part of the code.

So, here's lesson 1: Why making numerous comparisons like that through the whole class - some of which are surprisingly volatile - when I can make new class which inherits the current one and override specific methods to adapt them for co-op mode of the game. With that, I'm also avoiding the problem of pointless allocation of resources (time and memory) for object related to co-op mode.

Sound simple, right? Well, lessons 2 and 3 strike here at the same time. Due to "designing on the fly", I have to rewrite and refactor big parts of the code to adapt them for polymorphism. This means a lot of wasted time, due to the though process:

"Hmm, I'd like to add <feature 1>. Well, I can add this code here, and that code there... *writing code* Oh cool, this works! Yaay!"
"Now, to add <feature 2>... *writing* Crap, <feature 1> code isn't good here anymore... *moving and/or rewriting code* Good, now works."
"OK, <feature 3> is next... oh not again, <feature 1> is broken. *rewriting and/or moving code*"
"ARRRRRGH, NOT AGAIN!" (I'm now at this point)

Result: lots of wasted time trying to improve the structure of the game while trying to preserve current functionality (a.k.a. trying to NOT break it).

However, while I'm rewriting the code, I have to be careful. Some parts of the code, with best example being Draw(GameTime) method where last drawn object is on top, require executing in specific order. So, I can't simply do this:
public class A : GameScreen
{
    // ...

    public override void Draw(GameTime gameTime)
    {
        // ...
    }
}

public class B : A
{
    // ...

    public override void Draw(GameTime gameTime)
    {
        // ...
        spriteBatch.Draw(player2texture, player2rectangle, Color.White);

        base.Draw(gameTime);
    }
}
because Player 2's sprite would end on bottom of everything, which may not be desirable.

Solution for that problem that I came up with is to extract relevant parts of A.Draw() and raise them to Protected level:
public class A : GameScreen
{
    // ...

    public override void Draw(GameTime gameTime)
    {
        PartA();
        PartB();
    }

    protected void PartA() { // ... }
    protected void PartB() { // ... }
}

public class B : A
{
    // ...

    public override void Draw(GameTime gameTime)
    {
        PartA();
        spriteBatch.Draw(player2texture, player2rectangle, Color.White);
        PartB();
    }
}
This is also why properly structured code is necessary. Instead of having massive amount of code inside one method, having the same code split over several methods improves maintainability and readability.

Lesson 4 is connected to 2 and 3 as well. Inside my Gameplay class (the one having actual game logic) I had few... awkward? objects:
Texture2D player1Texture;
byte player1spawnID;

Texture2D player2Texture;
byte player2spawnID;
Why is that?
Player player1;
Player player2;

public override void LoadContent()
{
    player1 = ScreenManager.Player1;
    player2 = ScreenManager.Player2;
}
In other words, I have objects related to players, whose objects persist through whole game, being created, disposed and recreated inside the class having game logic. Memory problems aside, not having player sprites stored inside player classes also forces me to needlessly duplicate the code and use additional checks to decide whose texture I need to move. Luckily, I don't need to do much to restructure the code and eliminate that annoyance.

Suddenly, improving level fie doesn't seem so important.

So, what did I learn from all that for next project (which is already defined in my head)?

I wasted too much time restructuring current project to enable modifications and upgrades. In order to avoid this in next project, I need to write Game Design Document and Tech Document in order to precisely define project and save time.

I hope that I won't repeat mistakes in the next project (Snake clone with 3D camera.)

After reading some topics on GameDev.Net, especially this one, I realized I have to learn the following:
  • Garbage collector
  • Making unit tests
Thanks for reading, I'm returning to my code. Posted Image


Salty update.

Posted by , in Battle City development 23 July 2013 - - - - - - · 906 views

Hello.

Greeting from the sunny (and disgustingly windy) beach in Croatia. It's good to get away from the regular style of life; for some reasons my productivity arises while on vacation. Only problem is the lack of the normal connection to the internet, but I've managed to snatch dad's mobile internet USB stick so I can get here on occasions, so, this journal entry will be short.

Currently, I'm trying to establish the rhythm:
  • Breakfast @ approx 9:15
  • Beach
  • Math study
  • Lunch
  • Gamedev
  • Beach
  • Physics study
  • Dinner
  • Gaming
  • Sleep at 23:00-24:00
For now, I'm more or less abiding to it. I hope I'll manage to prepare myself before next semester.
Coding update

All the major features are finished!
I'm ironing out the bugs and finishing Options screen - only setting controls ingame is now required to implement.

Aside from that, after looking through the code, I started refactoring it. Smart decision when Update method holds 50% of relevant game logic. Only problem is organizing the code; despite refactoring, the most important class still feels clunky. But readable.

Artistic update

Nothing special on this front. Sadly, the workspace here isn't suitable for practicing art... I miss my 32' TV screen and Razer Copperhead.
I'm trying some combinations for improving the HUD and message boxes.
Miscellaneous

After some talking with jbadams, I said "it's enough" content-wise and decided I'll try and sell the game once polishing is finished - at least to see and learn about marketing/distribution/PR/etc. Otherwise, I'll never stop adding new, possibly questionable, content which can be added later anyway to keep the game fresh and thus never release the game. While I don't have much time to research about that field - at least until my Math and Physics exams finish, hopefully with passing grade - I put my game on IndieDB, where I'll also update status as soon as new material to update with appears.
Thanks for reading!





July 2013 »

S M T W T F S
 123456
78910111213
14151617181920
21222324252627
28293031   

Recent Entries

Recent Comments