I just got back from my vacation, and I have so many ideas for Asteroid Outpost. Scenarios, music, and voice acting have been running through my head. I think I have some pretty fun ideas for scenarios that I can’t wait to implement.
Here are some all-new screenshots of Asteroid Outpost’s new graphics. Sweet eh?
A beautiful revamp of all of the entity graphics thanks to my sprite maker
A spaceship!
A lot has happened in the past week or two. For starters, I corrected sprite angles in my game, so now when the spaceship is shooting at you, it’s facing you. It’s more complex than it sounds, I had to stretch the X axis to complete the Isometric look. In the end, it looks amazing. I converted all of the circles to ellipses to complete the look.
I have also been fixing up my sprite maker, and actually started to use it to produce proper sprites for AO. On that same note, I have replaced my old sprite animation library with my new one. This library is developed as part of the sprite maker and can be found on google code. Since I had all the pieces working, I went through and replaced all of the graphics in the game with new ones! Right now, the sprites are a little dark, so I have to do better light handling in my sprite maker. I should have that up and running before too long.
Oh, and did I mention you can zoom in and out now?
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/
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.
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.
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).
I just released a new version of Asteroid Outpost, revision 117. The old version on SourceForge desperately needed an upgrade. The main additions in the new version over the old one are:
The game still isn’t playable, there’s no way to win or loose, there are bugs in places, very few units, and so on. I wanted to get the multiplayer done before I started working on new units in case I needed to change everything. It turns out, I don’t need to change everything, but I do need a system for getting new and improved graphics in the game without taking days to do each sprite. I have started a roadmap in Trac that will help me to stay on trac (get it?) and to better document the future steps I need to take instead of just documenting the bugs. Long story short, I will be working on my Sprite Maker for the time being.
Edit: I have abandoned Trac in favor of Trello for its simplicity and rapid use.
I am in the final stretch, there are two bugs that I need to fix, then I will finally be releasing a new binary for Asteroid Outpost. Future binary (.exe) releases should occur more frequently. The development time for this update was largely due to changes in the core functionality that broke the end-user experience and took a long time to develop. Most of these kinds of changes are out of the way (I hope), and users can now use the interface as intended without core dumps. The changes I see in the immediate future will be more contained, and will allow for smaller and more frequent updates
A good friend and I got arguing about how easy or hard it was to design screens by hand (manual location & size). At first, I was saying that I didn’t mind designing by hand, but as my screens are getting more and more complicated, or I start to want more specific things out of my screens, it’s becoming more time consuming. The solution that we were toying with was to use the Windows Form Designer (available in Visual Studio) to design the screens, then copy the code into the game. As long as class names and properties look similar, it would be very little work to copy/paste. Now that I understand what he was trying to communicate, it’s actually quite nice. I did a proof of concept over the weekend, and it works great! I will be converting all of my menu screens over shortly. I make everything inside a windows form or panel whose size is some standard size that I will use throughout Asteroid Outpost (AO). Then in AO, I make a centred panel with the same dimensions, copy the code from the windows designer, paste it in AO and make a few small modifications (Point -> Vector2, etc), delete some unused portions, and then run it!