I moved to a new URL! Check it out!

posts tagged with: programming

Dev Log: SFML C#

Dev Log: SFML C#
At this point I am becoming an expert at making test applications full of randomly colored squares.

Image


This was made with SFML.NET and right now is just a quick framework put together loosely based off of Flashpunk. I don't have anything concrete yet, just a basic system of Scenes and Entities, but I'm having fun putting this together so far.

One thing I'm worried about is access to cool libraries. In AS3 I make use of TweenLite and AS3Crypto a lot. I'm really surprised there isn't a big "go to" tweening library for C#. I found some C# tweening classes with some help from Twitter, but they're mostly just "here's the code, good luck" type things. I was really hoping for something more like TweenLite with a bunch of demos and test applications to try out. (I know there's tweening options for Unity in C#, but since they are built with Unity integration they don't really help much without going into the core code and tearing it apart which I don't really have the know how to do.)

I think for now I'll move forward with this while also working a little bit on my AS3 project still. If I can actually manage to make a playable thing with SFML C# in the next two weeks or so then I'll call it a success.

I am both loving and hating this period of experimenting with new stuff, haha!

AS3 State Machine

AS3 State Machine
State Machines are the greatest thing I've ever discovered when it comes to programming games. More and more I'm beginning to realize that a lot of the structure of the tools I've used is in fact a state machine!

Finite State Machines


To find out exactly what a state machine is, check out this wikipedia article which describes them as "...an abstract machine that can be in one of a finite number of states. The machine is in only one state at a time; the state it is in at any given time is called the current state. It can change from one state to another when initiated by a triggering event or condition; this is called a transition. A particular FSM is defined by a list of its states, and the triggering condition for each transition."

An example of this in action in my games are the guards in Super Ninja Slash. They have a couple of different states. Idle, Alarmed, Shooting, and Dead. That covers all their bases for their behavior.

Without using a state machine, writing code for all of that behavior can quickly become a giant mess of if statements and booleans. With a state machine, I can completely separate all the code for the guard's Idle state, the Alarmed state, Shooting, and Dead.

More Development Options!

More Development Options!
Since my last post about trying out a bunch of different engines and coding languages, a bunch more options were pointed out to me by various people through the comments and through facebook and twitter, so here's a quick rundown of these things I've never even heard of or considered until last week!

Jump Input Buffering

Jump Input Buffering
Yesterday I updated Super Ninja Slash with a few tweaks, including the addition of jump input buffering. I talked about this a little bit on Twitter, but due to the 140 character limit I think I might've caused some confusion as to what I meant by jump input buffering.

First what I mean by input buffering is allowing the player (or any source of input) to input commands into the game and allow those commands to be effective for a short window of time after they are inputted. In the case of jump input buffering, the goal is to allow the player to input the jump button and still have a successful jump even if they mistimed their input by a tiny amount.

I made some doodles to try and illustrate what exactly is going on. Imagine that this is some typical platforming game.

Screenshot Saturday: Web Stuff

Image

This week I took a short break from video game coding to crank out some web tools for a table top RPG that I play with some local friends. The screenshot above is part of a combat manager application that I wrote in php. It's main purpose is to manage all of the NPCs in a fight so that the game master doesn't have to keep flipping through a binder full of different pages of enemies to keep track of what's going on during the battle. It should make our games go along a lot quicker, although some people really like to have physical dice make all the decisions. When you have a battle involving 15+ characters though, dice rolling can get tedious pretty rapidly.

Now back to game development!