I moved to a new URL! Check it out!

posts dated from: november 2014

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.

Doodle Post

Image


Got sick for Thanksgiving and still recovering. Not enough brain power to program yet so just doodling for now.

Doodle Post

Image

Google Spreadsheet and nanDeck Workflow

Google Spreadsheet and nanDeck Workflow
One of the things I've been fiddling with for the past month or so is a prototype of a board game inspired by stuff like Dominion and Legendary and a mix of other stuff. It's been a collaboration with some of the local developers in the Phoenix area, and we we're getting to the point where hand writing a bunch of cards was getting really cumbersome, so I looked into tools for generating cards.

Image


I ended up finding nanDeck, which at first looks like a pretty weird program. Okay it is a pretty weird program, but after spending some time with it it really does get the job done. There are some basic tutorials that can get you started, and some neat posts about it here as well.

nanDeck has the ability to read data from a csv file. At first I was using Open Office to manage some spreadsheets and export them to csv files for nanDeck to import, but that wasn't going to last if I wanted to collaborate with others.

I converted all of my spreadsheets into a Google Drive spreadsheet so that I could share it with others, but now the question was how can I take all of that sheet and spit out a csv for each individual spreadsheet that is a part of the document?

The first thing I needed to do was download and install the desktop version of Google Drive. This lets me access my files on Google Drive as just files on my computer, much like Dropbox.

Next I needed a csv export script. I found one here, and then modified it to fit my needs more. The script runs the onOpen method and that adds a custom menu to the document so that anyone that the document is shared with can also use the script. Adding a script to a document is located in Tools, Script Editor.

Image


After loading the script I get a new menu option with my script function.

Image


The script ends up spitting out a bunch of csv files into a folder on my Google Drive. These folders end up syncing to my computer, and now all I have to do is move them from there into a folder where my nanDeck project lives.

Image


Image


That's where a Windows batch file comes in handy. I whipped up a quick batch file that will take all of the csv files from that generated folder and copy them into my project folder. Using some custom system variables it's easy to make this work on my various work computers just by setting those variables on each of them. Just using XCOPY works great.
XCOPY "%NANDECK_CSV_SOURCE%" "%NANDECK_CSV_DEST%" /S /Y /I

After the batch file runs all I have to do is click "Validate Deck" in nanDeck and it will update the data from the newly updated files, and now my new deck is ready to rock. Eventually I can even use nanDeck's command line features to copy the files and render the new deck from the batch file. Neat!

There's one major issue to look out for and that's using the Linked Data editor in nanDeck. If you click the button to edit the linked data, nanDeck seems to place the .csv file in lock down, meaning that XCOPY cant write over it. If this happens you'll have to close nanDeck to unlock the file so XCOPY can do its thing. As long as you don't use the linked data editor you'll be okay.

Doodle Post

Image

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.