Solar System Simulation

Creating a realistic simulation of a solar system has proven to be an interesting project. It seemed simple enough at first, just find out the orbital distance and speed of each planet, apply those to a particle, add the force of gravity from another particle acting as the sun, and you'll have a good simulation, right? Not quite.

First of all, what kind of units do you use? If you are getting your data from most places, you will be finding kilometers and kilograms are the standard units of measurement for nearly all aspects, and they get big fast. It gets hard to deal with every unit being either a magnitude of 20 above or below zero. How to solve the unit issue? Find one that balances all the planets, and the sun, so that nothing is too large or too small. Gigameters was a good solution for distance, being a magnitude of 6 larger than kilometers, it significantly increased the readability of numbers, bringing orbital distances into the 100s of Gms, rather than the hundred millions of Kms. Mass, on the other hand, is a much larger beast. The order of magnitude difference between the sun and the lowest mass planet, mercury, is 7. To solve this, I found that Yottagrams (e24 grams) is a viable unit for mass. While it means that the sun is still measured in the hundreds of millions, every other body in the system has a much smaller magnitude.

So, we have our units, Gigameters and Yottagrams. We put in all the data using the correct units and our planets are instantly pulled to the center.

Why would that happen? We used all the correct units for our planets, we used the actual gravitational constant, everything should work! Wait, the Gravitational Constant has units. We never converted the G from Km^3/(Kg s^2) to our new units of Gm^3/(Yg s^2). That would be our problem! The magnitude of the G is off by a few digits. Wolfram Alpha is very useful for things like this, meaning we don't need to worry about making a conversion mistake, as long as we ask for the correct units(Check it out).

With that out of the way, now we have all our units in accord, our gravity should work and lets see how it turns out.

After a little more playing around, I found that the moon does orbit the earth properly, but only when the "warp" is extremely high.

Production

Browser Controller

I have successfully implemented the browser controller, which currently works on most Android and iOS devices. The system implements WebSockets to make a connection to the server then feeds touch data through the socket connection. The interface as it stands currently allows for a large amount of future customization and alteration.

The current control scheme is a slight alteration of the Twin-Sticks scheme available through the Android App, with the caveat that the center of each stick is set to the position the touch input begins. An new scheme that is planned, but has not yet been implemented, is a somewhat gesture based input, where the input is based not on the delta from the center of the joystick(where the touch began) but on the delta between touchmove events.

Improving Character Motion

Another aspect of the input that we are working on is the slipperiness of the character when moving. The character currently moves based on forces being applied to a rigidbody that is part of the character, which is an effective way of maintaining realistic interactions between the player and other objects. The downside, however, is that because motion is created by force being applied to the unit, that it slides, rather than immediately changing directions when input is changed.

Production

Implementing an alternative control interface

One of the major goals over the last semester was improving our control interface. Seeing as we are using a mobile device as the control interface, it both limits and opens up a lot of possibilities. More importantly than the actual interface, though, is the accessibility of the interface. Until now, our interface has been in the form of a lightweight Unity app that can be downloaded and installed on Android devices. While this worked extremely well for a majority of people who downloaded the app to play the game, some users found the that their device would not run the Unity application. We were also faced with the limitation of only being on Android, as we don't currently have the facilities to built to iOS and Unity for WindowsPhone currently lacks the networking functionality we need. With these facts in mind, I set out to develop an alternative interface that would be OS independent and would be able to run on a wider range of devices than the Unity Application. My solution? Websockets.

Implementing WebSockets with Unity

When I started out, I didn't exactly understand the WebSocket protocol. I'd never used it before, let alone HTML5 in general. I soon came across two promising C# implementations of a WebSocket server that I could potentially run within Unity as an alternative to the Unity Networking we were currently using. They being Alchemy Websockets and WebSocket-Sharp. I quickly realized Alchemy would not be a viable solution, as it is built in .NET 4.0, which Unity does not support. WebSocket-Sharp, on the other hand, was in .NET 3.5(Unity compatible) and even had a Unity Asset Store download available, which was a good indicator for me that it would be Unity compatible, so I set off with it.

This is more or less where I am now, I have WebSocket-Sharp successfully running within a Unity project, accepting connections from a quick html/javascript page I wrote up to connect to it and easily reading information back and forth between clients and the server, basically all of the functionality I need to convert the input system of the game from Unity Networking to WebSockets.

That said, I have hit a few snags now, for one, WebSocket-Sharp seems to leave a socket listener open(when running in the editor) no matter what I do to close it, which is a pretty big issue that I need to solve before I more further towards implementing it into the full game. I'm not sure at the point if it is an issue with Unity and the threads WebSocket-Sharp uses or an endemic issue with WebSocket-Sharp. Further investigation is required.

Production

Second Semester

After a break of a month, it's time for production to resume for the final 4 month. We've added 5 new team members to Phlegmatic Studios and are looking forward to working with them to improve our game as much as we can. We have a lot of ideas to discuss and decide upon and even more work to get done before the Senior Show in April.

Improvements

There are a few key areas that we, as a team, have decided we need to focus on first. The highest priority of these being the control scheme. Throughout the first few months of production, we mainly used a "twin-stick" configuration for controls, with two virtual joysticks as the method of input on the device, but as testing and feedback have shown time and time again: this isn't where we should be. Testers have found it lacking in many ways and desire something better. Our first task is to figure out what that "better" is and implement it as quickly and effectively as possible.

The next high priority area that we need to focus on is the aesthetic and theme of the world. As it stands right now, players are dropped in a pretty generic and empty feeling factory environment.

While it has worked for us up to this point, we have decided that we need to push it, either locking down on the factory setting by making the level more like an assembly line, or by taking it somewhere else entirely. The primary alternative idea, at the moment, it a Dr Sues feel, with comical looking machinery and strange devices whirling and buzzing around the level.

With these two primary points of focus in mind, we resume our work with new team members providing fresh and interesting new ideas that will take our project to new heights.

Production

The first four months of Push-It

Push-It as a game began significantly different than what we have now. When we began, we knew we wanted to create a cooperative multiplayer experience, and that was about all we had. We had not yet determined what the gameplay, objective, or visual style would be, but knew we wanted to forge something that would bring players together to achieve a shared goal. With this in mind, our first idea for gameplay was shared control of a ship.

Many people have heard of the games Artemis and Guns of Icarus Online, both of these games places a set number of players, 6 and 3 respectively, on teams to jointly crew a ship. Each player relies on the others to complete their objectives and perform their duties. If one player fails, the entire crew may fail. While these games provide players a strong sense of cooperation and urgency, Artemis fails to place players directly in the action, instead viewing it through 2D displays while Icarus players spend just as much time running around the ship in 1^st person as actually performing actions on or with it. We wanted liked the cooperative aspects of both, and created our first iteration based on a melding of these two ideas. Our players would take direct control of stations on a ship, providing 1^st person views from gunnery batteries as well as the helm to work together to control, navigate and protect the ship.

As we progressed with the idea of players jointly controlling a ship, we asked ourselves “Is every role fun and engaging to play? Would people be happy to be locked into a single role or should be allow variation in what each player can do?” What we came back with was a resounding “No” to the first and “Allow variation” to the second. With that in mind, we began developing ideas to allow players to do more than one thing and not be locked in a single role, thus we came up with the idea of drones. Drones would be a secondary mechanic for the gunners to use. Rather than having a dedicated mechanic making repairs to the ship, each gunner could choose to exchange their offensive potential for defensive. When controlling their drone, the gunner would be able to repair gunnery batteries on the hull of the ship, raise shield walls and perform other supportive actions to assist the ship and their team in non-offensive capacity.

With drones, we solved the “Being a gunner can get boring” issue, but had not touched the role of the helmsman. How could we make being in charge of navigation and moving the ship more fun and engaging for that player? After long discussion of the issues that faced being a helmsman, as well as taking a deeper look into the drone gameplay, we determined that we needed to make a dramatic change. With it determined that playing as a dedicated helmsman would likely get boring for a majority of players, we decided to remove the role. With that, we now had gunnery batteries on the hull and defensive drones for support. How would the ship move? The drones would be able to push it with a beam of some sort.

With this change, Push-It as it is now truly began. Multiple players working together to defend and push their broken hull of a ship through a maze of enemies to return “home.” Looking at where it was now, we questioned the need for the offensive batteries at all, and so we removed them. Players now all took control of their own drone, pushing their ship to safety while fighting off and avoiding enemies and dangers. Why complicate the gameplay with combat, though? Why not just make all the danger the players, and their ship, face come from the environment? Many games add combat mechanics “just because” without necessarily having a sound reason for them, thus we decided to remove them. They weren't needed, we decided, and testers agreed when we brought a combat-less build to QA with the only goal being to use your “push beam” to get an object from the start of the level, through various environmental puzzles and dangers, to the end of the level. We didn't impose a time limit or any other requirements, just “get there.” They loved it.

With the new change, however, we realized we just had an incredibly simple game, one that wasn't particularly innovative. It was fun to play, yes, because of the player interactions and the cooperation requirements, but not innovative. We also had the issue of being limited to 4 players on a single machine, using Xbox 360 controllers. Around the same time, I was working on a side project using mobile phones with gps to make a “hunger games” style hide and seek game. When I mentioned it to my group, we had a groundbreaking idea to “combine” the two. We would have players use their smart phones as controllers. It took only a few days to set up a system in which players could download an app to their android device and easily connect to the game through wifi giving them a virtual controller on the screen of their device. The versatility of smart phones has also provided us with the ability to make a range of control schemes, from a “twin-stick” scheme to a gyroscope based “tilt-to-move” scheme, with many more possibilities for additional schemes.

Push-It had now moved beyond something you might play in your living room with your family and friends to a game that could be played on nearly any screen anywhere, with little setup. It could be deployed in movie theaters before a screening or in a park or even on Time Square, the possibilities for deployment were endless because players could seamlessly drop in and out of the game without affecting the ability to complete the levels.

The process of reaching the point where we are now with Push-It has been extremely educational about the true process of game development. We started with just a simple idea of making a cooperative experience, we progressed through so many different iterations and ideas before we reached this point. In addition, although I only focused on the iterations that directly led to Push-It where it is today, we also had alternative ideas that we developed alongside the cooperative experience that also provided ideas for thing to do and not do in Push-It.

Production

Presentation

Last night we finally reached the pinnacle of the semester, the senior show. 14 teams brought forward all of their progress and achievements over the course of the semester to vie for one of the slots going forward to next semester.

We saw a wide range of games, and most of them looked great. A few of the more memorable for me were Sunbots, Phantom Mansion and Lucid Delusion, as well as our own game, BusyBots, of course.

Production

Stage 3: Proving Your Core Experience

As we progress in developing our game concept, we reach the point where we must flush out the aesthetics of our game. We have tossed around many different ideas for what our game will look like, ranging from ghosts in a haunted house to wizards pushing a dragon egg, from ants protecting larvae to fat princes, but none really seemed right, or quite fit. We finally fell upon the idea of Rube Goldberg machines as the backdrop of our game.

Using Rube Goldberg machines as the backdrop of our game opens up a wide range of possibilities for both level visuals and puzzle mechanics. Levers, balloons, and pulleys allow for many different interactions between various puzzle elements as well as means for the players to interact with the puzzles.