Tag Archives: C#

Glide update: Tween overwriting

I’ve just added support for property overwriting to Glide, my Tweening engine for C#. This functionality exists in Actuate (a great Haxe library from which I’ve taken a lot of inspiration) and I’ve wanted it in Glide for a while now because it’s just so darn handy.

Imagine you start a tween off on its way:

…but then something changes, and now you want your image to travel instead to (X = 500) instead, and it should only take two seconds:

At first this will work fine, but when the second tween finishes, suddenly the first one takes precedence again and your image will keep moving towards (X = 100). You could cancel the first tween, but that would also cancel the movement towards (Y = 200).

Now, creating a new Tween on an object that’s already being tweened will cancel the movement of any properties that are currently being tracked. In the example above, the new X tween would overwrite the old one, the original Y tween would keep on working, and there’s no need to manually cancel anything.

The old behavior is still available; just pass false to the overwrite parameter. I’m pretty sure that won’t be necessary in the majority of cases, but it does exist if you want it.

Iridescence mobile development update

When I was at the Boston Festival of Indie Games with Iridescence, I’d tell anyone who asked about the mobile versions that they were about two or three weeks out. At the time I had every reason to believe that to be the case, but it turned out to be a little more complicated than I had anticipated.

This will be a moderately technical post, so the short version: Iridescence is still coming out on mobile devices (iOS, Android, and even Windows 8 phones), but it won’t be as soon as I had hoped.

Now onto the technical side of things.

Iridescence is written in Haxe, which is a language that aims to act as an intermediary between platforms. Instead of writing C++ for desktop platforms, Java for Android, Objective C for iOS, and C# for Windows phone, Haxe allows you to write in one language for all platforms, translating itself into the one that’s best supported by each target. On top of Haxe comes OpenFL, a framework that mimics the Flash API but has support for OpenGL and runs as a native application. A single codebase, a familiar API, and great performance? Almost sounds too good to be true.

It is.

A week before launch, I plugged in my Android tablet to get a build running. It had been my intention to have a tablet on the exhibition table so people could see the game running on a variety of platforms. I’d had it working in the past without any issues and without having to change a single line of code, so I expected it to be uneventful.

It wasn't.

It wasn’t.

I’m at a total loss to explain what’s going on. At first I thought it was just a matter of the renderer acting up, but the music doesn’t start either. Worse, I get this same behavior if the app is entirely empty. Other games work just fine, so it’s not a problem with the device. On my friend’s brand new Moto X nothing displays at all, so it’s not a matter of the tablet being below required specifications.

I’ve spoken to the OpenFL community and development team to no avail. A new beta version of the framework came out and had the same problem. Worst of all, I tried to roll back to an earlier version that had worked before and I couldn’t even compile. The OpenFL ecosystem is in a constant state of flux, with new build toolchains and dependencies popping up seemingly every time it updates, and the older (working) versions weren’t compatible with the new tools.

At this point it was time to start considering my options.

  • I could hunker down, wait for another OpenFL release, and hope that it would solve my problems.
  • Or I could bite the bullet and port the whole game back to C# (the language I wrote the original gamejam version in) and use Unity.

I’m choosing Unity. I’ll be using the Futile framework, partially because the API is Flash-inspired and will be easier to translate code between, but mainly because it’s a fully code-oriented workflow and only has support for 2D. When I first started working on the improved version of Iridescence Unity still didn’t have support for Linux and doing 2D work was a hassle. Not so any more. When I’m finished, this version will replace the current Windows/Mac/Linux Haxe-based one.

It’ll be a tough road but I’m ready to do what it takes. I leave you with the first step.

long road

Glide update: Structs don’t work that way

Glide has seen some modest adoption despite the fact that I’ve barely made any effort to get the word out. A handful of developers have contacted me thanking me for the project and asking for help, which I’m always glad to offer. One issue in particular has come up a few times recently, and it relates to the way .NET handles structs.

Structs are passed and returned by value, not reference. This means that when you assign an instance to a variable, that new variable has no relationship to the original object; any properties set on it will only apply to that variable. This is a problem in Glide, since I have to store a reference to the tween’s target object in order to apply the transformations. Worst of all, while normally this issue would be caught at compile time, it’s impossible to detect when you’re using reflection to set values, and the resulting behavior was that the operation would appear to silently fail.

Today I made some changes that should help users realize when they’re attempting to tween an incompatible type. Passing an instance of a struct to the tweener will result in a compile-time error, and if you sneakily box your variable into an Object it will throw an exception at runtime. This still doesn’t solve the problem of how to tween these types of properties, but I’ve got you covered on that front as well.

Glide already has support for extension classes that allow you to add specialized behavior for tweening your own types, but this feature wasn’t really documented anywhere. Now it is! I’ve added a wiki to the Glide Bitbucket repository with an example showing how to tween an XNA Vector2. It should be pretty simple to modify for your own needs…maybe a StringTyper extension that causes letters to show up over time like a typewriter, or a GlitchString that fills the whole string with garbage and slowly fills in the correct letters.

Rotatable Graphiclists

Here’s a quick gif demonstrating a new feature I’m working on in #Punk, my C# port of Flashpunk.

rotate

Pictured: Two images (rectangle and circle), a Nineslice, and a Tilemap.

Since C# + SFML is so much more powerful than Flash, we can do some pretty cool things that weren’t previously possible. Rotatable Graphiclists are something I’ve wanted for a while, and they’re pretty close to being ready!

Glide update: From()

I made a small addition to Glide, my tweening library for C#. You can now specify starting positions for the variables you’re tweening, useful for when you need to change a variable instantly and then tween back to the default value. I use this when I’m making things flash for alerts or other important things for the player to notice.

Obviously you could just set the values manually before telling them to tween, but this is a nice shortcut if you’re setting a lot of them at once.

You can download Glide here.

7dfps

7dfps 2013 : Writing a raycaster

When the first 7 day FPS challenge was launched in 2012, I remember wishing I could participate but knowing full well that I didn’t have the skill to make anything of it. I’d never done any serious 3d programming and had no experience with the asset pipeline required for a 3d project. I decided I’d learn how to use a simple 3D engine in my free time over the following year and participate next time.

Well, it’s one year later, 7DFPS is back in business, and I still have no experience in any of the above areas. I had already resigned myself to missing out again, but I happened to stumble across this article on writing a “pseudo-3d” engine such as is used in Id Software’s early games, including Doom. I decided to give it a shot. Here’s my progress for the first two days.

1

The first step is figuring out where the walls are. The above screenshot shows that not happening.

 

2

A bit of an improvement.

 

yays

Wall segments are being drawn, but in completely the wrong places.

 

omgyays

Segments are now positioned correctly. I changed the texture to a standard pink/black checkerboard for debugging, but it isn’t showing up right. In addition, the perspective is “fisheyed”, causing curved lines at the periphery of the field of view.

 

nofish

Better.

 

perfect

The elusive “perfectly textured wall” in its native environment.

 

sexyhotness

Some awesome modern art I created while trying to fix textures.

 

textures

The final result as of this writing. At this point the engine is basically done and I can get to work on some gameplay.

slime

Game design by necessity

I started work on a game called Gunbuilding about a week ago with the purpose of stress-testing #Punk, a C# port of Flashpunk that I’ve been developing. Nothing puts a framework through its paces like using it for a game jam, and if nothing else I ended up fixing a lot of bugs that would have inevitably bitten me later on. On the downside, though, my idea for the game changed drastically to fit inside my schedule, and I’m not thrilled with the way it came out.

If you want to play it, go here.

The first thing to go was the mechanic that gave the game its name. I created a system that assembled bullets by passing data through a set of components that could be swapped out at any time. In theory, this could have allowed for a crazy number of combinations, resulting in bullets that homed in on enemies and spawned others to ricochet around after impact. The system technically works as it is, but I didn’t have time to create more than one component for each category. I’d like to explore this type of system again in the future, though; it seemed like it had potential to be a lot of fun.

The next feature to be cut was the enemy AI. I’m pretty happy with the way my little guys hop around (the quadratic curve movement system they use was one of the first holdups I encountered), but they don’t do anything to avoid each other and always ended up clumping together into a group as they moved towards the player. As a solution (though at the time it was a joke) I made them explode when they touched each other, and then made that explosion chain to other nearby enemies. The chaining was super simple and easy to do thanks to #Punk’s extensive message broadcasting capabilities, and it turned out to be a lot more fun than the approach I had been using, so in one sense I’m glad I ran low on time to implement the rest of the game systems.

The last thing I didn’t have time for was to put any effort into graphics. Everything in the game is made up of colored squares, with the  exception of a grass tile I used for the background and a tiny image for the particle effects. I generally try to prototype with as few art assets as possible to avoid getting stuck perfecting them before any gameplay is in place. In one sense that worked out this time — I can’t imagine what else I would have had to cut had I spent all kinds of time on art early on — but I feel like shipping the game in such an incomplete state is a real shame.

Overall I’m disappointed with the way the game turned out, but this was never about the game. I’m pleased with the number of bugs I was able to fix in the framework, and that was the whole point anyway, so I’d call this experiment a success.