.webm updates might be infrequent right now, my graphics card is in the process of dying.

Went from 2x 1920x1280 monitors via HDMI to 1x 1280x720 DVI via integrated mobo display. This also completely fucked up my physical desktop arrangement because I had HDMI audio set up and some other things I had to mess around with.

Moving accounts… soon!

So, Tumblr doesn’t really let you change emails for your blog easily, or merge/combine accounts, so I had to create an entirely fresh identity, since moving and restructuring things is a hassle.

I will continue to use this blog in the meantime, and repost major milestone posts on the new blogs until I have released a playable demo, at which point I will be fully onto the new blogs.

Busy last few days!

  • In order to be as fluid and deterministic as possible, I had to abandon my Timer class and just use raw timestamps on my Actor objects, since they previously relied on float values, and I couldn’t determine the EXACT half way tick
  • Objects are considered part of the target tile as soon as they’re halfway through movement - thus, other objects can start to replace the other they were on while they’re still moving. The last half of the movement is just a timer to delay it and look nice
  • Lots of code cleanup
  • Moved in a few (mostly) final sprites, such as the walls and conveyors
  • Changed my map format around a bit so it can read objects and players, but everything is hard coded, but the map file itself is just a text file. As a consequence of this, floors can be checked to see what it is (eg, open, wall, conveyor)
  • Tiles have a type and a flag - actors mostly rely on flags to move around

Too much little stuff to go over, but it’s starting to shape up. Hoping for a playable demo (pre-alpha, very buggy) by November 11th so I can drop it off in one of the /agdg/ threads.

How to write better error-handling

Let’s say you have an array, TileBehaviorFlags[] Tiles. It could have public getters or setters, and maybe you don’t want the contents accessed directly, so you decide to make a helper method that retrieves a value from it:

image

This works, but what happens if you hand it an invalid value? It will throw an exception. So you decide to add basic bounds checks in the form of another method:

image

This is better because it checks for null/out of bounds, and returns a proper value. However, it still has to check by calling a method, which can be slow if you need to cal this sort of method every frame on thousands of objects. We can do better.

image

Here, I’ve attached a preprocessor directive (a pragma) to the method. Now, if I compile the program with a custom CHECK_BOUNDS value in the compiler option, it will include the bounds checking. In the debug build, for example, I might keep it enabled so that I can find bugs and remove them. In the release build, I can simply remove this flag for performance, and in theory, it won’t get bogged down with performance checks.

Rather than relying on the underlying language to throw the exception, I raise it myself so I have more control over when and how it happens. Instead of returning TileBehaviorFlags.NONE, I use default(TileBehaviorFlags), which is usually zero - but this can vary, and wording it in this manner ensures that it behaves consistently if I happen to change the enum’s values down the road.

Finally, my debug class looks like:

image

I wanted it to be a globally accessible class. It is almost always best practice to create a singleton instance and place the instance in a static container. Here I’ve also given it a private constructor and made the static field read-only, so that it is impossible to message around with. The client code may change the flags around if they need to, of course.

I can call Debug.Log(), which is just a wrapper for Console.WriteLine(), so it’s quicker to type out. Depending on my compiler options and what flags I set here, I can either:

  • Call the method and return the correct value
  • Call the method and return a default value
  • Call the method and raise an exception

Small optimization:

While it should be impossible for two actors to enter the same space, they are currently able to be spawned on top of each other for stress testing. What I did was spawn 250 at a time at (1,1) but created a HashSet<position> for drawing, that only draws the first object at that position, logs it, and ignore further ones

Falling objects behave according to the following strict rules:

  • If the tile below is empty, move down.
  • If the tile below is not empty, but is sloped left, check the tiles to the left and lower left. If those are empty, move left.
  • If the object cannot roll left, but the tile is sloped right, try to roll right.

This was easy enough to implement, but the hardest rule was:

  • Objects are predictably updated according to their position, starting in the lower right, moving left, and repeating row by row.

This was difficult for a few reasons. For example, a month ago, I didn’t know that SortedDictionary and SortedList existed, and wasn’t sure how to sort my objects. Another difficulty was that most coordinate systems in XNA use “unsortable” tuples, such as Point(x,y) or Vector2(x,y) - you can’t necessarily say one is “greater” than another.

The solution was to use a packed value. My game will realistically use 128x128 maps at the absolute largest, so this basically means a coordinate pair here would be two bytes in size. I opted to use ushort/UInt16 to represent a particular coordinate, but this also had it’s own challenges, mainly how to interpret them.

You can take a random value like 18,681 and do [y = n/256] and [x = n%256], but the world’s Tile[] was only say, 20x40 in size, it was very easy to fall out of bounds. This is why I was flipflopping so much on my previous post - should the conversion go on GameState, because it has all the state changes? Should I make extension methods for ushort objects, so I can get adjacent tiles that way? Stuff still needs to reference the World’s width so it can scale properly.

So ultimately, I put the logic in the GameState class within one or two small, clean functions, and have a few functions hook up to it. The main one is below, but you can call it with regular (XY) coordinates and it will do the magic under the hood:

image

The issue was making it all work elegantly. Calling stuff needed to be short and direct. It had to work in a very deterministic way (for replaying level solutions, much later). It couldn’t do a ton of work because it might get called a few times per tick per object. The Tile array was just an array and can’t store 256x256 values just for the hell of it, etc.

Anyways, this is a major progress milestone, I think, because now I mostly have the foundation laid and I can start doing cooler things.

(And yes, as a consequence, this was mostly to make the red gem roll left, instead of right, every time.)

Spent the last half of a week rewriting the same code back and forth between two or three spots, but I think I have it settled. Now, World and Actor basically just store state, while GameState contains them and has methods to manipulate them.

image