I moved to a new URL! Check it out!

posts tagged with: csharp

Moving the Console Window

Moving the Console Window
Just wanted to share a quick tidbit of code that's useful for making a game with a console window for debug information. A lot of times I want to launch my game and have the console window on a different monitor, or just out of the way in general. It gets super annoying to have to move it over every time I launch a game for debugging, but then I found that I can move it with programming!

I'm going to be honest and say I don't totally understand how this works. It uses DllImport to get some functions from the user32.dll in Windows and then uses those to move the window around... I think? It should be noted that this probably only works for Windows.
class Program {
static void Main(string[] args) {
IntPtr handle = FindWindowByCaption(IntPtr.Zero, Console.Title);
MoveWindow(handle, -700, 50, 1000, 1100, true);

Core.Game.Start(); // Start the Otter game
}

[DllImport("user32.dll", EntryPoint = "FindWindow", SetLastError = true)]
public static extern IntPtr FindWindowByCaption(IntPtr zeroOnly, string lpWindowName);

[DllImport("user32.dll", SetLastError = true)]
internal static extern bool MoveWindow(IntPtr hwnd, int X, int Y, int nWidth, int nHeight, bool bRepaint);
}

I use functions to find the console window by it's name which can be accessed through the Console class in .net, and move the window by its handle. I give it a negative X coordinate because that pushes it onto my left monitor, so now every time I launch the game my console window appears and immediately gets pushed over to the left monitor. Neat!

Easy CSV Parsing in .Net

Easy CSV Parsing in .Net
Working on getting a public build of my latest game jam game up, and one thing I'm experimenting with is using CSVs for certain types of data. There's a bunch of enemies in the game that all have different stats, and usually I just store this information in the class for each enemy. Storing this data on a CSV has the benefit of being able to see all the data next to each other.

While I could achieve the same thing by having a dictionary set up in the code itself, storing the data in a csv file makes it a little bit easier to view and edit. Tweaks can be made more easily, and storing a bunch of data in dictionaries in code can get a little crazy looking depending on how much data there is to store.

Image


At first I was using OpenOffice Calc for my CSV editing, but there's a huge down side with that: file locking! OpenOffice thinks it's an awesome idea to put any file its editing into a crazy lock down mode, so I can't even read from the file while OpenOffice has it open. So I had to ditch it, and instead I'm using Ron's Editor. So far this is the best free csv editor I can find, even though it's a quite bit more strict about editing than a big spread sheet.

Now for loading the CSV data I'm using CsvHelper which makes parsing a csv as painless as possible. My enemies.csv looks like this:
EnemyType,Supply,Mass,MaxHealth
BasicTest,1,1,10
BigSkeleton,10,0,-1
TestPart,0,0,5

And the code to parse that looks like this:
var csv = new CsvReader(File.OpenText(Assets.Data.Enemies));
while (csv.Read()) {
var record = new Record();

record.EnemyType = Util.GetTypeFromAllAssemblies(csv.GetField<string>("EnemyType"));
record.Supply = csv.GetField<int>("Supply");
record.Mass = csv.GetField<float>("Mass");
record.MaxHealth = csv.GetField<int>("MaxHealth");

Records.Add(record.EnemyType, record);
}

I'm using a tiny class called Record to store the data. Record looks like this:
public class Record {
public Type EnemyType;
public int Supply;
public float Mass;
public int MaxHealth;
}

I end up loading the csv data into a dictionary with the enemy Types as the key, and the Records as the values. When an enemy is created it can look into that dictionary by using its own type and get out a Record object that contains all the data it needs to initialize.
var r = Records[this.GetType()];

AddComponents(
new Team(TeamType.Enemy),
new Heart(r.MaxHealth),
new SpriteEffects()
);
Group = O.GroupGameplay;

if (r.Mass > 0) {
AddComponent(new PushAway(r.Mass, Tag.Enemy));
}

var h = GetComponent<Heart>();

h.OnDeath += () => {
Death();
};
h.OnDamage += (d) => {
};

Pretty straight forward! I think I'm going to extend this to expose more fine tunings of things. It might also be fun to leave the files totally exposed for players to mess around with as well.

Dev Log: Jam Game Stuff

Dev Log: Jam Game Stuff
I've been doing pretty bad on blog posts this month so far, but I've been getting a lot of cool stuff done lately. I've been mostly focusing on my game jam game from a few weeks ago. I want to get that into a good playable state and do some testing at a local indie gathering and hopefully push it out to the public after that. This is another game that I'm making using my 2d .net framework Otter.

During the game jam I started to use the idea of components a lot more. The entity component system is the new hotness in video game programming as it seems many developers are starting to favor it over the old school hierarchy tree of classes. Here's a pretty good write up explaining how it works.

Image


So far all of my games depend very heavily on the whole class hierarchy tree. Like I would have a base Entity, and then maybe a game specific Actor which extends Entity. Then I would have a MovingObject which extends Actor, and then a PlatformerObject which extends MovingObject. Finally the player would be a class (like the momma from Offspring Fling) that extends PlatformerObject. It seemed like a good idea at the time!

Now with this jam game I'm working on I'm trying to use components as much as possible. It may be a little overkill, but I'm using this as a learning opportunity.

Image

For example here's what the Heart component looks like. I use the Heart for everything that can be involved in combat in some way, like anything that can take damage and all that stuff.

There's also something as simple as the RenderAllColliders component, which is handy for just slapping into an Entity if I want to see all of it's colliders during runtime. It will only render colliders on its parent Entity if the game is running in debug mode which is pretty neat.

So what does an Entity look like with all this component stuff? Here's a quick snippet from my main player class:
AddComponent(new CameraTarget());

// Add the movement and pass the axis from the controller.
var movement = new MovementTopdown(7, 0.3f);
movement.AxisMovement = c.Movement;

// Add the weapon, and pass it the shoot button from the controller.
var weapon = AddComponent(new AngelWeapon());
weapon.Button = c.Shoot;

var special = AddComponent(new Components.SpecialAttacks.Shotgun());
special.Button = c.Special;

AddComponent(movement);
AddComponent(new ClampInsideScene());
AddComponent(new SpriteEffects());
AddComponent(new RenderAllColliders());
AddComponent(new PushAway(2, Tag.Angel, Tag.Orb));

Later if I need to I can use GetComponent to retrieve any of those components if I need to change anything on them.

So far I'm really liking this approach, and it seems like it's the way things are heading in the video game programming world as far as I can see. I'm a little concerned with the performance of using a lot of components with GetComponent() running all the time, but it's probably not going to have that much of an effect.

Dev Log: Otter Updates

Dev Log: Otter Updates
Some crazy updates happening in the dev branch of Otter recently! Here's the scoop on what's been going on:

* Changed how Entities are Added to the Scenes. The Entity's Added() method now fires when the Entity is actually added to the Scene at the end of the current frame. The Added method also fires after all Entities in the adding queue have been added.

This means that if you're adding a player object, and then an enemy object afterwards, and the player object needs to reference the enemy object in its Added() method it should be possible to do so.

* In a similar fashion the Components have been changed in regards of when their Added() method is called. Components in the add queue are added at the beginning of Added, UpdateFirst, Update, and UpdateLast, and their Added method will fire when they are actually added to the Entity from the queue.

* GetComponent can now return Components that are still in the adding queue if none are found on the Entity itself.

* GetComponents() returns a list of Components of a certain type.

* Axis now has access to Up Down Left Right buttons. Very handy for having to check for button presses on an Axis and not having to create 4 separate buttons to do so.

* Repeat has been changed to two bools RepeatX and RepeatY.

* Util.Log() now behaves like a format string call (similar to Console.WriteLine())

* BitmapFont support is coming along and now supports data for three different bitmap font generators, as well as support for standard monospaced fonts.

* RichText characters can now be accessed and manipulated individually. This means you can do stuff like animate properties of characters yourself instead of relying on the mark up in strings.

* Other minor clean up and fixes that should make stuff better overall.

In other Otter updates be sure to follow the journey of Otter Pup 681!

Visual Studio Asset Class Generator

Visual Studio Asset Class Generator
One of the key things I learn from every game jam is what the major knots are in my work flow. The past two jams I did with Otter had a common issue: getting assets from my assets folder to the game was annoying!

I don't like to rely on strings in my code to reference things. A typo can cause a major headache, especially when referencing a path to a file that needs to be loaded. Usually I like to just keep an Assets.cs class that has a bunch of static references to various file paths. Something like this:
class Assets {

static string Asset(string str) {
string assets;
#if DEBUG
assets = "../../Assets/";
#else
assets = "Assets/";
#endif
Console.WriteLine("[ASSET] Register asset {0}.", assets + str);
return assets + str;
}

public static string ImageIcon = Asset("img/icon.png");

public static string ImagePalette = Asset("img/palette.png");
public static string ImageTile = Asset("img/tile.png");
public static string ImageTiles = Asset("img/tiles.png");

// and so on...

This makes it so I can just do something like this later:
public Image Image = new Image(Assets.ImageIcon);

Instead of having to remember that the path to the icon whenever I want to use it, I just keep a reference to it in once spot. This drastically reduces the amount of typos I could possibly hit, and it also makes it easy to bring up with auto complete and intellisense stuff.

However the process of saving out a png, then remembering the exact path to the png, and then opening up Assets.cs and adding lines to it for every new asset every single time becomes a giant pain. The more assets I have, the more complicated this becomes, and the more I'm modifying the assets folder the more annoying it gets! Back when I was using Flash I created an asset generator script to overcome this, so why not just do the same for C#? Wouldn't it be awesome to just be able to click a button in Visual Studio and have an Assets.cs generated from the files in my Assets folder?!

Download AssetClassGenerator.exe (v1.0 Windows 11kb)

This program will execute in the console and build an Assets.cs file based off of the Assets folder in your project directory. This was built with my specific use case in mind so this may not be an exact fit for your needs currently.

Otter Updates

Otter Updates
Some quick updates to Otter in the dev branch!

* Added the Polygon class: For the Polygon collision stuff I created a quick helper class to keep track of the points in a polygon. This class also has some neat functions that are used in the Collider class to figure out polygon collision stuff.

* Added PolygonCollider: Now there is an actual PolygonCollider in Otter! You can use it to check for collisions with any other type of collider too. I expect there to be some bugs so be on the look out when using it.

* Various Collider Updates: Some of the colliders had some minor bugs so I squashed all of the ones I could find.