Category: C#

Whatever happened to SBARG?

Posted by Conkerjo – August 17, 2010

“What ever happened to EssBarg?”

“Did you ever finish SBARGE?”

“What was that game called you wrote?”

I get asked questions all the time about SBARG and it’s quite humbling to know

1) people still remember it

2) People still want to see it released.

SBARG was a game I wrote which never quite made it to release quality. This seems like a lifetime ago now, but some recent activity inside a code window has inspired me to start thinking about SBARG once again. It’s been a long time since I thought SBARG in a code context and thought it would be good for my motivation to write something about it.

SBARG went through a couple of major overhauls, the first one was following our submission to calling all games.

screenshot2

After we got some feedback from this, we decided we needed to make the gameplay much more interesting and to make major changes to the HUD and some subtle changes to the art style.

So off we went on quite an epic code change to the A.I and the general gameplay engine. As we did this we also introduced much more artwork and lots of polish to the visual effects in the game. It was looking great and we felt we were getting close.

We reached a point where we thought we were at “BETA” quality and we ran it past some friends and family to try out. We also pushed this version for XBLIG Playtest. Thanks to the ruthless testing of some of the people we realised we had some issues. The major one was people liked playing it, but it was frustratingly slow when the game started to turn on you. This was a major flaw in my naive attempt at an A.I engine. There were a lot of other cosmetic issues but these were minor in comparison to the big flaw.

From here, we pretty much went back to the drawing board with the A.I. Artistic changes were put on hold and I began writing a fresh new A.I library, and decided to actually think about it before implementing.

This turned out amazingly well in my opinion, and BRAINS was born.

It took much less work than I feared to implement the BRAINS functionality into the old SBARG game code. All my existing game engine and scenario engine continued to work. The result was all our previous level designs worked, and they ran at a suitable frame rate.

So at this point we wondered how far we could push the new engine and what doors it may open up for gameplay. The results were astounding, we managed to have levels with many more A.I enemies than we had originally planned way back when we first jotted down the idea for an RTS game. We were thrilled.

We decided that we should try to make the most of the new awesome A.I engine and redesign some of the levels. We added much more complex scenarios and many more enemies. This caused issues with balancing and so the test/tweak/test cycle began.

This took many a late night to get it to a point where it was actually playable again. Once we were happy we hadn’t made it too easy and that there were no major outstanding bugs we decided to run it past our family & friends again.

The response was great and I think everyone enjoyed it. Some people found it too hard while others wanted it to be more challenging. Some wanted more game modes, others wanted difficulty settings. All in all people seemed to think we had a half decent game on our hands. (relative of course, it’s not like we had just written SBARGCraft II)

The only thing left to do was nail down the story elements and finalize some art work. It was then ready to publish on XBLIG and see if anyone out in the real world actually liked it.

So what happened?

Well, I managed to pull my finger out and find myself an awesome real job before the previous one killed me off (literally)

Since then I’ve been so busy with work and spending all my free time with my family to make up for not doing as much in the previous 18 months.

Unfortunately SBARG never got released due to real life :(

So that’s it. That’s what happened to SBARG!

Wondering what’s next for SBARG? Me too!!! Stay tuned!

Zune HD Accelerometer Basics

Posted by Conkerjo – October 2, 2009

I was just messing around with my Zune HD while taking a short break from my main project when I thought I could port my TinyEngine to it in no time.

…

Sure enough, it took about 12 seconds.

In my dummy project I have Mr Tiny just smiling away in the center of the screen.

mrtiny

I wanted to get him to move around by just using the accelerometer. This was really simple.

I just call Accelerometer.GetState(); which returns a AccelerometerState. The AccelerometerState contains a Acceleration of type Vector3 which contains the direction of the accelerometer. I then just pass the direction of tilt to my engines Sprite Move command, as a Vector2.

Something like this

Vector2 accel = new Vector2(state.Acceleration.X, -state.Acceleration.Y);
    AccelerometerState state = Accelerometer.GetState();
    Vector2 accel = new Vector2(state.Acceleration.X, -state.Acceleration.Y);
    this.mrTiny.Move(accel * 100 * elapsed);

Clamp it to the screen

    this.mrTiny.PositionX = MathHelper.Clamp(this.mrTiny.PositionX, this.ScreenBounds.Left, this.ScreenBounds.Right);
    this.mrTiny.PositionY = MathHelper.Clamp(this.mrTiny.PositionY, this.ScreenBounds.Top, this.ScreenBounds.Bottom);

 

And there we have it, you can tilt your Zune HD to move around Mr Tiny.

Short but sweet uh?

The code is linked just below. I’ll be looking to do more Zune HD samples in the near future, as well as adding gesture support to TinyEngine.

Once I’m finished with my secret project.

Source Code (Includes Tiny Engine Source)

Redirecting the console output in c#

Posted by Conkerjo – September 17, 2009

Often when writing code in an agile way, the best way. We might write something like this.

 Console.WriteLine("I'm super awesome");

I don’t think it’s the correct way to do logging in your game or application. But such is life, stuff happens and we’re tasked with resolving it.

We need to get all these logging messages into some readable form inside my game, or app. This needs to be done by the time you wake up yesterday.

So how do we replace potentially hundreds and hundreds of Console.WriteLine’s?

Don’t panic, I have a solution. We can redirect the Console output to anything we want. All we need is an IO Stream and we can do whatever we like with it.

I decided to do this and output it to a label which scrolls in my application. It’s not the most ideal solution for viewing it either, but we went from not knowing W.T.F was going on, to seeing snippets of info fly by. It allowed us to progress with the next problem. This was a minor change and isn’t required to be in the final product so it doesn’t have to be “pretty” per say.

Here’s how I did it. I inherit from the class TextWriter and override the WriteLine method. I just happen to know all my logging calls are coming into WriteLine. Your situation may require more methods to override.

I expose an event which fires every time WriteLine is called and my app picks this up and displays it on screen. Here’s the full class

 public class TextBoxWriter : TextWriter
{
    public event Action<string> OnConsoleWriteLine;

    public override void Write(string message)
    {
        this.OnConsoleWriteLine(message);
    }

    public override Encoding Encoding { get { return Encoding.UTF8; } }

    public override void WriteLine(string message)
    {
        Write(string.Format("{0}\n", message));
    }
 } 


Once we have this class we simply have to redirect the console out put by using the Console.SetOut command.


 writer = new TextBoxWriter();
writer.OnConsoleWriteLine += new Action<string>(writer_WriteHappened);
Console.SetOut(writer); Console.SetOut(writer); 


Simple, yet effective. I should get back to work :)

K.I.S.S – C# Properties

Posted by Conkerjo – September 10, 2009

Keeping up with the K.I.S.S principle my previous post prompted an interesting debate in the #xna IRC channel.

Somebody commented

“User> Also, "public Vector2 Position { get; set; }" will transmit some bad habits to noobs. :]”

&

“<User> It expands it into a function call. If the get and set is public, it may as well be a public field.”

I missed most of the debate but here’s my take on things.

Why should we use auto properties as opposed to being maticulous and writing out the private variable? Or why bother with a property at all if you can’t be bothered to write the private variable and set and return it?

Firstly, I don’t see how it produces a bad habit. I come from a background where having to write a private accessor every time I needed a property was a very tedious task. Especially when dealing with hundreds of classes at the start of a large project, so this was a very welcome addition to .net for me as writing a private accessor just to return it and set it felt like a waste and left me with a ton of private variables I didn’t really need.

A few arguments for using them are.

  • It follows the K.I.S.S principle.
  • It looks a lot cleaner and has a smaller code footprint than writing a private property too.
  • They’re so easy to implement using the Visual Studio Snippet feature. prop <tab> type <tab> name <enter>
  • It allows you to maintain the API while giving you room for flexibility in the future to change the functionality of the get/set.
  • If a third party relied on using reflection for API, fields are treat differently to properties.

 

So what really happens when we do use these auto properties.

Not surprisingly it does something very similar to what you would do if you write the private accessor yourself. Here’s an example.

Here is my own property with my own private variable. This took blood sweat and tears.

private int myvalue;

public int MyValue
    {
        get { return myValue; }
        set { myValue = value; }
    }

 

Here is my auto property for the lazy people.

 

public int MyValue { get; set; };

And here is what your code looks like after you compile an auto property.

[CompilerGenerated]
private int &lt;myproperty&gt;k__BackingField;

public int MyProperty
{
    [CompilerGenerated]
    get
    {
        return this.&lt;myproperty&gt;k__BackingField;
    }
    [CompilerGenerated]
    set
    {
        this.&lt;myproperty&gt;k__BackingField = value;
    }
}

 

It’s just doing the same thing, except adding an attribute to say it was generated by the compiler.

Over the course of a large application or a game, you would be amazed at how much time this saves, it keeps it simple and allows you to tighten up property get/set methods later in the development cycle.

There are a lot of other differences between Fields and Properties in c# but the main ones which effect this discussion are listed above.

Thanks to Björn for giving me the nudge to post.

This post is sponsered by Björn’s XNA Adventures