Structure statuses. Distributed resource consumption and production.

It's that time again to celebrate progress. Here's a nice video so you know what I'm talking about:

The Details

Introducing: the virtual reality visor! This overcomes a game immersion issue I had.

Game immersion..? You know that feeling when your mind dives into a game, movie, or book so much that the real world goes away? That is full immersion. It can be disrupted many ways: a real life phone call, cat, awkward writing, or bad game design.

Those blue transparent "blueprints" don't exist in the game world. That ruins immersion because it makes no sense for us to see them. I needed an excuse to show them to the player. So now you must be wearing the visor to see the structures you have planned. This way it still feels like you're only seeing what your Martian is really seeing. I thought this was a great solution because "virtual reality" is a real technology that we have today. It also got me started on my first of many "visor" items.

Structure list

Resources can be produced, consumed, or stored. A resource with a green circle means that structure produces that resource, a red bar means it consumes it, and a white square means it can store it. Not super beautiful but it works great. Note that the number of icons is an approximation of the rate/capacity. The game uses real units internally like kwh, kg, etc.

Structure blueprints

The new blueprint window! It's getting easier and easier making new windows like this because I can re-use code. Resources are displayed here just like how they're displayed in the structure list. That is my ResourceReusable class, just one of many "reusable" classes for GUI stuff. This is one of the advantages to planning out my GUI system. I know in advance which visuals I am going to re-use.

Coroutines

Coroutines? If you're not a programmer, maybe skip this paragraph.

I started using coroutines. This way, every single building isn't calculating what it's doing every single frame (which can be up to 60 times a second). Each structure does its thing every second and generally on a different frame because the coroutine is started whenever you start the building. I am aware there are cleverer uses of coroutines, as I've read about them and even went to a talk from a Unity3D software engineer about them! But this is actually my first time using them in any language so it's great to start simple. They're performing great.

Comments

I wrote a ton of comments in my code.

Comments? Commenting is this thing that programmers always say is great to do, but then never do it. As you can see from the picture below, code is weirdly halfway between human-readable and computer-readable. Humans can "read" computer code like this, but it's more work than reading English comments.

Well this is now my second biggest Unity3D project (4942 lines of code). Even though my pseudo-professional design patterns and coding architecture choices are all in my head now, they won't be forever. Sometime, future Stuart is going to wonder what the hell past Stuart was doing with his bizarro code. When that happens, it is much nicer reading a paragraph in English than trying to make sense of hundreds of lines of magic code.

I've never felt the need to comment my code this thoroughly for any project. But I intend for it to get a lot bigger. And that's not going to be possible if it's too hard to remind myself how the pieces are put together.

Milestones

I keep a spreadsheet listing all game ideas I've ever thought of, sorted by priority (around 100 ideas now). Well I invented a "milestone" system which allowed me to go through them all and re-prioritize. My first milestone is "plausible survival and death". Everything I do will be focused on that until I feel I've achieved it. I was surprised how some tasks ended up being much higher priority or lower priority than I thought when put into context.

Distributed resource consumption and production

This also used coroutines. Whenever a structure tries to consume or produce electricity, water, oxygen, or whatever, it makes a request to nearby structures. A producer must check nearby storage if there is space. A consumer must check nearby storage if there is enough to operate. For now, all structures are magically connected to all storage.

Flywheels are like batteries. 

They store energy by spinning a heavy internal disc. Thanks for the idea, Karl.

A crate filled with lithium batteries.

A crate filled with oxygen tanks.

A small water tank.

A big water tank.

Plastic sheet.

Blender is fantastic! I put together this render in no time at all. Like, ten minutes.

Finally I fixed a bunch of bugs.

Onward!

Generation of water and electricity. And a toolbar!

The colony generates water and electricity! Plus I added windows, tooltips, and a toolbar.

GUI..? GUI stands for graphic user interface. This just means all the buttons, menus, labels, and pictures that help the player play the game and get information about the game.

It's been over a week since any major progress because I've been intimidated by all the options that I faced. Designing how information is displayed requires knowing a lot about the future of your game. In the end I actually needed to write out my interface requirements in a document:

This took several hours and it was an extremely good idea. While reading and writing my interface requirements, I was able to clearly imagine the appearance of all the controls and game information. I vividly imagined what it would be like to want information and use my menu to find it. I imagined the exact graphical layout of each window. And because it was written in English and not code, it was easy and painless to revise or completely rewrite.

I highly recommend this process to anyone starting a big GUI system before writing any code. Had I not done this I would have burned a lot of time writing dead-end code, frustrating myself profoundly. That sort of motivation-trap puts the whole project at risk.

At the bottom of the screen is the overview toolbar which turns on and off by pressing "O".

For now I've coded the colony resources window (first button) and colony structures window (fifth button). I have planned the others in my document but will code them only when it adds something meaningful to the gameplay. I don't want to work on something unless it adds something interesting now. Otherwise I would be squandering my motivation.

Thanks to Unity's GUI.Window you can reposition the windows. I also made a tooltip system. My system works great with Unity's OnGUI calls. Just place a single TooltipManager function call in OnGUI for each tooltip and it does the rest. Tooltips follow the mouse smoothly. Tooltips everywhere! Here's a tooltip for the electricity resource (you can't see the mouse in the screenshot):

In other news, I fixed the weather balloon animation, and made a plastic dome for the AWG. I also mass produced a ton of icons. Here are some:

The art is far from perfect. And some of you may be thinking: "surely you could have found some of that art online, for free". Why yes, there are indeed some great free video game icon packs out there. But I think consistent mediocre art looks better than non-matching fabulous art. And since I'm the only artist, all my art has the same mediocre style. That style being the only style I can probably do!

I wrote a python script to count how many lines of C# code is in my project. So far we're at 3706. Gee, C# sure is verbose.

For research I started reading A Traveler's Guide to Mars but found it a little slow so I just switched to On to Mars. It came with a CD with 60 pdfs on Mars colony science but of course the mailman decided to smash it to pieces when he jammed it into my mailbox...

Thanks Canada Post!

Oh well. Onward!

Book Review: Martian Outpost

Martian Outpost: The Challenges of Establishing a Human Settlement on Mars by Erik Seedhouse was decent but it took an unexpected direction and was poorly edited. Despite the title, hardly any time was spent talking about a "Martian Outpost". Instead this was a technical exploration of space travel and propulsion systems in general.

Who should read this book?

Devoted space travel enthusiasts. There is a lot of detail here on propulsion systems, human biology, and the long term plans of different space agencies.

The Good

I learned a lot about how space agencies and private companies plan and design "mission architectures". There is also a huge glossary of acronyms used by the author like LOX (Liquid Oxygen) and MOI (Mars Orbit Insertion). So I think this book was a great introduction to many technical terms used by space agencies.

Most of the book was spent thoroughly exploring propulsion systems, engineering, trajectories, and descent and ascent procedures. It was well referenced and very technical. And given the author's emphasis on its importance, I learned a lot about bone density loss and other health issues humans suffer during space travel.

The Bad

Ideas were dismissed without exploring why. For example, Mars Direct proposes spinning the vessel while in transit to Mars to give the passengers artificial gravity. Gravity solves many health issues that Seedhouse considers to be major health hazards to any Mars mission.

Well, Seedhouse dismisses the spin idea by briefly mentioning communication and solar power difficulties. Yet later, Seedhouse approves of the very same spinning strategy without reservation for Buzz Aldrin's plan. I was confused. Does one spin work and another not? Why? For the rest of the book, Seedhouse uses a hazardous zero gravity mission architecture and I'm not sure why.

Other strategies that were assumed and not defended were bringing a doctor, and not using local Mars resources (ISRU).

This is perhaps the poorest edited non-fiction book I've ever read. It was verbose and repetitious. I believe the basics of bone demineralization are explained on five different occasions. So it felt as though no person is meant to read the whole book cover to cover.

There were technical contradictions. Do Martian temperatures vary from -140 to 17 Celsius, or -120 to 20 Celsius? Is there a maximum Earth-Mars communication delay of ten minutes, or forty six minutes? One time the adjective "lunar" was used in place of "Martian" - so I can't help but think the author copied much of this material from his other book, Lunar Outpost, published just a year earlier.

I counted 11 typos, some of them glaring. Like a "comma period" and even pressing "enter" in the middle of a sentence. From the author's acknowledgements: "I am fortunate to have had my wife ... as my proof-reader". Hah!

Typos do not invalidate the content of any book, but they are an obvious indicator that the author doesn't care very much.

Finally, there was but one chapter on the actual "Martian Outpost". The ideas were superficial and obvious. I've seen far more detail watching half hour Mars documentaries for laymen. Surprising, since this is the focus of the book.

The Ugly

In selecting crew gender, Seedhouse opts for a strictly all male crew. True, tough decisions must be made in space travel, but his justifications are flimsy. They include avoiding sexual tension and a slight advantage men have in radiation resistance. Whereas the proven advantages of including women did not even leave the question open to him. What are his thoughts on women in the ISS I wonder? I was thoroughly unimpressed.

Finally, in the epilogue Seedhouse reveals his bias towards general space travel and disinterest in Mars exploration when he belittles readers of fiction. He says there are "Mars or bust types who have spent too much time reading ... Kim Stanley Robinson novels". His tone says it's silly to be dedicated to Mars exploration, and silly to read science fiction. Robinson's books have won Nebula, BSFA, and Hugo awards. I read one and a half of these novels and enjoyed them. Tell me Seedhouse, how much time is too much time reading inspirational science literature?

Summary

The book provides a lot of great technical details about general space travel but it's poorly edited, repetitious, and has a misleading title. The author appears more interested in the minute details of general space travel than the grand discoveries on Mars itself. As a result, the language lacks poetry and the book lacks inspiration.

Book Review: The Case for Mars

The Case for Mars: The Plan to Settle the Red Planet and Why We Must by Robert Zubrin was inspiring. While this is my first non-fiction Mars read, I can compare it to many other non-fiction science books. And it's been years that I learned so much about something so interesting.

It's no exaggeration to say that reading this book propelled me to do all this work on Martian Agora. While I continue to do other research, the simplicity and reality of Robert Zubrin's "Mars Direct" plan really spoke to me.

Who should read this book?

If you think we are held back from sending humans to Mars for any engineering or scientific reason, you must read this book.

The Good

After reading this book I sense I have the tools to argue for a manned mission to Mars using our current technology. Zubrin thoroughly covers the entire mission: preparation, launch, transit, descent, surface missions, ascent, and return home. In his chapter "killing the dragons, avoiding the sirens" he addresses every fear: radiation, zero gravity, human factors like isolation and insanity, dust storms, Martian germs destroying Earth, and missions from the Moon to Mars. You will be educated and persuaded.

Probably the best aspect of the book is the mission philosophy. Zubrin argues against hauling impossibly large reserves of cargo to Mars. Instead, we have the science to know what's on Mars, so lets use it. The details are interesting and accessible.

The Bad

While Zubrin has support from fellow aerospace engineers and has given talks on Mars at NASA conferences and Lockheed Martin, this book may have benefited by including a chapter or two written by his critics. Perhaps, if we're lucky, by NASA administrators who chose other projects. While the book proved to me that a manned mission to Mars is not only realistic but orders of magnitude cheaper than I realized, my experience changed my thinking so much that I can't help but feel sceptical. Nevertheless, since reading I have looked long and hard online and found no serious problems with this "Mars Direct" plan.

Finally, while Zubrin is very inspiring and optimistic about future missions to Mars, his pessimism towards politics and the administration at NASA is truly infectious. He describes very convincingly how political will has crippled these incredible exploration plans. This reminded me of becoming an adult. You may not want to realize certain things about the world, but then you do. I hope that some of the other Mars books I will soon read will offer refreshment.

Summary

This book is like a great science fiction book about starting a colony on a new world - except it's not science fiction at all. It is an exciting read because the science is real and the adventure is imminent. Mars is just patiently waiting for humanity to get our shit together.

Mars Research, Books, and Inspiration

Contrary to popular belief, the science and engineering ideas for the Martian Agora game I'm working on do not spew forth from my undiluted genius. I've done and will continue to do lots of research. While making a fun game is my top priority, making it accurate and thus educational is a close second. I've had a ton of fun learning about Mars these past few months and I hope my game will pass on some of that fun.

My interest in Mars started a few months ago when I spent a couple hours in a book store combing through all the books in the science section. I didn't know what I was looking for at the time, but one of the books I got that day was "The Case for Mars" by Robert Zubrin. This book showed me so much that I didn't know about Mars exploration. I highly recommend this book to anyone with a scientific soul.

After finishing the book I found myself looking online for more about Mars and space exploration. I found this Mars rover simulator made by NASA and this Canadarm2 simulator made by the Canadian Space Agency. Both games were made with the same game making tool I use. So I thought: hey, making a Mars game might not only be fun, but could help me get my dream job of making education games and software.

After sifting through reviews on dozens of Mars books, I just ordered these four:

• A Traveler's Guide to Mars
• Martian Outpost: The Challenges of Establishing a Human Settlement on Mars 
• On to Mars: Colonizing a New World
• On to Mars 2: Exploring and Settling a New World 

Since this blog is all about Mars and science, I will write quick reviews as I read them, starting with "The Case for Mars".

Building wind turbines and solar panels. Tools, work, and more!

Wow! Looking back now I've done a lot since my last post. Here's a video with my new ladders and construction system:

The tools appear in front of you now, and most have sounds they play when you use them. Tools have durability (they wear out) and some use battery energy. And we have yellow work cones now! I did a neat trick for the sounds: say I have ten seconds of "wrench". I start playing at a random point and loop, so the tool sounds different each time.

Another quick improvement was the skybox. 

Skybox..? The player is positioned right in the centre of a giant cube (the skybox), and the faces of the cube look like a sky. Making your own is not as simple as using paint/gimp/photoshop though. If you don't do it right you can tell it's a cube! That's just silly.

I didn't make a fancy 3D projected one like this fellow this time though. It's just pure colour with a hint of radial gradient. There are no seams because I made the edges of every face the same colour. This is still remarkably close to the Martian sky though. Big payout for little time investment - always a good choice for a team of one.

Ladders! The ladder script builds a ladder of any height using a 1 meter tall segment that it repeats over and over. I did a lot of tweaking to make the ladder feel comfortable:

• You only move up/down when you're looking at it. So you can stop climbing and look around freely.
• You get locked to a nice place just in front of the ladder until you jump off.
• You have to leave the ladder entirely before reconnecting.
• You can move higher than the topmost rung so it's easier to get off.
• There are also a ton of funny little issues that had to be solved.

I've never made a ladder before and it was fun thinking about all the ways to do it. I am considering making a super duper ladder script and putting it on the Unity Asset store. It would include some features I skipped like tilted ladders. 1$? We shall see.

I ordered four Mars books! "The Case for Mars" by Zubrin was great but it's inadequate as a sole technical reference. This merits its own post.

Lastly, I did a ton of modelling work again. I am finally starting to feel like I have a strong variety of models to make a game with. Here are the item icon renders:

Charging station. This model took awhile! Cables. Cables everywhere.

Electric generator.

Lithium battery.

Martian concrete.

MPPT controller. I always have to look up what this acronym stands for: maximum power point tracking controller. Used in devices like solar panels and wind turbines because the electricity generated is irregular. I really still only have the vaguest notion of what this does.

Power cables.

Solar cell.

Solar panel.

Steel. How might an early colony access the huge stores of metal on Mars? Hmmm!

Turbine blade.

Wind turbine.

There are three main types of wind turbine. If only I had a better idea of which work best on Mars... For now, this one will suffice. Perhaps the four Mars books I just ordered will help? :)

Wire cutters.

Wrench.

So what's next? I must follow my own rules and not talk about what I will do. Instead: we have electricity. What other resource is critical to a Mars colony?