Tag Archives: Sprite Maker

Sprite Thoughts and Life

I was playing an early alpha of a friend’s strategy game and noticed that the animation of the character’s feet wasn’t in sync with the ground below it. This got me thinking that I could add a feature into my sprite maker where you could preview what your character would look like at various animation speeds in relation to ground speeds so that you could more easily sync the two up. I still need to add the registration points to the editor too, my lasers are going to need those really soon.

Somewhere down the line, I would like little rotating turrets on my spaceships and battle-stars. With my current isometric point of view and 2D sprites, this could prove challenging. Just thinking out loud: I would need to use an orthographic projection of my models (but maybe not), then draw the sprites in a few parts to handle special cases like where a turret is partially obstructed by a tall part of the structure it’s attached to. If I handle cases where a turret can be obstructed by the structure it’s attached to, I’d want to handle that (somehow) in the sprite maker because the purpose of the sprite maker is to abstract these sorts of details from the programmer and let the artist handle all of this artsy stuff.

Not that I used to get a lot of search referrals, but I have not had a single search referral since I upgraded my website. I’m pretty sure I broke something. That ought to teach me to upgrade my website. Anyone had this problem, or know how to fix it? All of the old URLs no longer work, and you’ll get a friendly 404 if you try. I’m certain that has something to do with it.

Life has been keeping me rather busy recently, so I haven’t had time to develop AO any further :(. I’m hoping to get a few hours in this week though, see if I can make a quick video of the power pulsing and finish up with the network cleanup. The networking has a few complexities that need some thought, like: Will updating a ship’s location, velocity, and target, only when the target changes be sufficient enough to make a smooth client-side simulation? or will more updates be required? My instinct tells me that this should work just fine, as long as the game knows when this target change occurred and how to bring the ship into the present (keeping in mind that all network packets come from the past). There are some other organizational issues around how to send the initial state of the game to the client and how scenarios tie in to all of this, but I’ll elaborate on that in an other post.

3D to 2D En Route

I spent some time today working on my sprite maker. The major event, is that I got some 3D to 2D action going. There are currently limited options for this conversion, but now that I have a start on it, these should come quickly. Currently, you can load a DirectX model file (*.x), specify a frame width and height, and how many rotation snapshots you want to take. It presently uses a fixed viewing angle, and won’t display animations, but those are on my plate. If you’re a programmer, you can check out the code on Google Code: http://code.google.com/p/sprite-maker/

Back to AO and my Sprite Maker

With a heavy heart, I left the Android project late last week. I have been extremely stressed out since the project started. The stress largely came from my experiences with other hobby projects, and comparing those failures to this budding project. I felt like I was nay-saying absolutely everything, and I was; Trying everything I could to get a smaller project, yet only rocking the boat more.

So… after a more than slightly bitter break-up, I am returning my attention to Asteroid Outpost (AO) and my Sprite Maker. I am trying to find small things to work on in AO while I get my teeth into my Sprite Maker.

Over the past week or so, I have decided to tackle the lag issue when slower computers host a multiplayer game. Kind of a funny cause: A long while back, for testing purposes, I disabled XNA’s frame rate limiter so that I could see how many frames per second my modern computer was pumping out. Turns out it’s usually between 500 and 700. In AO, the miners mine at a constant rate over time, so each update, they will generate 2 events and 2 packets: one to decrease the minerals of the asteroid, and one to increase the player’s minerals. After putting two and two together, I figured that XNA has probably tied the Draw and Update loops into one, causing 500 to 700 draws AND 500 to 700 updates per second, in turn causing 1000-1400 packets per second to be created for a single miner! That could cause some lag eh?

The obvious, simple solution is to turn the frame limiter back on, but that would only be a bandaid solution. The real solution is to change the miner’s logic from a constant rate to a burst rate, something like: take and give minerals only 4 times a second. This would reduce the number of packets to 8 packets per second for a single miner, regardless of the frame rate.

An other optimization I will be looking at, is to remove older versions of the same packet in the same outgoing batch. What I mean by that is if miner A is updated first and takes 10 minerals from the asteroid, and gives the player 10 minerals, then miner B is updated and takes 10 minerals from the same asteroid and gives the same player those minerals, there will be a lot of duplicate packets. I intentionally collect all of the outgoing packets for a single frame, then send them all at once at the end of the frame. Here is an example of what packets could be generated for the above example:

Packet 1: Asteroid 1 current minerals is now 250
Packet 2: Player 1 current minerals is now 110
Packet 3: Asteroid 1 current minerals is now 240
Packet 4: Player 1 current minerals is now 120

As you can see… if these packets are executed in order, packets 1 & 2 will be rendered completely useless, more recent information is available for the same entities in packets 3 & 4. I plan to resolve this with a hash-table (or dictionary) where the hash would represent the packet type and destination in such a way that previous, non-useful packets of the same type could be discovered and overwritten with new information before getting sent to the client(s), reducing the packet count yet again.

Android Project

It’s been a while since my last post. I’ve been keeping busy. I went on a hike with some friends a couple weekends back, and one of them brought up that we should make a game for the Android phones. We’re still in the early planning stages, but we’re trying to make a multiplayer artillery game. We’ll see how it goes. So far, we have five or six people on board, but only one of them is an artist. I hope it doesn’t limit us.

I have been slowly working on my Sprite Maker, but not a lot of progress so far. I’m still trying to think of easier ways to make multi-part sprite or how people in the industry do “registration points”. Complicated.

I’m starting to play around with Box2D for the first time ever. I’m mainly doing research into whether it would work on an Android properly, and whether it will work or is necessary for an artillery game. My gut feeling says… “no” if we only want gravity and wind, but “yes” if we want anything more. Explosions to push people, or action/reaction forces, or map doodads that react to physical objects, or anything of the sort really.

I notice a number of people visiting the site for minecraft intersections, so I’ll make a quick page to help out.

Sprite Maker Start

Last night, I managed to get a start on the new version of my Sprite Maker. I had an old version that is giving me a great head-start, but I’m starting with some large architectural changes. Like… In the old one, I was storing all of the frames in a List of Lists of Lists of Lists of Frames, which makes sense when it’s worded: a List of Sets which contains a List of Animations which contains a List of Orientations which contains a List of Frames. But using this list in an editor when a user can add or remove any of these, and due to the symmetric structuring of the lists (each set contains the same animations etc), it makes it hard to maintain. I may end up using that method in the end, but I’m experimenting with three dictionaries of frames instead: one for sets, one for animations, and the other for orientations. The idea would be that each dictionary would contain all of the frames, but indexed differently. The dictionaries will also be partially filled, filling in only as frames came into existence. This way, when a user deletes a set, I look up all the frames for that set, and delete those from the other two dictionaries instead of trying to do a whole re-balance of a List of Lists of Lists of Lists.

— Edit —

After some further investigation and thought, I have stuck with maintaining a symmetric List of Lists of Lists of Lists of Frames. For one: it more accurately models the sprite. And for two: removing sections of the symmetric list isn’t quite as difficult as I had previously thought (or as difficult as it sounds).

Sprite Maker

I have been designing a sprite maker for my 2D games. The idea is that my sprite maker would produce a sprite map and an XML file describing the sprite map. I would also produce a Sprite class & DLL in C# that would be able to read the XML file and handle all sprite animations for you.

For the purpose of this project, I have defined the following:

  • A Sprite is the collection of Sequences that represent a Game Element
  • A Game Element is a visual element in the game-world
  • A Sequence is a collection of ordered Frames
  • A Frame is a rectangular section of an image

That is to say that menu items, HUDs, buttons, text, loading screens, all of that is not a Sprite because they do not exist in the game-world.

Also, each Sequence has a unique combination of Set, Animation, and Orientation where:

  • A Set represents the set of the sprite to use. This can be used for a second, complete set of Sequences for the sprite. Examples are: (full health, half health, and almost dead) or (sword, vs spear).
  • An Animation represents an action that the sprite is doing. Examples are: Idle, Walking, and Jumping
  • A Orientation represents the direction the sprite is facing. Examples are: (left and right) or (0, 45, 90, 135, 180, 225, 270, and 315 degrees)

Any of the above can be left as “Default” if they aren’t useful for your application. Every frame can be accessed by using a 4-dimensional array like so:

frame[set][animation][orientation][frame#]

Where the frame# indicates the progress through the Sequence. When the Animation changes, the frame counter restarts at 0. When the Set or Orientation changes, the Animation and frame counters do not change, the current animation just continues in the new Set or Orientation. Each Animation indicates which Animation should follow, once completed. For a looping animation, the animation will refer to itself. For a ping-pong animation, there will be a second animation that uses the same set of frames, only in reverse. And for animations continuing on to greater things, they point elsewhere. Whenever an animation completes, either a flag will be set to indicate this, or an event will get fired to allow the game to take any required actions (like start moving after standing up).

In my editor, I am building a few import methods to import from individual files, existing sprite sheets, and even 3D models. I have already built something that will load 2D individual files from Reiner’s Tilesets, but am currently focusing on building the 3D->2D importer. I should have this project on SourceForge before too long.