A Different Type of Development

Decided to switch up my development type a little bit.  I picked up an Arduino today from Radio Shack and got back into some robotics stuff.  I had previously used the Parallax Propeller and had a lot of fun, but recently I had read a lot about the Arduino and it looked really interesting.  Radio Shack had a nice setup for ~$80 which I picked up.

So far I really like it.  I was able to get a little robot that I had frankensteined before up and running in it in a few hours.  You can see it there in the background.  I'm using an H-Bridge (SN75441) to control the rear motor and turning motor.  I also have a Parallax Servo up front that moves an Ultrasonic Distance Sensor around to find the closest object.  The little dude will just drive around and find the closest thing.  Then drive up to it and stay there.

It just wants to hug things :]

This isn't very AstroMiner related, but it is an area I'm interested in.  I have a lot of other projects that I don't post much about.  I also have a project for my website, http://www.pwned.com, that I need to start and finish soon.

On the AstroMiner front, I'm fairly certain that I fixed the bug where blocks were changing their drawing locations.  For some reason I was pulling in a new block object every single time I added a block to the world.  Once I fixed that and only pulled a new block object if the current block is null, the bug seemed to go away.  I'll continue to test it to confirm.  Next on the list is player inventory and a faster way to save/load worlds.

I probably won't do as much dev work starting next week due to the holidays.  I'll be back full swing come the new year though.

Development Screenshot

Just thought I'd show you what 95% of my dev time looks look.

I'm currently trying to fix a bug where some blocks are getting their positions crossed and drawing themselves in the wrong locations.  This was introduced during the multiplayer addition.  I'm not sure if it's on the client or the server where the block is being corrupted.

You can see the server running in the background there as well.  It's not as pretty to look at.

Tonight's Multiplayer Progress

Block deletion/addition has been fixed and is now working.  I've removed almost all of the client-side detection for this.  The client tells the server that it is eating and that's it.  The server tracks how much health the block has and decides when the block is considered 'destroyed'.  When it is, the server sends the client a message saying "destroy this block" and the client does it.  The server now also tells the client when to add floating items (the little boxes you see when you eat a block).  The client's job is to tell the server that the player's bounding box has intersected with the floater and that the player wants to take it.

When it comes to multiple players, it's going to come down to whose call makes it to the server first.

So anyway, lots of rambling there.  That's what I worked on all night.  Next on the list is player inventory.  That should all be managed by the server as well.  Once that's done, I'm going to start saving the player's position on the map so when they exit, they come back to the right spot.  Then I'm going to start saving the map itself.  Fun stuff.

I miss the whole creative side of this game.  I miss adding a structure and functionality to it and seeing how it interacts.  I miss toying with the AI, or even just coming up with new AI ideas.  I know this part has to be done and when it gets done it'll be well worth it, but I sure do miss all the other parts.

Multiplayer Updates and Protobuf Usage

Today I started the "no-going-back" multiplayer conversion for AstroMiner.  While I do have many backups and I could theoretically go back to day one, I am considering this the point of no return.

As I mentioned before, a lot of code has to be changed to allow multiplayer support.  I could hack it in and make it so it's not nearly as much effort, but that runs the risk of future hassles whenever I add new features.  There would be redundant code running on both client and server that wouldn't need to be run.  How do I know which results to trust?  Server or client?  What if my client disagrees with someone else's?  These are all questions that I asked myself when I decided to make this conversion.  If you want more detail, read my blog post from a few days ago that describes my model for multiplayer.

So today I started removing code from the client.  When the game launches, the server is also launched silently in the background.  The client no longer saves or loads maps.  That's all handled by the server now.  When you start a new map, you actually send a command to the server telling it "load this map" or "start a new map with this seed".  The server then does its business and sends another packet back telling you it's done.  At that point, the client says "give me all the updates around my position".  This was the tricky part.

Gathering the updates wasn't hard.  Building a container class for them to be transported wasn't hard.  What was hard is figuring out a solid way to transport them without taking so much space.  I toyed around with several serializers.  XMLSerializer was slow and took up a lot of space.  BinaryFormatter was fast, but it can't handle Vector2's.  I tried some custom libraries, such as the Sharp Serializer.  This is an awesome little library and would've worked, except it was giving me issues with Vector2's as well.  Vector2 is an XNA format and I can't modify it, so I needed something that would let me define my own custom serialization types.  Google's Protobuf came to the rescue.  More specifically, Marc Gravell's Mono Implementation.  This not only lets me define custom types, it is extremely fast when it serializes and extremely compact.  For the sake of internet searches, I'm going to post my code to serialize an XNA Vector2:

First, you want to declare a RuntimeTypeModel:

     private static RuntimeTypeModel serialize;  

Then in your initializer, you need to instantiate this model with all of your custom classes.  Mine looks like this:

     public netManager()
     {  
       serialize = RuntimeTypeModel.Create();  
       serialize.Add(typeof(Vector2), false).Add("X", "Y");  
       serialize.Add(typeof(chunkUpdate), true);  
       serialize.Add(typeof(change), true);  
       serialize.Add(typeof(block), true);  
       serialize.Add(typeof(Rectangle), true);  

By the way, I did all the coloring by hand.  You're welcome.

Ok so to explain that, I'm creating a model so Protobuf knows how to serialize my object.  For Vector2's, I'm telling it I only need the .X and .Y values.  For all my custom classes (chunkUpdate, change, block), I'm telling it to figure it out on its own.  It's also reading XNA's Rectangle on its own.  I'm willing to bet it can read Vector2 on its own, but I haven't tested it.

Anyway, once that's all fancy and done, I simple serialize like so:

 serialize.Serialize(fullPacketStream, cu);  

fullPacketStream is a MemoryStream and cu is my chunkUpdate object that I'm serializing.  I turn then fullPacketStream into a byte array and send it off on its journey to the client.  When the packet is received, I deserialize like so:

 serialize.Deserialize(chunkUpdateMemoryStream, chunkUpdateInput, typeof(chunkUpdate));  

I now have an intact chunkUpdate class that contains all of the updates for a given chunk of data.

I spent most of the evening learning about protobuf and getting this to work.  I think that by tomorrow night, I should be at the point where I can create a new map or load an existing one.  The map will be able to save itself to desk when the server is done with it and the player will be able to travel all throughout the asteroid field and have data being streamed to them on demand. (I just jumped from first person to third)

Anyway, no screenshots to show because it's all just code :[  I will hopefully have something tomorrow though when I get the full streaming set up.

Until then ~

Successful Multiplayer Test

Just wanted to report that I've had a successful early multiplayer test.  I logged into the server with my local machine.  I then used tethering through my phone to have my other computer logged into my server through my remote IP.  Lastly, a friend of mine logged in from his computer.

Lag was very minimal (I actually didn't notice any, but I'm local).  We flew around.  He deleted 2 blocks and I saw it on my screen.  Overall, a successful test :]

One thing I haven't addressed is world syncing.  He came into a world that was different than mine.  When the player comes onto a server, they'll need to be updated with all the changes/structures before they can start playing.

I'm currently on the 2nd milestone.  I've decided that generating the world is going to be left on the client side.  I think it would be too much work for the server to constantly generate asteroid locations around every single player connected.  Instead, I have several hashing techniques in mind so I can make sure that all the player worlds are similar.

Adding/deleting blocks has been completed.  I have the packet builder complete and I've been utilizing it.  I've decided that the floatingItems can stay on the client side.

Next thing I have on the list is to sync up the worlds between players.  After that, syncing up player inventory and passing in more player information.  You currently can see a player standing on a block and the block being slowly eaten, but you can't tell the player is drilling.  You can't see the thrust that the player is using.  All that needs to be sent to the server.

After all that, I'm going to actually add bullets before the next milestone.  That will leave adding structures as the only player interaction left.

Anyway, I'm progressing well :]  This is actually more fun than I thought it would be, heh.

Until next time ~

Multiplayer Milestones and A Summary of the Past Year

I started coding today by jumping straight into multiplayer.  I added support for structures, multiple players, AI and the environment when I realized I'm doing this all wrong.  I need to stop and rebuild from the ground up.

So I've come up with a plan.

I have my base server.  It currently compiles fine, but most of the sections where I'm checking for player collision are commented out because they currently only support 1 player.  I need to add multiple player support for those, but that's for later.  For now, I have my base server with all of the AstroMiner objects and classes built in and compiling.

Next on the list is the world.  Generating asteroids, for starters.  This will be done on the fly, like it currently is, and the player should be able to fly around in an infinite world, like they can currently do.  This also means I will be adding support for multiplayer player movement, light support (which I'm going to calculate client side) and some other things.

Once that milestone is passed, I will move onto adding/deleting blocks.  This will force me to build out a changesManager that can dynamically update from any source and report what changes it has so I can build an efficient packet to send.  We obviously don't want to send all the changes all the time.  We only want to send updates.  These kinds of updates are important, so they will require some validation on the client end telling the server that they received the update.  This will also require me to sync up the player's inventory (and now that I think about it, the floating items manager (the little blocks that drop when you eat a block) will have to be working here).

At that point, I should be able to have multiple players log into the same server, delete and change blocks and have them see eachother's updates.  That will be a major milestone because I will have collision detection for multiple players done, an efficient packet packing algorithm and a streaming server-side world that can save itself to the file system.

Next on the list is environment.  This will be game night/day sequence, gravity for any objects that register for it and water.  This one will be easy because it's pretty much already done, but nonetheless it's on the list to be reviewed and updated.

After that, structures.  I believe this will be one of the hardest to implement and that's why I've saved it for the very end.  Lots of objects check to see if the player is near them to activate.  I can do a foreach() on every logged-in player and check, but that seems horribly inefficient.  In order for this milestone to be complete, the player should be able craft an object (this will be validated client and server-side), place and remove it from the world.  The structures should all run their normal update() routines.

The next, and definitely hardest out of the bunch, will be the AI manager.  90% of the AI manager will have no problems and will be a seamless transition.  10% will be very complicated.  That last 10% is enemy movement and player collision detection.  There could be hundreds of enemies in the world and all of them need to check for player collision.  They also need to detect if they're near a player and if they are, go towards that player.  A foreach loop would also work here, but again - very inefficient.

So that's my multiplayer roadmap.  My goal is to have this done by the end of the month.  That's my goal because I'm going home to see my brother before he ships off to the Navy and I'd like to play multiplayer with him there before he goes.  I have a feeling that once I get started and figure out the fundamentals of how this server should be laid out, the rest is going to fly by quickly.

I still don't have a 100% solid idea of how I want the client to interpret the data.  I have an idea of how I want to efficiently build packets and how each player will have their own custom packet.  Sending it is already done.  How the client will interpret that packet and use it to update the world, though, is still a little foggy.

So anyway, that's my plan.  I feel like this is a whole new chapter in my game development saga.

- The First Chapter was just getting started.  Learning about Unity, 3d and the different engines/languages I can use.

- The Second Chapter was my Minecraft clone.  I learned about algorithms, heavy 3d triangle strips and efficient ways of rendering millions of cubes, player input and writing very efficient code.  Object pools and utilizing floats efficiently.  Using the Garbage Collector as little as possible.

- The Third Chapter was the beginnings of AstroMiner.  Creating a seamless 2d world.  Adding/deleting blocks.  Spritesheets.

- Fourth Chapter would be AI.  Implementing an effective, "thinking" enemy that can react to the player.  Making that enemy spawn in ways that make sense.

- Fifth Chapter would be crafting and structures.  Creating graphics that make sense.  Creating structures that take time to do their job.  Creating structures that pay attention to their surroundings and react accordingly.  Turrets that shoot enemy, doors that open and close and tractor beams that raise and lower the player.

- The most recent chapter, the Sixth, was all about fluids.  Creating an efficient fluid engine that let me have vast amounts of liquids and let them all update and react with the world around them without taking up tons of resources.

And now we're on the Seventh Chapter, multiplayer.  I've barely started this chapter and I've already learned a lot.  This might be one of the most challenging ones yet, mainly because I have so much of the fundamentals already done and there's so much that now needs to be changed.  I feel like I will definitely learn a lot though.  The nice thing is, at the end of the day, that's the point of this entire adventure.  To Learn.

So until next time my friends. ~

Learning 3d

First AstroMiner concept

First AstroMiner Build

Latest Screenshot

Lesson Learned

For my next game, the very first thing I will do will be multiplayer support.

The concept is simple.  When you launch in single player, the game is going to launch a local server and your client will connect to it.  You will be the only player on that server until you reach the multiplayer stage.  Then it will open up for others.

When you want to connect to another server, your client will simply point itself towards that server.

It sounds very simple and it would be, if I had worked like that from the beginning.  At this point of the game, I have so much code working with eachother that separating it is giving me a lot of issues.

I'll get it done - no doubt.  I just wish I would've thought of this from the beginning :]

MultiPlayer

That's a screenshot of the multiplayer server running.  It's using C#/Lidgren for networking.  Here's the first AstroMiner multiplayer screenshot:

There's a lot of work that needs to be done, but 2 players can log into the same server and watch eachother fly around.  This is just the tip of a massive iceberg though.

I need to make it so the worlds are always synced up.  The enemies need to be synced.  The time of day needs to be synced.  Structures.  Water.  Pretty much every single thing.  What I'm thinking of doing is having the game always launch with a local server that runs everything.  Even when you're in single player, you'll just be connecting to your own server and pulling information from it.  That way when it comes time for you to connect to another server, I just have to point the client somewhere else.

Anyway, Lidgren was a breeze to work with.  I had some minor issues at first but it was due to my own coding.  I'd definitely recommend it if you're thinking of adding multiplayer support to your own game.

I'm going to focus on that all week and probably for the rest of the month.  It's a lot of work, but I want to get it done before I do terraforming since that's going to be one of the most complicated parts of the game.

v.1a.2 Released

Here's the changelog:

• All items and blocks now have their own floating graphic.
• Memory leak in floatingItemsManager has been fixed.
• Fixed bug where breaking glass could destroy tractor beam.
• Fluid engine has been completely redone from scratch.
• structuresManager draw() method has been optimized.
• The higher the player goes, the less thick the asteroids become.
• Pipes can now be placed inside of blocks.
• When a player is on the ground and they place an item, it gets placed 2 blocks below. This has been fixed so the item is placed directly below.

This version also has much better logging and exception handling.  I'm pretty sure the new fluid system is bug-free (though I probably just jinxed myself).  Download information can be found at http://forums.tigsource.com/index.php?topic=22847.0

Performance Updates

I'm been focusing a lot on performance this past week.  I started merging the world and structuresManager draw() methods and that seemed to go well, until I realized that this drew all of the structures behind the player.  I didn't want that, but I was able to use the same technique to further optimize the structuresManager drawing code to increase framerate.

For the sake of documentation, I'll admit that I made a very, very newbie mistake.  When I was drawing structures before, I was simply iterating through every single structure the player had built and drawing it.  Then at some point I put in a method that checks to make sure that the object is within view before drawing it.  This was stupid because I was still iterating through every single object that the player had built.

Then one day I was inside of the world draw() method.  I was toying around with adding another liquid when I realized that the structure was different.  In the world draw(), I had a nested loop that simply went from the top left of the viewport to the bottom right.  It only drew what was on the screen and ignored everything else.

Why the heck wasn't I doing this in structuresManager?  Stupid newbie mistake, that's why.  After changing that, it increased my frame rate by 30fps.  You won't notice this much of an increase in the beginning of your game, but in my Alpha base I have a lot of structures.  I have 9 forges, 3 chests, at least 20 light posts, 5 fuel posts, at least 20 turrets, 5 laser doors and the real structure hit:  2 sets of tractor beams.  You see, each tractor beam can be up to 500 blocks long.  That means that I was drawing every single tractor beam on every single frame.  This is clearly a waste.

After that was fixed, I noticed that my frame rate dropped drastically when I was around water.  This is because the game updates any water within range.

Now while in theory that makes sense, it sucks in execution.  The best example I have is a waterfall.  Say I release 100 units of water and let it fall down.  It will continue to fall and fall and fall until it gets out of range.  When it's out of range, it'll just float there in space until I get close enough to it for the game to update it.  Meanwhile, the game is constantly going through all the water around me and updating them, even if they have nothing to update to!  This is all waste, waste, waste, waste.

The new water method 'checks in'.  When the game generates water, it 'checks in' the water block.  Each water block has 10 ticks to do something (1 tick = 1 update() execution).  If the water block is ran 10 times and it hasn't made a single change, it's removed from the update() list.  Whenever I do something around the block that could effect it, I re-add it to the update() list and it again has 10 ticks to do something.

If I add water that flows into other water, I add both waters to the update() list.  What this gets me is a constantly changing list of water blocks to update.  The nice thing is I can be in an area with 500 blocks of water and not need to update a single one because they're just sitting there.  When the player drops in, they splash water so now 5 blocks need to be updated.  Eventually they fizzle out and now we're back to 0 updates.  If I remove a block underneath the water, a huge waterfall will form.  This waterfall can cause every single water block to update.  That's ok because at the most, it will be 500 blocks of water to update.  As soon as all that water is done flowing, I return back to my original 0 water updates.

It still has some minor glitches to work out, but overall testing has been very successful and the game now runs at an average of 170fps when I don't limit the framerate.  I'm very happy with these two performance updates.

On a more graphical note, all items now have their own drop graphic.  Beforehand, I was simply taking the original texture and re-scaling down to 16x16.  This worked temporarily but was ugly.

I'm going to spend the week focusing on the water update and removing all the little glitches.  For some reason, the water doesn't like to go near the laser door.  The current functionality is that when water is at the door, if it's open the water will go through.  If it's closed, it doesn't.  Well for some reason, when the water is falling straight down to the left side of the door (but not the right), it stops at the block above the door.  No idea why.

So that's my week.  No screenshots this time, but hopefully once I get these done I can start to put some serious code towards terraforming.  I'm torn between terraforming and netcode (multiplayer).  We'll see what I feel like doing when the time comes.

New Build Released - v.1a.1

I released a new build of AstroMiner tonight.  You can get the download details here:  http://forums.tigsource.com/index.php?topic=22847.0

Here is the official changelog for this version:

1. Radar
2. Better Mouse Controls
3. Beam lights up the area around it
4. More Base2
5. Performance updates - more specifically, the structures draw method and the world draw method have been combined, giving me an increase in 30fps. Player won't notice because the game is fixed at 60fps, but it gives me more leeway for when I want to add features in the future.
6. Chests now drop items if they are destroyed
7. W and A can now be used to control the menu.
8. Top left GUI can now be modded.
9. Ability to turn audio on/off has been added to the options screen.
10. Logging support has been added. A game.log file is created in the root folder.
11. Background track from Connor Humphreys - Artist of the Fortnight (1 of many!)

I'll be starting work on terraforming soon.  I can't wait to get into that code.  I have a lot of awesome ideas sketched out.  As long as I didn't introduce any new bugs in this build, I'll be working on that part of the game soon.

New Background Image

The sun has also been slightly moved.

I'm working on making the game brighter.  That was probably the most requested change from you guys.

First thing I did was adjust the minimum brightness in the day/night cycle.  The game used to make blocks completely black during the 'night' cycle.  Now you can still somewhat see the block types, but they're still darker than during the 'day' cycle.

Next thing I did was create a new background.  I looked at several space photographs as reference and came up with something that I think can pass as a good background.  I'm not sure if it's realistic, but it does give the game a nice feeling.

The next thing I want to add is some kind of graphic to show an asteroid belt going around the sun.

Anyway, I'm going to be out for a few days hanging with the wife.  I'll put a new build out early next week.

edit: Very subtle asteroid belt.

Load this up next to the other image to see it.  Very subtle :]

Radar

Just thought I'd share an update with the new Radar.  It's in the top left corner where the momentum-meter is.

Notice the little red dots?  Simple but effective.

I thought about the best way to approach this.  First thought was to have the game go through all of the enemy, get their distance from the player (their location - player's location) and those that are within a certain range would add themselves to a list.  That list is cleared() every single frame, so only enemies that are close would be in it.

After thinking that through, it definitely didn't seem like it was the most efficient way.  Then I remembered that the AI is always checking its distance from the player anyway.  After realizing that, it was a very simple if statement to see if the enemy is in range and it added itself to the list.

That seems simple enough and takes up a very small amount of extra CPU (just an if statement and List<> insert).  Sounds like a good solution to me.

Open Alpha is Awesome

I've gotten a lot of input for AstroMiner ever since opening up for public alpha.  I was very nervous about releasing the game at first, but after all the very constructive input I'm very happy I did it.  First off, some awesome fanart from kowbis at the TIGSource forums!

Such awesome work.

Next great news is that I got some audio for the game background.  It gives the game a mysterious, but spacey tone.  I can't wait to get it in the game.  Expect a new build with it within the next 2 weeks.

So as I said, I got some great input.  The most common request was to make the game brighter, so I've been looking at many different space photos and seeing all the different ways that space can be bright.  I have some  ideas that I'll implement before I release the next version.

• I was also asked to make the beam shine some light around it - that's done.
• Mouse controls have been revamped.
• The block algorithm generates more BASE2 now.

Before the next week, the following will be done:

• Blocks will look more distinctive.
• Radar in the top left corner.
• WASD will control the menu.
• UI will be moddable.
• Chests will drop items if they're destroyed.
• Better death animation.

For the future updates:

• The ability to pick where you save your maps.
• Tutorial
• Higher Terminal Velocity
• Ability to customize your controls

I've also switched off my forums for now.  I get so much spam :[  I decided to create a Wiki filled with lots of information, including more bad guy info:  http://www.astrominer.net/wiki/doku.php

So I have a lot of work ahead of me.  I'd expect a new build sometime next week with the new audio and some updated features!

Thanks to everyone for helping me test.  You've made all the work I've done for the last few months well worth it!

Roy

Public Release

Details at http://forums.tigsource.com/index.php?topic=22847

This is my first public release of the game.  I'm pretty nervous but I'm looking forward to all the feedback.  Changelog can be found here:  http://www.astrominer.net/f/viewtopic.php?f=2&t=19&p=69

This release adds pumps, pipes and elevators.  Big and fun update :]

Anyone for a space elevator?

Off

On

I'm still tweaking the crafting formula.  I'd like to use water somehow.

If the player is in the tractor beam, it will drag them up towards the top.  It drops down really far (about 100 blocks, but I'm thinking of raising it to 500).  The purpose is to give the player the ability to dig very deep down into the belt.  It's a lot more dense down there, so they can get more minerals than if they were to stay on top.

Eventual plan is to also let it be used to communicate.  By building a dispenser at the bottom of it and connecting it to a chest, the player will be able to transport blocks back up to their base without having to go back up.

I think I'm going to force the player to keep water near it.  Since it uses a lot of energy to create the beam, the equipment heats up.  The water can help it stop from overheating.

Not sure if I'm going to force them to attach a pipe or just submerge the elevator.  Oh, one thing I forgot - the elevator can be between 1 and 5 blocks wide.  The tractor beam will always take the center block though.

Here's a 1080p video I just created showing everything off:  http://www.youtube.com/watch?v=KNF9_FVXlgc

So that's it for now.  More updates later this week :]

Copper, Pipes and Pumps

The sprite for the pipes isn't the best, but it works for now :]  Turn the pump on and water flows from the left side to the right.  Pipes are created in the forge with the new Copper block.

Game Chapters

Spent a good portion of the weekend working on the game.

First off, the AI manager has been completely rewritten.  The way I had it before was not object oriented at all, so changing things around was a huge pain in the butt.  This new way is much, much simpler and lets me give more complex actions to the creatures (and it's also OO proper).  My first action with that was to give Matterholes the ability to jump.  'Jumping' didn't really seem like it'd fit their character much, so they actually kinda float up.  It's cute to see.

The player now has a consequence for dieing.  First off, they lose their whole inventory.  They have plenty of time to get it back (around 5 minutes) though.  They're then teleported back to where their beacon is.  If no beacon is set, the spawn point is used.

Those are the biggest additions to the game.  There are lots of minor ones and you can see them in the changelogs at http://www.astrominer.net/f/viewtopic.php?f=2&t=17.

I'm going to have the major versions of the game be released in chapters.

Chapter 1
This is the beginning of the game.  Chapter 1 is where you gather resources and build your base.  You learn how to control your ship, how to defend yourself from the enemy and how to survive in the asteroid belt.  What's the point of building your base and learning all this though?

Chapter 2
Chapter 2 is where you terraform the asteroid you've taken.  Your ship is nice and all, but you can't spend eternity inside of it.  Once you build a secure base that can successfully withstand assaults by Spies and explosions by Matterholes, you need to create a secure room in which to terraform.  The room has to be sealed so that no air can escape, but you still need to be able to get in.  Do you do this using laser doors?  Water?  Speaking of water, what's the point of gathering it all?  You'll also need to weigh your options.  It seems that ever since you've started terraforming, you've attracted a new type of enemy.  One that looks a little more mechanical and less biological.  You need to find ways of hiding what you've built so the new enemy can't find you.  You need to build some new defenses that can withstand this type of enemy.

So now the base is terraformed.  You have oxygen, plant life .. you can get out and walk around.  It almost feels like home.  Almost..  now what?

Chapter 3
Time to figure out how to leave this chunk of rocks.  You start building a device that lets you find other bases and possibly your home.  Once the device is built, you'll be able to travel to other worlds inhabited by other players.  You can exchange resources, building ideas and maybe even helpers that you've built along the way. You'll also have the option of going home here.  Maybe you like your new base and you don't want to go home.  The choice is yours to make.

That's the global picture of the game and all the chapters.  Chapter 1 is going to be the free version.  Gather resources, fight enemy and build a base.  Chapter 2 I haven't decided yet but Chapter 3 will definitely be pay (since that'll require me to run directory servers).  You will only have to pay for the game once and you'll get all updates and chapters released.

I do have some ideas for a possible Chapter 4, but I'm thinking way ahead of myself for that.  I also sketched some ideas for a new game idea I have, but I most definitely want to finish this one first.

Anyway, back to programming.  I'd like to add a new enemy and structure this week.  Testers have given me lots of good ideas which I've implemented.  I was going to release the public version of the game this weekend, but with Skyrim and MW3 being released, I thought I'd hold off until next weekend so I actually have some people that might be interested in playing.

I will leave you with a screenshot of my Matterhole farm.  They're really cute.

3000x4000 Alpha II Base

New Lights Video

I love this song.

New Background and Sun Graphic

I think the combination of new Sun and stars background make the game feel a lot brighter.

Alpha II Base, New Lighting

I got several comments about the lighting being too harsh, so I revamped the lighting algorithm.  I also used the opportunity to build a second Alpha Site to replace the old one.  Here is the Alpha II Base.

Click for a huge version.

Lastly, the game now has a Google+ page.

Busy but fun coding night :]

The Alpha Base has been lost :[

I jinxed myself.

Earlier today when I was testing some stuff, I accidentally corrupted my world file.  The Alpha Base has been lost :[  All hope is not lost though.  I have started working on Alpha II and I hope to complete it by the end of the week.  That being said, here is the last known shot of Alpha Base.  This was taken right after I updated the lighting in the game.

I released a new build to the testers tonight.  If nothing major comes up, I'm going to be releasing a build on the tigsource forums later this week.

1080p Gathering Water Video

http://www.youtube.com/watch?v=epXefh76s8U for the full version :]

2659x3000 Image of My Alpha Base

This thing is almost 4 megs large, so here's a link to it.  Down below is a smaller thumbnail.

I need to stop playing and keep working.

Steel

I need to make it so steel + water = rust, too.

Here's the forging formula:

It's the strongest object in the game currently.

Also, here's the forging formula for glass.  It's pretty straight forward.

Forge and Glass

I spent tonight working on the Forge.  The Forge will let you 'cook' items.  It is pretty much the same thing that the furnace in Minecraft is.

The graphic for the Forge isn't completely finished.

You interact with the Forge the same way that you do with the Chest.  When you land on top and open your inventory, a Forge window will pop up.

I had just finished making some glass and there was left-over fire.

For the first forging recipe, I created Glass.  Glass is easy to make.  It takes 1 Sand block to get 4 Glass block.  Glass is placed 'behind' objects.  This means the player and other creatures can move in front of it.  It's a decorative piece and nothing more.

Adding those two things swayed me way off my roadmap.  A lot of my next updates involve sound, so I'm going to focus on that for now.  I've been adding a lot of placeholder sound until I can find/afford a sound person.  I figure that as long as I get the code done, I can consider it done on my end and move forward.

Testers can expect a build with the forge and glass sometime late Sunday.

If you're interested in testing, go sign up at http://www.astrominer.net/f and post in this thread.  I'll send you a link to the latest build.  I could use more eyes looking at the game and giving me their opinion.