The Community-Driven Game

Imagine you are driving a car, and you have three of your misanthropic friends in the back. Suddenly they lean forwards and ask if they can help steer. You think this might be a bad idea, but before you can react they clamber forwards and put their hands on the wheel. Most people would at this point judge the situation as “not a good idea”.

Replace your annoying friends with the Internet (uh oh), and replace the car with an indie game. Congratulations, you have just created the perfect environment for a terrible game to develop. Actually, often times the situation only gets as far as the Internet playing backseat driver, yelling out confusing and contradicting directions that are both useless and hard to ignore. But for a game like KSP, the community has leapt into the passenger seat and nearly wrested controls from the developer.

The developers of KSP are driving towards a cliff of not-fun. They could probably make a good game that stood on it’s own and appealed to a certain audience if left to their own devices. However, because the early prototypes of the game drew such a diverse crowd, the fans want the game to head in a couple of conflicting directions. Few people share a common vision for the game, and a lot of people like to play armchair game designer.

I honestly think some of the more prolific modders in the community have been taking the game in a more suitable direction. Meanwhile, the community quibbles over what should be included in the stock game and what shouldn’t. I want to take one of my biggest peeves as a case study:

One of the most touted arguments against certain large features is that the feature merely adds another level of complexity without adding any “true gameplay”. For example,

  • Life Support would just mean another thing to worry about, and it would reduce the amount of shenanigans you can do (stranding Kerbals on planets for years, etc).
  • Living Room/Sanity mechanics? Nope, it would just be a hassle. You have to bring up bigger habitats any time you want to send a mission to somewhere far away. It doesn’t add any gameplay during the mission.
  • Reentry heating? That just restricts craft designs, making people conform to certain designs and plan around reentry.
  • Different fuel types? Too complex, requires a lot of learning and planning before hand, and only restricts your options during a mission (again, restricting shenanigans).
  • Realistic reaction wheels that don’t provide overwhelming amounts of torque and require angular momentum to be bled off with a reaction system periodically? Could prove to be annoying during a critical part of a mission if you hit max angular momentum. Requires you to put in a reaction system even if you only want to rotate your craft (not translate).

Do you see the problem with these arguments? You are arguing that something shouldn’t be added to the game because it adds gameplay that isn’t in the game right now. See how circular and pointless the argument is? The worst part is that it could be extended to basically any part of the game that exists right now.

  • Electric charge? What if you run out of charge during a critical maneuver, or go behind the dark side of the planet. It’s A GAME, we shouldn’t have to worry about whether or not the craft is receiving light. Just assume they have large batteries.
  • Different engine types? That would add too much planning, and just limits the performance of the craft. What if I need to take off, but my thrust is too low to get off the ground? That wouldn’t be very fun.
  • Taking different scientific readings? That sounds like it would be pretty tedious. You shouldn’t add something that is just going to be grinding. The game doesn’t have to be realistic, just fun.
  • A tech tree? Why restrict players from using certain parts? What if they want to use those parts? You shouldn’t restrict parts of the game just so the player has to play to unlock them. That doesn’t accomplish anything.

Hell, why even have a game in the first place? It sounds like a lot of thinking and planning and micromanagement and grinding.

Of course, this could be considered reductio ad absurdum, but the problem is that it actually isn’t. The arguments against Life Support or different fuel types or reentry heating just don’t hold any water. Yet people hate against them, so the developers are less likely to put them in the game. Since I started with a metaphor, I’ll end with one:

The developers of KSP are driving towards a cliff because the community told them to. Fortunately, they realized it and are now putting on the brakes. In response, the community is shouting “why are you putting on the brakes? That only slows the car down!” To which I reply, “yes, yes it does.”

Advertisements

Mass Paradigm

One of the most interesting things to think about with respect to the near-future of space travel is the removal of limited mass as a paradigm. That is to say, right now the predominate design constraint for spacecraft is mass, because rockets are very expensive, so each kilogram of payload must be put to best use. Unfortunately, this means that the design and construction costs for spacecraft are very high, as much effort is put towards shaving off grams by using exotic materials and efficient designs.

But soon the current launch vehicle renaissance will result in launch costs low enough to demolish the limited-mass paradigm. There is a tipping point where it is economical to cut design costs and take the hit on launch costs. There will also see a growing emphasis on tough and reliable systems that last a long time, rather than fragile, light, efficient systems. Combined with lower fuel costs from asteroid mining and improved refueling technologies, the predominant modus operandi will be repairing spacecraft rather than replacing spacecraft. Designing for reusability and, more importantly, refurbishment will be critical.

We’re already seeing a shift towards this paradigm with SpaceX. Their launch vehicles use redundant systems to make up for their cheaper designs — their avionics electronics, for example, are not rad-hardened but instead redundant in triplicate. The mass penalty is minimal, however they also make up for it by using modern electronics concepts. For instance, instead of running numerous copper wires up and down the length of their rockets, they run a single ethernet cable and use a lot of multiplexing.

This kind of change is just the beginning, however. There will be a time when it makes sense to loft a big bundle of steel rods into orbit and have workers weld them into a frame for a spaceship. This has a number of benefits: the frame doesn’t have to be fit into a fairing, it can be reconfigured on the fly, and it doesn’t have to endure the acceleration and acoustic stresses of launch. Additionally, lifting big bundles of steel makes best use of the volume in a launch vehicle fairing.

I think the only two questions about the future of space travel are: How much will it be dominated by robots? and Where will the money come from? But those are questions for another time.

Unity and tjSTAR

Here is a soundtrack for this post:

Everybody should use Spotify. It’s like magic, but real.

So I wanted to talk about Unity. For those who don’t know, Unity is a game engine. But it’s way for than that. The best way to describe is an IDE for game development, similar to UDK. Every part of the development cycle (aside from asset creation) can be done within the program, from placing assets to creating game object behavior to playtesting. The engine also has built in support for pretty much anything you would want to do. Behavior is described through scripts, which can be written in JavaScript, C#, or Boo (which seems to be a Python/C# hybrid). Assets can be imported from almost any file format, without external conversion. For instance, any 3D file format that can convert to FBX works, and image formats from PSD to PICT. Unity constantly checks for asset changes and updates them in realtime.

A good analogy involves programming languages. UDK is like Java, while Unity is Python; Source is C++. You don’t really understand how much annoying background work you are doing with Source until you start using Unity. However, unlike Python, Unity has an enormous learning curve. This comes from its being extremely powerful. I’ve only just started working with it (a few days) and I can see that there is a huge amount of potential. I also still have no idea how to most of anything.

The event that sparked interest in Unity was tjSTAR, an annual symposium held by my highschool. In addition to Design Challenge events and student presentations, there are also panels and professional talks. I attended 5 talks, all of which were fairly interesting.

Game Design and Development as an Academic Path and an Industry
This presentation is an in-depth look into majoring in game design in college, what universities offer the best programs, and how to get in; accompanied by an overview of the game industry and the careers it offers.

Mr. Danny Kim
Student
University of Southern California School of Cinematic Arts, Interactive Media Division

This was the presentation that got me interested in Unity. Of course, I had seen it before, such as at SAAST(the computer graphics course, specifically) when we looked at projects the undergraduate students had been doing, they used Unity for the most part. Danny Kim (a TJ alumni himself) also talked about how TJ is a great source of talent, both due to the large number of talented programmers, but also the great writers and artists. Any interested reader should check out his blog, See Play Live.

Big Data: What Is It and How to Cope With It
With the digital world enveloping our lives through mobile devices, digital home appliances, digital sensors and controllers, and video, data growth is expected to be massive in the coming years pushing into peta and zetabytes. Of this data, only 5%-20% will be structured. Find out how is the technology world is preparing to cope with this onslaught.

Ms. Rumy Sen
President & CEO
Entigence Corporation

This talk was about processing large amounts of data, especially sampled from online sources and social media. The objective is to analyze the whole of customer feedback across the Internet rather than from small testing sessions performed by marketing and consultant companies. However, this requires entirely new structures for storing and processing the data into a usable form. She talked about Hadoop and other forms of managing unstructured data that differed from conventional database methods, as well as processing methods such as massively parallel processor arrays.

Computer Vision: Challenges and Applications
Computer vision is the art of teaching computers to see and to understand what is in images and videos. The presentation will discuss some of the key challenges, and show practical applications.
Dr. Peter Venetianer
Director, Commercial Science Development
ObjectVideo

Computer vision is obviously interesting. The big brother of computer graphics (the two are inverse problems), it has stumped researchers for decades. The first professor to attempt the problem was sure that a summer with a lab of grad students would solve it fine. Now, 50 years later, we are starting to make some headway. Dr. Venetianer discussed some of the methods for separating critical objects from a noisy environment. Spotting movement from a fixed viewpoint is fairly easy. If you have three consecutive frames, spotting moving objects is simple using the three-frame method (it involves comparing differences). However, identifying the objects is much harder. If you know what to look for, the problem simplifies somewhat, but there are still numerous exceptions. A car is usually wider than it is tall, except when it is coming towards or moving away from the camera. A person is usually taller than they are wide, but a group of people is more likely to match the profile of a car.

Spacecraft Guidance, Navigation and Control
Guidance, navigation, and control (GN&C) is a specialty area in Aerospace Engineering that involves determination of how a vehicle gets to its target, knows where it is, and maintains its position or trajectory. These concepts and related technologies will be highlighted for spacecraft application. Some of the projects involving GN&C at Emergent Space Technologies will be summarized.

For more information, visit http://emergentspace.com/.
Dr. Sun Hur-Diaz
Vice President
Emergent Space Technologies, Inc.

Until you think about it, determining where you are in space might seem trivial. But because hardware never reacts perfectly, a spacecraft needs to constantly be checking its position and orientation. But you need a variety of instruments, such as sextants and telescopes, to determine orientation. To find your location in orbit you need at least four GPS satellites. Finding which orbit you want to go into requires some physics simulations, as well as constant corrections to maintain it. In fact, finding an orbit to optimize fuel usage and time for a set of destinations is a huge field.

Millimeter Scale Robotics Research and Development at the MITRE Corporation
As we continue to look for ways to keep soldiers and first responders out of harm’s way, the capabilities of robotic systems improve and demand for them increases. While large robots have been used extensively, the development of smaller robots opens up a range of additional potential applications, such as accessing confined areas for search and rescue or surveillance purposes. To address this emerging need, MITRE’s Nanosystems Group has been developing rugged, low-cost robots, designed to be carried in a pocket. They can be operated from a mobile phone and reconfigured in the field to quickly adapt to specific missions.
Ms. Jessica Rajkowski
Systems Engineer, Sr
The MITRE Corporation

I don’t know if I mentioned this before, but I am working at MITRE this summer, albeit in a different division. The talk was still fascinating. Some of it was about developing micro-scale “robots” using interesting properties of polymers and metals. The speaker also discussed MITRE’s development of a hand-sized field robot designed to be low-cost, low-maintenance, durable, and easy to control. Obviously this would normally violate the rule of “cost, speed, quality; pick two”. To some degree it was speed that was sacrificed. It took years to develop the robot, but at its current stage it is pretty amazing. Another subject of the talk was the speaker’s project to set up a consistent test for testing whether a producer’s robot was up to MITRE standards.

I’ve also continued to use Google AppEngine and I’m working on a forum, seen here.

Interstellar Travel

The most important part of writing science fiction is laying down a set of rules which stays constant throughout the book. In A Fire Upon the Deep (aFUtD), there was hyperwave, anti-gravity, hyperspace, and the Zones. In The Mote in God’s Eye (tMiGE), there were only two pieces of technology which violated physics: the Alderson Drive and Langston Field. Each was defined very clearly. Nothing is more infuriating than when an author saves the day with a previously undisplayed loophole.

Cover of A Fire Upon the Deep

The interesting thing about tMiGE is the interstellar travel. Scifi authors usually couple FTL travel with FTL communications; in tMiGE, the only way to send a message to another star system in a timely manner is to send a messenger ship. In addition, jumps between systems can only be made from specific points within each system, determined by the mass of the star and the arrangement of surrounding systems. aFUtD uses a similarly interesting, but completely different, device. Starships in the Beyond make micro-jumps, instantaneously jumping between two points in space and then calculating the next jump. This means that to go faster you just need more computing power. Systems built for different regions of the Beyond work differently; a bottom-lugger isn’t as fast as a state-of-the-art battleship except close to the Slow Zone.

In the fictional world I’ve been developing through a short story, interstellar travel is also interesting. Like tMiGE, the only way to go faster than light is with a spaceship. In my universe, ships have a minimum size requirement; messenger probes are out of the question. An interstellar drive has two parts: the ring, and the spikes. The ring manipulates space, flattening the local regions of the universe around the ship. While in theory a ring could be any size (bigger rings make bigger fields in a not quite linear fashion), it would lack control and have a tendency to fall into gravity fields. That’s why a ship needs spikes. Spikes are long, thin sensors that monitor the properties of the universe in small regions of space. They help the ring avoid massive bodies, correct for small spatial inconsistencies, and deactivate in the correct place. The more spikes a ship has, the safer and more precise it is. The higher quality a ring a ship has, the faster it can go. A ship that was too small wouldn’t be able to avoid planetary bodies or have a large enough detection field to navigate in flattened space. Ok, so maybe there is a little bit of Handwavium. But not THAT much.

You may be wondering: if the spikes hold sensors, why not just make a bigger spacecraft and imbed the sensors within the hull? Good question, reader. The answer is: you could. That is, if you are filthy rich. Rich people sometimes drive crazy cars and build crazy buildings, so certainly some people would make stylish spacecraft. At the end of the day, though, your spaceship is still occupying the same volume of space. It uses more sensors (unless you want minute pockets within your spaceship to expand and explode), and it only gives so much more interior space. It masses more, which means more energy or fuel to boost it through regular space. Spaceships aren’t like cars, either. Stylish lines are going to count for very little; even space stations don’t have windows, and nobody uses video to navigate. The result is that most spaceships are spheres inside a forest of spikes. Not very romantic, is it?

Mass is going to be the limiting factor on spaceship size. Unless you have very expensive spikes, you are still going to redimensionalize hundreds of thousands of miles from your target. You need some sort of in-system propulsion system. Since it is impractical to put a high-powered propulsion system aboard an already too-small ship, most spaceships would use local services: tugboats. Even obscure areas could afford one or two spacecraft with excellent traditional drives that can ferry interstellar craft around in cubic space. This also solves the problem of giving interstellar craft big dangerous drives that create exhaust. Except for military ships, redimensionalizing craft wouldn’t run the risk of toasting someone behind them. Military ships would be the exception; your enemies aren’t going to help you invade their system, so you need your own engines. On the other hand, military ships would be significantly different already. Most attack ships would be gigantic; they need to carry ship-board weapons, planetary craft, and a propulsion system. Military ships also carry prized interstellar equipment; governments are going to outfit their fleet with the finest rings and spikes.

%d bloggers like this: