Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

1044467 Posts in 42327 Topics- by 34012 Members - Latest Member: Ad4m

September 21, 2014, 08:08:01 AM
TIGSource ForumsFeedbackDevLogsThe UnEarth Initiative - Space Colonization Sim
Pages: [1]
Print
Author Topic: The UnEarth Initiative - Space Colonization Sim  (Read 1663 times)
Phastin
Level 0
**


Might know the first thing about programming


View Profile WWW
« on: November 22, 2013, 09:17:05 AM »


  Hello everyone! For about six months now I've been spending my nights and weekends working on a game about colonizing other planets. Last week I stopped all of my paying contracts so that I could work on it full time, and so it seems like a pretty good time to start posting about it too.

Screenshots!
Here's what the game looks like currently:









Movies!

Here's the game's trailer
Here's a quick fly-through from an earlier development build.

So what's it all about?

  The UnEarth Initiative is a humorous sci-fi sim where Earth is coping with its overpopulation by sending its least desirable citizens into deep space on poorly equipped colonization crafts. The effort is being billed as 'colonization', but in reality Earth's government would be happy to never hear from any of its misfit colonists again. =)

  You play as the manager of a colony ship that has just crash-landed on an alien world. It's your job to lead everyone as they build, mine, and explore their new home. And since your ship was filled with misfits, prisoners, and rebels that Earth didn't want, you'll have your hands full keeping your own citizens in line, even before you meet any aliens...

  We're looking to strike a balance between building a well defended home, and also sending colonists out to scout around and scavenge resources as part of (potentially dangerous) away-missions. Every world you play on is procedurally generated, so there's no predicting what sort of threats or opportunities you'll uncover...

Who's working on this?

There's Peter Hastings (me), doing code and design, Lesley Mathieson working on design and story, John Lally doing our modeling, rigging and animation, and Janice Chu doing concept art and texturing.

We're all working hard now to finish a playable demo of the game, and I'm going to try and post updates each week about our progress.
Thanks!
« Last Edit: June 27, 2014, 07:29:50 AM by Phastin » Logged
DrunkDevs
Level 1
*


Drink beer and make games


View Profile WWW
« Reply #1 on: November 22, 2013, 10:33:23 AM »

I like the emphasis on the humans being undesirables. That's a really cool mechanic that I haven't seen before in this style of game. Best of luck to the team on this project.
Logged

Want more Drunk Devs?
DrunkDevs.com / Facebook / Twitter

Current Devlog:
Kegbot
Phastin
Level 0
**


Might know the first thing about programming


View Profile WWW
« Reply #2 on: November 22, 2013, 04:42:26 PM »

Thanks! Getting the AI to understand and manifest personality quirks is one of the bigger coding challenges in the game. I'll have an update soon to talk about how that's working...
Logged
Phastin
Level 0
**


Might know the first thing about programming


View Profile WWW
« Reply #3 on: November 29, 2013, 09:23:39 AM »

Time for a Friday update!

Our concept artist, Janice Chu, has written a blog post about how she approached the look of our game:

http://www.inklinggames.com/updates/?p=29

Logged
wccrawford
Level 2
**



View Profile Email
« Reply #4 on: December 03, 2013, 11:11:30 AM »

It sounds very Douglas Adams-esque.  Wink  I'm looking forward to seeing more of this!
Logged
Phastin
Level 0
**


Might know the first thing about programming


View Profile WWW
« Reply #5 on: December 14, 2013, 08:18:26 PM »

More Friday update goodness, now on Saturday! (Because I got distracted coding)

Our designer, Lesley Mathieson, talks more about the personality quirks that make each of your colonists special unique (and occasionally kleptomaniacal) snowflakes:

http://www.inklinggames.com/updates/?p=65
Logged
Phastin
Level 0
**


Might know the first thing about programming


View Profile WWW
« Reply #6 on: January 03, 2014, 01:31:28 PM »

Happy First-Friday-Update-Of-2014 Everyone!
 
  I've spent the week putting together dialogues with alien races. Once you've got your colony set up to the point where you're producing electricity, mining metal, and able to fabricate techy stuff, you're now able to build radio antennas and broadcast your whereabouts into space.
  This means that passing aliens will come to visit and offer to trade for your valuable stuff. Or they might just try to kill you and take your stuff. That's probably going to seem like the more expedient route to a lot of hostile aliens out there... Which reminds me that I should get on with implementing more advanced weaponry...

  Also, have you ever put off implementing a major feature for weeks because it seems like a nightmare, but when you finally force yourself to do it, it turns out to be incredibly easy? Well, me too. On Monday I made it possible to script/code the mechanical devices in the game -- making them move around and do work for you. And it turns out integrating a scripting language for the user in a Unity project is really, really, shamefully easy. So easy, in fact, that I had time left over to write a blog post about it.


Follow that link to learn some more about what we're doing with modding your own robots, and getting them to browse the internet and display RSS feeds to your colony. =)
Logged
Phastin
Level 0
**


Might know the first thing about programming


View Profile WWW
« Reply #7 on: January 11, 2014, 01:43:53 PM »

So, for whatever reason, I appear to be constitutionally unable to post Friday updates on Fridays.

Lesley Mathieson, my partner in crime and game design has posted a blog about how she sees tools, weapons, and machines working in our game: Do please click me.

Logged
Phastin
Level 0
**


Might know the first thing about programming


View Profile WWW
« Reply #8 on: February 21, 2014, 07:53:37 AM »

It's been a few weeks since I had a chance to post, and the reason is: We've been hard at work polishing the game and preparing for a Kickstarter campaign!

I'd like to get your guys' feedback before we launch. Do please take a look at our gameplay trailer




This trailer will be the first thing that people see of our campaign. Does it make you want to pull out your wallet and give $20 to help make the funniest indie space-colonization-by-former-convicts game that's ever existed?

« Last Edit: February 21, 2014, 08:15:43 AM by Phastin » Logged
Phastin
Level 0
**


Might know the first thing about programming


View Profile WWW
« Reply #9 on: March 04, 2014, 08:23:05 AM »

Folks, we've just launched our Kickstarter campaign, and we could use your help!
Logged
Music Vortex
Level 0
**



View Profile WWW Email
« Reply #10 on: March 06, 2014, 04:29:38 AM »

Very nice, I really like the looks of the game. Programming my own robot sounds very cool!
Good luck with the KS Smiley
Logged

Jose Mora-Jimenez - Composer
Website | Soundcloud
Phastin
Level 0
**


Might know the first thing about programming


View Profile WWW
« Reply #11 on: March 06, 2014, 01:19:20 PM »

Thanks! Now that the coding system works, I've been thinking about extending it so to let players mod more of the game's features. Like writing your own events and story-lines...
Logged
Phastin
Level 0
**


Might know the first thing about programming


View Profile WWW
« Reply #12 on: June 27, 2014, 08:50:18 AM »

Hi folks! I finished coding something the other day which I'd never had to do before: letting the player save the game anywhere, at any time.

  That's obviously not a giant unsolved riddle that's had computer scientists stumped - many games do it. But every game I've made before has always used checkpoints, so I didn't have to worry about loading game objects into *exactly* the state they were they were saved. With checkpoints, it was usually enough to say: 1) Load level X, 2) Warp the player to point Y, 3) Okay, go.

  Since it was clear that I needed to write a proper Save-Anywhere system for UnEarth, I decided my first step would be to take all of the game's internal data and conceptually break it into two pieces: The things that really *need* to be saved, and the things that can be either be inferred or just aren't important enough to save. For a creature in the game, that first group is generally just "where am I, what is my goal at this moment", the second group contains things like "what frame of animation am I on right now, what particle effects am I handling, what sounds am I playing," etc. When we load a save and discover that a creature was in the air, jumping, we can put it into its jump animation. If there was a particle dust cloud from its jump? Fine, we can just ignore that.

  Another big conceptual decision in designing the save system was choosing where complexity is going to happen: Games like UnEarth have a heap of unique creatures and events. Each of these has code behind it and data that's going to need to be saved. I decided that if I can make it simpler to write AI code at the expense of making it harder to write the save system, I'm going to do that. Because the save system is small, and the AI code is vast.

  In short: The first step of saving anywhere was mentally collecting an idea of what information needed to be saved, and what didn't. The next step was designing a system to save all that data that puts as little work as possible on the game objects themselves.

  Okee. From here I'm going to get a little more specific. UnEarth is being made in Unity and I'm using C#. Specifically, I'm using C#'s reflection features. If you're coding in a language that doesn't support reflection, you may need to approach this implementation very differently.

  Saving begins with an Attribute - a tag, essentially, that you can apply to any classes members:

Code:
using System;

[AttributeUsage(AttributeTargets.All)]

public class NeedsSaving : System.Attribute
{
  public readonly string Name;

  public NeedsSaving(string name)
  {
    this.Name = name;
  }

  public NeedsSaving()
  {
    this.Name = null;
  }
}

With this defined, we can begin marking-up variables inside game objects -- tagging the things that we know we'll want to save.
Like so:

Code:
  public class Door : MonoBehaviour
  {
    [NeedsSaving]
    bool m_IsLocked;

    [NeedsSaving]
    bool m_IsOpen;

    ... 
  }

  C# gives us the ability to take any arbitrary object and walk through its members, checking the attributes of each one. So in a nutshell, that's what we'll do when we save the game - we write down a list of all the game objects in the world,  then peruse each object for members that are flagged as [NeedsSaving] and write down whatever we see there.
  As I mentioned early, this makes life super easy for writing AI code. You just drop [NeedsSaving] on to a variable you think you'll need to hold on to, and you're done. It's pretty hard for the save/load code itself, though, because that code needs to understand how to take literally any kind of member data and save it to a file. But like I said - better to solve a hard problem once, then to have to do a minor headache a hundred times.

  Wait! You say, writing booleans and integers to a file doesn't sound hard. But one of the most relevant things a AI needs to save is references to other AIs in the level. How do you store that?
  To store references to other game objects, the save/load process has to take two steps: First, creating a list of all the relevant game objects, and only then saving all of their member data once that list is complete. Why? Because one creature's reference to another creature is saved as an index into that complete list of game objects. So, for example, if this HostileAlien class wants to save a reference to who it's shooting at:

Code:
  class HostileAlien : MonoBehaviour
  {
    [NeedsSaving]
    GameObject m_OurTarget;
    ...
  }

...what the save system is actually going to write down for the variable 'm_OurTarget' is a number. Specifically, the place in that big list of game objects where the target resides. Then we when load everything back, we begin by creating each of those game objects. When we come back on a second pass to fill in member data, it's trivial to read that 'm_OurTarget' was object number 17 and fill in that connection from the list.

  Also of note: backwards compatibility. You really don't want to break all your old saves anytime you add a new variable that needs saving, and that means that when you load a file, the system needs a way to tell what member a particular block of data is meant to fill in to. To make this work, member data is stored in file this way:
Code:
  An integer hash, based off of the member's name.
  An integer holding the length of the data used to describe this member.
  The actual member data.
  When the system reads an object's member data, it starts with that initial hash, and checks if it can find any member in the current object that matches. If it can't, then it knows it's dealing with a member that used to exist in an earlier version of the code, but was removed. It continues to the next line - the length of the data stored for this member - and uses that to skip ahead to the next piece of member data in the file.
  On the other hand, if it can find a match then it gets the type of the member using C# reflection, and uses that type as a guide for how to parse the data stored in the file.

  Two rare things can go wrong with this. There's a one in four billion chance that an object contains two members that generate the same hash code. Currently I get around this by having the save system check that no two members in any object have the same hash. If they do, it simply throws an error and I rename something. (This has never happened yet, except when I forced it to as a test.)
  There's also the possibility that a person might mark a member as needing to be saved, but latter change its type without renaming it. Since the save system uses a member's type to determine how to parse the data stored in the file, this could get ugly. The fact that the length of the data is also written in the file gives you a small measure of protection from this: The system will generate an error if the data is the wrong size. But the case where you changed an int to a float (both having the same size when saved), and then load an old save will result in some improper behavior. For now, I simply remember to avoid doing this.

  There's actually a whole lot more I could write about how this system works - especially on how arrays, lists and enums are handled inside the system. But for now I'll leave it at this high level overview. If anyone is interested in the gritty details of serializing arbitrary member data, let me know. I might start a thread on the tech forum for it. =)
Logged
Music Vortex
Level 0
**



View Profile WWW Email
« Reply #13 on: June 27, 2014, 10:39:32 AM »

Nice to see that the project keeps moving forward Smiley
Saving the game at any time sounds great, much better than check points.
Logged

Jose Mora-Jimenez - Composer
Website | Soundcloud
Pages: [1]
Print
Jump to:  

Theme orange-lt created by panic