All posts by Austin Graham

“Tesla’s Legacy: Wireless Power”-Engineering Log 5

newCameraIf you have read Stephanie’s article about Kickstarter, then you already know how much Kickstarter has been on our minds, and so I have been focusing on rather large systems than individual buildings in preparation. fullCamSince last time, I have finally finished getting colony cams into the game. Right now the cameras can be placed and deleted from the UI, and there shouldn’t be anymore problems with that. I also took a bit of time to add some simple icons to the camera panels for ease of access. The icons are as follows: center game camera on this camera’s location, move the camera to a new location, delete the camera. The delete button is the only button that works for the moment.

Green particles indicate a valid position for the tower.

In addition to the colony cams, I was able to implement a new system: power. With Katey’s power plants operational, players can now build wireless power towers (wouldn’t Tesla be proud) that send power to a certain area. powerThese power towers can only be placed next to a power plant so to help players find the location. I added a smaller particle effect around the power plant that only shows up when placing power towers. Also the visual for the power area (a yellow ring of particles) only shows up when constructing or selecting a tower so as to minimize clutter in the world. Several buildings, such as luxury housing and colony cams, require power to be built, and to get Katey’s Luxury House (aka the Shark House) built, a player must provide power.

As if getting power and the colony cam systems weren’t enough, I have also been working on a log in screen that will eventually pull data from a server to give access to a player’s colony. For the time being, we are working with an offline version. Below is the scene used for the log in screen.It is a deceptively soothing scene before the player is thrown into the chaos of managing a colony.

logInView

Currently I have the game switching back and forth from scene to scene. I am looking into what it would take to save information and what all needs to be included and what can be loaded later from data stored. Finally, I have created development builds for the team so that everyone has a working copy of the current project to play with.

We have 7 days left before Kickstarter! It’s getting crazy around the office, and we are hard at work getting everything together.

Past Engineering Logs:
Engineering Log 1
Engineering Log 2
Engineering Log 3
Engineering Log 4

“I Always Feel Like Somebody’s Watching Me”-Engineering Log 4

geico-kash

So who heard this song before Geico used it for their commercials?

Ok, enough of that. The end of this post will cover the feeling of being watched. Recently, Katey took her rather simple concept for a power plant and transformed it into a much more modern and interesting look. Once that was done, I took it into Unity and gave it steam billowing from its main tower and the ability to now add onto the power potential of colonies. One of the cool things about the building is to watch it be constructed and then start releasing steam once it is fully operational. The next task in regards to power is the creation of the wireless power tower (courtesy of Nikola Tesla and Katey) that sends out pulses of electricity and provides power to all buildings within its reach.

icons
Notice anything familiar about some of these icons?

In addition to new buildings, Katey has been hard at work creating new menu graphics for the UI, with some input from me. These new icons are more unified in appearance and still give the impression of what they mean (plus we left the words underneath if there is any confusion). The UI has come quite a long way from where it once was, as discussed in my last blog post.

On a similar note, I have been working to get our game utilizing the event system to manage click events. Before, if a user selected an object and then tried to use the interface, unexpected results would occur as both the click event for the UI was triggered as well as the code to check for a mouse click for the object. The goal is to hook game objects into the event system since it has a built-in way to detect and handle multiple events. This will prevent some of the unexpected results seen in some of our videos and streams. The change to using this system is taking a little bit of time to try and figure out how to convert all of the necessary methods, but it will pay off in the end.

Lastly, we are excited to begin work on a feature we think will be very interesting for players to take advantage of: Colony Cams and Colony TV. The colony cams are individual cameras/objects that are placed by the player to give unique views of their colony. menuIconsThe plan will be that these can then be hooked into channels on “Colony TV” (a website for the game) where other people can get a glimpse at the goings-on of your colony. We will limit the number of cameras a player can have at one time, but players can change camera locations at any time, and potentially even keep some around their colony to act as outposts to keep an eye out for… ah, you’ll find out later. The point is, these cameras will provide an interesting mechanic for players to take advantage of, and we are excited to start working on them.

On Friday, I was able to get two Colony Cams in place and begin work on the UI system for our cameras. Right now, a player is limited to eight camera which they can move or delete at their discretion. Unlike normal buildings, that must be built by units and can have many commands, the cameras will be managed, placed, and edited through the UI system set aside for this purpose and are simply dropped into existence. They will, however, take up space and need to be navigated around, so keep that in mind when setting up your cameras! Once I have finished hooking everything into the UI, and most likely after Kickstarter, we will be looking into getting a site set up for colony cams to be displayed. So then you can really ask “Who’s watching me?” Here is a screenshot of the UI I have so far:
CamSmall

That about wraps it up for this blog post. Check out the other Engineering Logs and stay tuned for future blog posts from us here at Reactuate Games!

Next Engineering Log:
Engineering Log 5

Previous Logs:
Engineering Log 1

Engineering Log 2
Engineering Log 3

 

“Tea, Earl Grey, Hot”-Engineering Log 3

Wouldn’t it be awesome if you could just tell the computer to make something and have it done (also food replicators would be cool too)? How the user interacts with the computer and/or game has a dramatic influence on the overall experience. While our user interface (UI) won’t be voice activated like the computer from Star Trek, we are working to make it easy to understand and accomplish tasks without a lot of hassle.

oldUI
placeholder UI from older method

That being said, let me go back several weeks ago to talk about the beginning of our UI system. Those of you who remember (or have read my past blog posts) will know how I ran into some issues in the organization of code early in development. Luckily, I found a tutorial to help me get my bearings and better organize our code. There was just one problem with this tutorial: it was written for Unity 4.1. We are using Unity 5.1.1 and a lot of changes have been made, especially to the UI system. The UI the tutorial used was the outdated way of doing user interfaces. So while I worked on some other mechanical things, Ron started working on our new User Interface. The biggest inspiration for our design came from Jurassic World‘s website. Ron thought that having the ability to dismiss certain elements but still having easy access to them was a nice idea. So Ron got to work animating and creating placeholder UI elements.

newUI
New UI with placeholder graphics

Here is where I come back into the picture. Now that the placeholders are set up, it has been my job to link the functionality that has already been coded from the old UI into our new interface. It’s actually kind of weird to get it to work since now I have to go find all of the elements to change. I have been working to make things as efficient as possible and only update when needed. With some basic functionality now tied into the new UI, our Digital Artist, Katey Bluel, will be working on creating amazing graphics and symbols for the UI, and I will begin work on creating some of the more in-depth UI elements, such as a pop-up command window and in-depth unit/building stats page.

In addition to the blog posts on the site, Katey and I have started individual stream series on Twitch that appear throughout the day where we show you what it is we are doing and you can watch the development of the game in real time, make comments, and ask questions. Also, don’t forget to follow us on Twitter and subscribe to our YouTube channel, as well as our email list here on the site. We are now 41 days away from the start of our Kickstarter, and the game is moving along quite nicely.

Engineering Log Supplemental: 7-27-2015

details
UI with pop-out details window
command
The Command Center’s detail view.

A lot can happen in just a few days, and instead of another short blog, I will be adding onto my last UI blog. Last week, I was able to get a pop up window of detailed information and commands to show up. The idea is to give the user a great deal of information in a nice and neat little area. Here the user will have access to different commands, various progress updates, and other miscellaneous information about buildings and units. This is only brought up when desired from a flag above the selected object. The graphics are still all placeholders until our artist has a chance to sit down and switch from modeling to 2D art. Now that most of the UI framework has been set up, I will be adding a few small additions here and there and continue working on the missions for our “Simplest Path to Portal” Epic.  The end of this week will mean we only have one month left before Kickstarter, and we are all working like crazy to get content out before then. We’re giving it all we got!

P.S. I tried Earl Grey tea last week for the first time! It was great.

Next Engineering Log:
Engineering Log 4

Previous Engineering Logs:
Engineering Log 1
Engineering Log 2

“Portals and Particles”- Engineering Log 2

Read Engineering Log 1 if you missed the first post detailing our first few weeks and the struggles we faced early on.

So how does one travel across the universe when warp speed isn’t fast enough or even an option? A Starga… I mean portal, of course. Call it what you will, but there is no faster way to travel than simply stepping in on one side and stepping out on the other halfway across the galaxy! This is your first main goal as colony manager: build a portal. That’s easier said than done, and it is our goal to be able to show you just how to do that in the next coming months.

We have been working hard here at Reactuate Games moving along with the game. The Epic (i.e., a large collection of tasks) we are focusing on for our Kickstarter event this fall is called “Simplest Path to Portal.” In other words, these are the mechanics that are essential for the user to land his or her colony ship and eventually construct a portal to bring colonists to the newly found colony. All information about portals and colonists is restricted to personnel with Level 3 Security Clearance (i.e., anyone signed up for the Reactuate Games newsletter) or higher.

ghostBuilding
Ghost Building

One of our past milestones has been to get building construction up and running. There are some slight alterations that can be done in the future as extra things to make users happy (you’re welcome future players), but the core mechanic is in place. We have “ghost” buildings as a means to help the user find the perfect location for the building (with the color green meaning it is a valid location and red meaning it is an invalid location). Once construction begins, the building slowly rises from the ground until it is fully constructed. Additionally, when two or more builder units work on a building, the building is constructed faster. In contrast, if all of the builder units are destroyed or leave, then construction is paused and the building remains unusable until it is complete.

particles
Simple particles around a building

Just before our three day weekend for the Fourth of July, I began looking at particles and experimenting with them in different places and uses. Particles are a very interesting system in Unity, so I took the time during our short week to experiment and familiarize myself with particles. It was actually a lot of fun playing with the settings to see what different kinds of effects I could get from simple particles.  If we are going to have a science fiction, futuristic game, having good particle effects are pretty important. I’ll revisit particles in another Engineering Log once we have more fleshed out particle systems and effects.

While I was working on game mechanics, Ron generated our alien landscape. As we are moving our project to integrate this larger terrain, I have also been working on our navigation system to keep units moving smoothly over the rough terrain. We are still working on how to do our pathfinding to keep our units moving along the terrain. I will continue with pathfinding, optimizing our code, and simplifying  the interactions between units and buildings over these next few weeks.

PurpleLand
The New World: “The Purple Land”

This past week we have been creating “missions” that will guide new players to the point of witnessing the power of their fully operation battle statio… I mean portal. I am hard at work getting these basic missions set up in our new environment. The first of these missions is to have the colony ship land and “beam” down units and allow them to carry out orders. Now that I have probably ruffled enough feathers by referring to Star Trek, Star Wars, and Stargate all in one post, I will end this Engineering Log.

Next Log:
Engineering Log 3

 

 

“Heigh-Ho! A lot of Work to Go!”- Engineering Log 1

Begin Engineering Log 1…

Take a moment to get the song out of your head. I’ll wait.


Now then, before continuing, picture this: You are starting a voyage on the open seas, and you must guide the ship without modern technology. Now imagine that your charts and maps you use to navigate are drastically outdated, or even entirely useless.

So what does that have anything to do with our company and game? We are venturing into uncharted waters, creating a game that is not like anything else, and my job as Code Artist is to bring elements the others create and combine them into a working game. With these development blog posts, I invite you to follow along as I document our struggles, triumphs, and process we go through to make this game a reality. Our ship is guided from the Command Center,  but the heart of the game is maintained in Engineering.

mineralDeposit
Mineral Deposit and Miner Unit

Now then, let’s get on with the game talk. That is why you’re here after all. When work started at the beginning of June I had no references and only a vague idea of what kind of game we were going for. I knew certain elements needed to be in place and so worked on those. My job involves the actual programming of the game, but I actually do much more than that. In addition to the actual programming, I have been working with our two artists to bounce ideas around and integrate their creations into Unity
and the project. Those who have been following our Scrum meetings may recall the little snag we hit in week three and four when the organizational structure of the game came into question. For a mix of reasons including lack of references, new programming methods, and others, we had to rethink our approach. Thankfully, at the end of week four I found a wonderful tutorial that outlined a very basic structure for a Real Time Strategy (RTS) game, which our game pulls heavily from. Instead of combining and creating the more advanced sections of code from the beginning like we tried to do before, this new outline followed the same way the game would be played: the player would start with a building that created units and then later new units could create new buildings. There was just one tiny hurdle to overcome: the tutorial was written for Unity 4.1.

Since the structure was still sound I decided to adopt it as a rough outline for our game and integrate our systems with the structure, updating pieces when necessary. MinerVariablesNow, at the end of week five, we have working buildings, units, and resources. The next step is to have units create new buildings. I have two things to say to others in similar positions to my own: never underestimate good code and become able to adapt to less than ideal conditions. Even though the code example is from a much older version of unity, the underlying structure is still viable. Also, I have had to constantly adapt the code and my thought process in order to overcome the various challenges faced thus far.

This week I have been hard at work getting the resource collection code done, and I am proud to say that finally our mineral deposits can be harvested by the miner units made by our artist Katey Bluel and deposit them at the nearest holding facility. A while back, Katey made many of the different shards, and we collaborated on how they might be used in the environment. After creating the crystal cluster-like deposits, we moved them in game and got to work on the unit to mine them and the code to accomplish the task. Now, our miners are able to collect resources. This is just the first step, as much more work is to follow, including animations. Now that we can collect resources, the next step is to have units create buildings using those resources, but that is a topic for another day.

Keep a look out for future Engineering Logs! If you have any questions about the game and want  to learn more, keep checking out our website and follow us on social media and let us know!

End Log.

Read Engineering Blog 2 HERE.