Friday, June 14, 2013

Learning TDD

So starting to learn TDD has been on my mind for some time. I've had a few people ask me to use it during my tutorials and I've never really "had time". It would be more appropriate to say that I didn't want to start using it in my daily coding since I don't have to use it during my day job. In other words, it didn't interest me enough to begin using it.

So this week I decided to pick up a book on writing Unit Tests and started a course on TDD. As the instructor of the course said, Writing good tests and doing TDD are 2 completely separate skills. You can follow TDD and still write bad tests. You can also write good tests, but not have a failing test drive your development.

After getting started I realized something yesterday. I started my Intro To Photon videos and blogs. When I became frustrated with the code, I started over again from "scratch" having gained an understanding of how things could be set up. It also allowed me to look at the Server2Server code in the newly released Photon 3.0. When I became frustrated with that code set, I started over yet again and created the Photon Framework. Each of these was better than the previous version and I wanted to look into TDD, but got myself wrapped around the axle for how to "test" code that wasn't mine.

In the end, I decided that my tutorial videos will continue to use the current Photon Framework, but in the background I have started over from scratch yet another time. This time, however, I started with TDD. I started with nothing more than the notion of a server that could add and remove clients from a list. Since yesterday, I have created a suite of 32 tests that cover 12 functions which are helping me keep to my "design specifications" that I have built over the last 3 iterations of the same set of code.

The more I play with TDD, the more I like how it sets me up to accomplish what I want to do and still gives me the ability to refactor it and ensure that the same basic rules still apply.

Wednesday, June 5, 2013

Value types vs. Reference Types

I won't claim to be an expert by any stretch of the imagination. However, I have learned a few tricks in dealing with the conversion of C++ libraries to C#.

Let me begin with a bit of background. I enjoy working with Unity3D. It has one small "problem", to work with C++ you have to buy the professional version, a small setback of 1500$. To counteract this problem, I've been working to convert a few C++ open source libraries to C#. Namely Recast Navigation and Bullet Physics.

"Why bother," you might ask? Well for one, I can't afford the 1500$ price tag for Unity3D. For another, taking apart the library helps me understand how it works. Furthermore, I can code Editor and Inspector enhancements for Unity3D to take advantage of the library.

Back to the topic at hand. A value type, when working with C++ and C#, is an object that contains its data directly. A reference type, on the other hand, is a reference to an object that contains its data. Let me explain it another way. If I hand you an apple, it would be a value type, I am passing the object directly to you. If I hand you a gift voucher for an apple, I still gave you an apple, but unlike the physical apple, when you go to get the apple for the voucher, it may not be the same one pictured on the voucher.

So what does that have to do with C++ and converting to C#?

In C++ everything is a value type, both class and struct. If you want to pass a reference to it, so you can modify it and give it back in the modified state, you have to do one of two things, either pass by reference by adding an &, or pass by pointer meaning you add a * at creation. Without this, when it gets to the function, if you make any changes, those changes are ignored when it gets back to the area that called it.

In C# classes are a reference type, this means that if I do A = B; A now points to the same apple B points to, if you want to make a copy of B to use with A, you have to create a new object, pass in the values of B, and give that to A. A = new Foo(B);

There is a handy little trick when it comes to C#. If you wish to always pass by value, that is A = B; gives a copy of A, you simply declare the class as a struct instead: public struct Foo{};

One minor word of caution, when you use structs, you cannot inherit from other structs or classes, only from interfaces. This could lead to code duplication if you are attempting to make a derived struct.

Anyway, this was today's lesson for me as I work through the conversion of Bullet Physics.

Wednesday, May 29, 2013

Building Libraries

So in my spare time, I like to play around with small components of various games and try to write them into small libraries. The nice thing about doing it this way is that it has no ties to a specific game. So the last few weeks I've been playing with a few different libraries.

First up, Behavior Trees. I was on AIGameDev.com and they have a few posts covering Behavior Trees rather than using Finite State Machines. So I looked at their code and built up a small library with some test cases to play around with their concept. I ran into a snag in that once it successfully made it through the behavior tree, you had to rebuild the tree, or hack the code to reset it. So after some more digging around I found snippits of other behavior trees and was able to make a small library with various nodes and put together a small demo in Unity3d showing a block moving to other blocks to "eat" them when it got hungry.

After that I started up the previous blog post and decided to begin looking at small scripts to handle cameras for most Strategy games (top down, scrolls when the mouse is near the edge, zoom with scroll wheel) and I've decided to make a permanent home for my musings. So far it only does some simple camera movement.

Today I'm looking into how to use Unity3D to make a radar system. I want to build it to behave both like an MMO with the player in the center, and like an RTS, with a camera frustum outline and the entire map displayed so you can click and zoom to that location.

As with everything I work on, I hope to build these into tutorials so that others can benefit from my musings as well.

Monday, May 27, 2013

Starting the blog again - 4X and MMO Games

I've decided I'm going to use this blog to put my thoughts on paper while I play with various mechanics and play around with game ideas. Today I wanted to begin with just making a simple camera controller that scrolls at the edges of the screen. Which leads to me why I chose this simple project.

I've always been a big fan of what are called 4X games. Specifically I enjoy the Turn Based Strategy games such as Civ 4, Masters of Orion, Space Empires 4. For those that don't know, 4X stands for eXplore, eXpand, eXploit, eXterminate. Most feature pretty indepth tech trees, have multiple paths to victory and can suck many hours of your life away.

A few games have tried to make this take the form of an MMO. EVE Online could be classified as a 4X game, Mankind.net is a smaller, nitch game that has changed a few hands, and Beyond Protocol was an indie attempt and probably could have done much better than it did.

So I find myself thinking about what I would do to make a 4X MMO game. It is something that has crossed my mind before, but not in great detail outside of saying that I'd want to make it a cross between EVE Online and Civilization 4.

I like several concepts from various games I've seen over time. A couple of them are Component Configuration and Design.

Space Empires, EVE Online, and StarDrive all share at least one concept: ship configuration. Whether you choose a ship because it has strong shields, or you design the ship from the ground up with a specific hull and add shields or armor, all of these games let you configure the ship the way you want.

Star Wars Galaxies, before NGE, and Beyond Protocol had an awesome setup with components that you designed. Depending on the materials you used, a weapon could be created with drastically varied stats. This leads to a more nitch market of gamers who like to min/max things and like to play with designs to get the most out of their materials.

Lastly, one thing I've covered before is material acquisition. EVE Online, Star Wars Galaxies, Beyond Protocol, and Saga of Ryzom have all covered interesting aspects. EVE Online has you able to get materials from mining, but the materials you can mine vary depending on where you are, from safe space to null security space. Star Wars Galaxies had materials that changed on a week by week basis leading to vast databases created to know what material was available on which planet during a given week. Saga of Ryzom had harvesters who could search for harvest nodes using skills, and Beyond Protocol had a bid system if more than one person was on a planet with a mine, you would bid on the minerals with the top 4 people getting 25% of the minerals each, if only 2 people bid on the mine, 25% went to the second person and the remaining to the top bidder, if there were 3, 25% went to the bottom 2 and 50% went to the top bidder.

These 3 things can be pretty powerful and add a subtype to the genre that allows people more specific play style. I want to go over more of them in detail while I play with my development.