Doodle Post
No Comments
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.
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.
After loading the script I get a new menu option with my script function.
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.
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.
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.
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.
After loading the script I get a new menu option with my script function.
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.
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.
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.
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.
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:
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.
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.
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.
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
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!
* 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
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:
This makes it so I can just do something like this later:
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.
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.
