GOTO or not to GOTO...that is the question....

Hey guys! Been a quite a bit huh?

Well a lot has been going on, but when I reflected upon an assembly someone handed me today I saw something that got my writing juices flowing again.
(Plus I totally have to take a break from Skyrim :))

When you open someone else's code you never now what you're going to find. Is it going to be that Christmas present you've oh so been waiting for or the dreaded pair of white socks....

Today I got the socks.

Enough with the metaphors *turns on a skrillex live set* let's get technical.

What I found was the GOTO keyword I was taught long ago learning Assembler but was quickly told to forget again once I started C and at the latest C++ and C# once the object orientation started.

Now I've done some reading on the subject and discovered the GOTO actually has defenders and one actually has to pick sides in the discussion (which has me pretty surprised because I thought this subject is a "no brainer").

Before I get going: I'm on the no GOTO side of this debate (from here on known as the Light Side).

I'm going to try my best on picking an example which is easy but at the same time not too trivial.

Starting off with GOTOs

OK, still kinda trivial, but this is only to make a point and have a base to "improve" upon.

Program:

• So we start of randomly picking a number between 0 and 2
• Depending on the index we alter the string and jump to one of our labels
• CorrectOutputThenLaunchSubroutine alters the string again (because we <3 DnB right?)
• ExecuteSubroutine display the string on the screen and we're go to go (pun not intended)

First of all: NO Intellisense for labels...need I even continue? I don't know about you but I've pretty much reached the point where I let the IDE generate as much code as possible for me. So now I'm going to start memorizing label names which are supposed to make my life easier....sorry but not me :)

Next up which you Assembler programmers all remember is: The order of labels are crucial, order them wrong and you're going to have code executing in all kinds of directions.

Finally in terms of scalability, keeping track of a small number of your own labels isn't going to be the hardest task in the world, but imaging that small number growing and growing and having that code handed to you from a colleague developer...get your machete and start exploring.

OK enough GOTO bashing. I mean in low-level programming it is pretty much the only way to go. But it shouldn't be the way to go in high-level programming. Especially when there are so many alternatives to choose from which can make your own life easier and that of your colleagues.

To keep my syntax as DRY (don't repeat yourself) as I can get it and because my software engineering lecturer taught me a strong dislike of the switch/case, I like to use the following approach:

• Dictionaries
• Delegates
• Lambda Expressions

 If you got it, flaunt it and C# definitely has some features you can use :)

The first step is to package what we did in the case blocks into a pseudo function signature which we can use as a delegate. Because in each block we're basically taking a string, changing it and returning it we can define the following delegate:

The myStringDelegate

Remember function pointers from C++? *wink wink* I knew you did.
For everybody else, this is "merely" a data type which we can later give a function signature (or a lambda expression) and Invoke that function whenever we want.

The next step is to assign the numbers we used in the first example for the cases in our switch block to the delegates we are going to create. This can be done by declaring and filling a Dictionary with int as the index and myStringDelegate as the value type as such:

The Dictionary which maps an int to the corresponding subroutine / lambda expression

Now at the first glance the syntax may look a little confusing, but take a second and let it do it's work and you'll see it's only a couple of harmless lambda expressions.
The dictionary is awaiting a myStringDelegate which receives and returns a string. The lambda syntax goes like this:

 (/*parameters here*/) => {/*operations here*/}

So basically the functionality of the entire program can be extended upon by adding another entry to the dictionary and changing the max value of the number generator to the length of the list. And I personally find it very easy to read (once you've gotten the hang of those lambdas :)).

During the run time of the program, after a number has been chosen using random, the corresponding code block can be invoked by one single line of code:

Method invocation via the subroutineDictionary

Now if you ask me, you can't beat that with a stick. Again concerning scalability, you don't have to touch this part of your code at all. You merely add an entry to the dictionary!

The dictionary functionality can also be used to store different data types to alter the flow of a program. Remember those mean things the program had to say about DnB and how we got rid of them? If you declare and fill a second Dictionary the same numbers can be linked to boolean expressions to determine if a string should be replaced during runtime:

The dictionary which determines if a string should be replaced

Using the replaceOutPutDictionary you can easily create a condition during runtime and replace those pesky string which do not <3 DnB:

Replace condition

That way we can make sure the program always <3s DnB :)
Before I recap here's the whole thing remodeled which semantically produces the same results but is (in my opinion) much more readable and can easily be extended upon if the requirements arise:

Version 2.0 without those pesky GOTOs

What did I want to achieve with this post? Well basically to show that there are other ways of doing things nowadays without having to resort to the use of a GOTO.

Think of your fellow programmers when you write code, at least have the intention to produce highly readable, understandable and extendable code. Because it could be you one day on the other side, machete in hand, trying to figure out the the mazes other people have built and hoping to make it back out alive.

I leave you with Randall Munroe's (www.xkcd.com) thoughts on this matter:

http://xkcd.com/292/

I'm off to Skyrim...still  haven't reached level 50 :) shame on me.

Microsoft XNA 4.0 Part 2 - Game Basics

Hi guys,

I know it took me quite a bit to go and get me a simple cup of coffee...but now I'm back. I've completed some first small steps understanding the fundamentals of a XNA game and will use this post to document what I've learned.

So let's go.

We're going to create a "Windows Game(4.0)" project which can be found in the standard "create new project" dialog of Visual Studio 2010 (as I described in my last post).

You'll notice that this project template is filled with quite a bit more content from the start compared to
a standard C# project. But no need to worry, it's not too complicated to find your way around when you take a look at the separate components.

*During the following explanation I will be using the standard project and class names generated by Visual Studio 2010 (WindowsGame1, Game1 etc...) so apply your names as needed*

We'll start on the project level of our generated solution:
A standard XNA Windows Game solution consists of two different projects:
WindowsGame1 - this project will be used to write game logic, load textures and models, acquire computer resources - in short this is where the magic happens.

WindowsGame1Content - remember I just mentioned we will be able to load textures, models and other neat stuff? Well this is where we're going to store it. This project is used to refer to all game resources that can be declared as content (sprites, models, music, animations etc.).

Now that wasn't so bad now was it?
If you open the content project, you'll see that aside from a couple of references, the project is completely empty. We'll take a look at how to load and render content a little later.

First we'll take a look at the classes generated in the WindowsGame1 project and find out a XNA Windows Game works.

The following is a class diagram of the WindowsGame1 project (compliments of Visual Studio 2010, just right-click on the project in the solution explorer, select "view class diagram" in the dialog and voila).

 

So let's get to know our two new classes shall we?

Program - This static class is used as the entry point of the XNA Windows Game. In Program an instance of our Game1 is initialized and told to Run. That's all we need to start our video game.And for now that's all we need to know about Program and until we add anything to it, that's all it does:
It starts our game.

Game1 - This class is where it all comes together, the loading of content, evaluation of game logic, rendering of the video game, reading user inputs....you see where I'm going with this? :) But again, if we take a look at the provided methods of our Game1 class, we'll see it's not as complicated as one would think.

Now that we know what the separate projects are for and what the standard classes are used for, let's open up Game1 and see how a XNA Video Game works.

Here are the 5 basic methods that can be used to manage a whole game:
The first three methods are called once during a XNA Video Game, and are used to manage the content used to construct the video game.

Initialize() - This is the first method called when Game1.Run() is called from the Program class. It's purpose is is to load non-graphical resources (stuff you won't be drawing :P) and to query if needed services are present (Web, Network, etc.).

LoadContent() - Once Initialize() is finished, this method is automatically called to load all graphical content (you guessed it, everything that will be displayed on-screen).

UnloadContent() - This is called as a clean-up method to unload all the content we loaded at the beginning of the game.

The final two methods, are placed inside of a never-ending loop. These are used control and display the Video Game.

Update() - This is where the game logic is evaluated. Movement, collisions, scoring - all that kind of logic is placed in this method.

Draw() - And finally, this method contains all the logic needed to display are game content.

And that's all folks.

I tried to keep this post pretty abstract without going into the code (yet). Before I started on this post, I fought my way through the MSDN documentation. Doing this helped a lot in understanding how the separate parts of XNA Video Game work together.

In my next post we'll be writing our first little game and tackling the following subjects along the way:
- How to load content into a game
- Rendering the loaded game content
- Evaluating user input

I hope this post helped in taking a little bit of the magic out of the inner-workings of a video game. Next time we'll be seeing some first results. I promise :)

Microsoft XNA 4.0 Part 1 - Development Environment

In this series of blog posts I will be documenting the progress I make with the Microsoft XNA 4.0 game development framework.

My plan is to start with the very basics (development software, project template, etc)  and work towards programming a simple 2D game and then ultimately a 3D game using models I will create with Cinema4D.

There's the road map right there...so let's start with what we'll need for the ride:

Microsoft Visual Studio 2010
The Microsoft IDE used to program for just about anything with the Microsoft logo on it. I will be using the Ultimate version provided in my student license. If you don't have a copy of Visual Studio 2010, you can pick up Microsoft Visual C# 2010 Express for free.

(Feel free to try this with Visual Studio 2008, but I finally migrated to 2010 a couple of weeks ago and I'm sticking to it :))

Microsoft XNA Framework
The XNA Framework is used to develop video games for Microsoft platforms: Windows, Xbox 360 and Windows Phone. So again, pretty much everything Microsoft. The latest version to date is the Microsoft XNA Framework 4.0 and can be directly integrated into Microsoft Visual Studio 2010.

When these two components are installed, you're ready to dive right into the gaming business...at least theoretically that is :)

You can check if everything installed correctly by starting up Visual Studio 2010 and opening the "New Project" dialog. Select Visual C# on the left, if everything worked out fine XNA Game Studio 4.0 will be listed at the bottom. When you click it you will be able to choose from different project types:

During these posts I will be working with the "Windows Game" project template. These projects can be used on the Microsoft Windows and Phone platforms. I don't think I will be experimenting with Xbox 360 as I have a Playstation3 (*hehe maybe I'll get browny points for mentioning Sony here, in there war against the internet*).

So much for part one, next time I plan to write about the basic inner-workings of a windows game, how to get started and such. Now time for coffee.

Introduction

This will be my first attempt at blogging so I hope I do OK. I'm a 6th semester IT student living in Germany, closed to finally getting that sought after bachelors degree. The title of this blog sums me up pretty well: I'm into computers, movies, video games, television series, music...a geek I guess.

During my programming studies I have always been dependent on message boards, programmer websites and blogs. So I decided to step up to the plate and to document the programs I make (and the mistakes I make along the way) in hopes of giving something back to the internet community that has helped me out of some tight spots. I primarily program in C# but will be trying out Android (Java) programming in the upcoming weeks.

It won't be an strict programming blog, I plan to write about my interests as a bit as well.
My first project will be to document my progress working with the XNA 4.0 Framework from Microsoft.
I'll start with the basics, and we'll just take it from there.