next »

[stopthief]

Now on Steam!
https://store.steampowered.com/app/553560/The_Maestros/

The Maestros is an online multiplayer RTS (real-time strategy) game set in a humorous fantasy world where you control a commander and his squadron of wildy cuddly and mildly vicious minions. You can play as either the dieselpunk Knights of Teutonia with their clunky, transforming robots or as the futuristic Alchemists of Regalis with their adorable, mutating monsters.

You amass minions by killing monster NPCs around the map.                  Then you can transform them at points around the map.

                 

When you’re all ready to fight, go in there and take out the enemy’s commander!

But what does it all mean?
Basically, The Maestros is what happens when an FPS momma adopts a weeee little RTS baby and raises it as if it were its own child.  You are absolutely controlling a fast-paced, top-down strategy game à la Starcraft, but sometimes you end up with moments like this

And you end up camping the Rocket (Turtle) spawn so you can do this

When is it going to be released?
Soon...  I hope.  But maybe not that soon.  Given the scope of this game and the limited amount of time we have to commit to it, it’s tough to say.  We are definitely approaching some kind of “milestone,” and I feel confident in saying you’ll get to flirt with, fondle, and otherwise become intimately familiar with some iteration of The Maestros before the year is out. So there!

It looks like a lot of time has gone into The Maestros.  What’s the story here?
Oh, why thank you for noticing, *bats eyelashes*  But in all seriousness, this game has been an enormous labor of love for myself and several others for a while now.  Ideas for a zero ramp-up, hyper-mobile RTS had been bumping around in my head for years as a core RTS gamer, and the game was majorly inspired by Warcraft 3, and elements of MOBAs as well. The Maestros began life as a student project at the University of Southern California. From about Sept. 2013 to May 2014, the core of what you see here was built by a team of students and hobbyists all pitching in what we could and building a fun "first alpha" that we eventually put in front of people.  At the conclusion of the class, most of our core team graduated from their various schools and/or went on to get jobs.  We had such a blast making it though, that a handful of us kept plugging away after work every week, hoping some day we could get a finalized version of the game in front of people’s faces with all the awesome stuff we had envisioned.  After about a year of that, we think we’re honing in on the next iteration that we can show off so we’ve started lifting the covers off of our development and the game itself.

How Do I Keep Up with the Game?
We intend to keep this DevLog up to date here and on Tumblr so you’ll be hearing from various members of the team on here.  In addition, you can watch our weekly playtests on our twitch channel on Monday nights ~8:30pm PST.

Web Site | Facebook | Twitter | Twitch | IndieDB | Tumblr

You can get it on Steam too.
https://store.steampowered.com/app/553560/The_Maestros/

I'll leave you with a trailer

[grumbles]

Seems like something interesting.

Looking forward to more updates !

[DrunkDevs]

Seams like a cool concept. I look forward to trying it out.

[stopthief]

Thanks guys!  We will probably do a design update in the next few weeks, and we're hoping to have something you can try out soon!

[cipher]

The Maestros - Devlog 02 - Sunset Isle Map Creation


Introduction & Conception
Hello readers, my name is Alex, and I am the lead level designer on The Maestros, and I’m going to talk about my personal map creation process for our newest battleground, Sunset Isle.

When starting any new map, there are countless things to consider. How will this design compliment our gameplay? Does it stay true to our design goals? What would make this map different from the others? Our gameplay is what it is, and the map needs to be designed to play off the strengths already in place. I am constantly asking myself throughout the process, “what aspects of gameplay are covered by our other maps, and how can this one achieve something new?” I’m always examining the floor plan, map’s footprint from various distances, and more, in order to really answer this question.

Defining The Design Goals
While all my maps begin as various sketches, laying out the goals I want to achieve is a secret to success. As in, physically writing them down, not just having these ideas in my head. Even a small paragraph of text is a powerful guide and reference. As I made my initial designs, these are what would become Sunset Isle’s core design goals.

Size
I wanted this map to be middle ranged in size. In The Maestros, each level is designed with an ideal team size, but should still be appropriate for teams of plus or minus one member. Sunset Isle thus is created for 3v3 and 2v2, but remains smaller overall than other 3v3 maps.

Map Feel & Spacing
Most of our maps make heavy use of blocked areas to grant players large amounts of space for vision-based play. I designed Sunset Isle with the opposite in mind, granting players more space to move, but still including corners and blocked areas for special maneuvers. Too much space can be disorienting however, so finding the right balance is important.

Transform Point & Neutral Spawn Zones
Typically in most of our maps, these two gameplay elements are positioned based on expected gameplay flow; where we expect players to be at certain points in a match. With this map, due to its open nature, I wanted to do the opposite; use these elements to control the flow itself. Thus, I placed the transform points around 's the map's central axis, while neutral units closer to and on the outskirts. By placing the Dreadbeast, the tamable super unit, and the Shrine, the score-altering objective, on opposite ends, players will have to make important decisions on where they want to focus their combat efforts.

Gameplay Flow
Gameplay flow is the one thing that unites the former design goals, and the most important. If I poorly utilize the above elements, gameplay can become sloppy. Lack of engagement, players unable to find each other, and so forth.

My (Personal) Creation & Documentation Process
With all these in place, I made many map sketches and designs that could fulfill my goals. While ultimately I would settle on one, even failed designs may have something to offer future maps. Save those sketches!

Personally, I like to bring my final paper designs into Illustrator, and recreate them there to be paired the the full design document I’ll be making next. I create images that illustrate specific things, such as transform point and neutral locations, gameplay flow, and even images that outline potential problems (and perhaps fixes), all to compliment the new design document.

I always review my work and try to bring out any potential flaws to discuss with the team. Sometimes team members with little design experience may have the perfect solution to a problem! As an example, here are two problems I saw with initial Sunset Isle map designs:
  -Map areas (particularly the south) being neglected.
  -Gameplay turning into a merry-go-round of players not finding each other.

Art Direction & How It Can Affect Gameplay
Due to the small size of our team, I had to be careful with what I wanted, knowing that new asset creation was limited. Aware of what I had from the start, I wanted this new map to be an island with pretty lighting. A design and color palette that would stand out. While my initial vision was simple, I was fortunate to get more assets than expected, and was able to create an extra good looking environment.

Art direction and asset placement can do much more than make the environment pretty. Landmark assets can help players differentiate and recognize areas, painted terrain can help guide movement, and much more. I used this simple design fundamental, as with all our maps, to smooth any map-related hiccups in gameplay. As a simple example, literal paths in the terrain help guide players to important areas.

Lastly, I’d like to address an unexpected problem that I encountered in this map. With the combined efforts of the the lighting, color palette, and “soft” art style, it was difficult to discern where the island begins to dip off into the water. It was unclear where the maps boundaries were. I tried solutions like additional terrain textures (wet sand), but it was too subtle. Nobody likes invisible walls in games, but with asset placement, the problem was made much less severe. A simple fix to a more complicated problem.

Conclusion
Sunset Isle is a map far younger than any of our others, and is of course still in need of more testing. Hopefully, you, the person who cared to read this in its entirety (I thank you), will get the chance to give it a try sometime soon. Did I succeed in my goals? Hopefully you’ll be able to tell me!

See you in-game!

[cipher]

The Maestros Public Alpha Starts July 11th!

Starting Saturday, July 11th at noon PST, The Maestros will be available in an Alpha (pre-beta) state for your auditory, visual, and kinesthetic pleasure.  The game will be completely free during the ~3 weeks that it is live, after which time, we’ll shut it down, bring it back into the workshop, and work to make an even better game based on the feedback we receive.

What's the Maestros?
The Maestros is a new-fangled RTS (Real Time Strategy) game built by some dudes who decided they’d grown quite weary of watching the underpaid workers of various fictional universes ferry raw materials back and forth to an unidentifiable structure, and they’d really rather get on with smashing awesome robots against genetically modified creatures in an unceremonious battle of wits and skill.

Want to know more? Check out some of the posts earlier in this thread, or come check out or blog!
http://blog.maestrosgame.com/post/119137474763/first-devlog

Or check out our trailer here!




Whatever will Happen Next?
During the Public Alpha we’ll be running various events with our friends in the gaming community.  Expect things like guest-star streams, play sessions with the devs, and maybe some in-game competitions   If you’re interested in partnering up with us for events like that (e.g. you’re a hardcore RTS gamer & streamer; you write game reviews; etc.) please shoot us a line directly: [email protected]

Why Limited Time?
A valid question for sure. We’d love for you to play from now until launch, but it turns out that running a live service actually takes some work.  On the tech side, servers are among the most haunted technology in the modern age, requiring 24/7 anti-poltergeist patrols.  From a game design perspective, we find that at this stage, our feedback around a given version of the game quickly starts to look similar, and with only a few developers, we’d rather spend time addressing your feedback before we give you a released product than chasing down misconfigured servers.

Important Dates
Sat, July 11th at 12:00pm PST - Game goes live here: http://maestrosgame.com/download/
-- more awesome events TBD --
Sun, Aug 2nd at 11:59pm PST - Public Alpha Ends

[maestros_stumpy]

The Maestros - Devlog 03: How to Make a Unit

Hi everyone! My name is Taylor, and I'm one of the engineers on The Maestros, a fast-paced team RTS game. We're excited to be in a brief open alpha period! Come download our game and play with us for free: http://www.maestrosgame.com/download.html

Today I wanted to talk about how we design and create new units (characters you control) in our game.



What's an RTS game without cool units? We spent a lot of time creating a flexible system that allows us to create, change, and test units in our game. This short overview gives a step by step guide for how a unit is made. Given I'm on the engineering team, this will definitely be more technically skewed, but we will have a designer's version of "How to Make a Unit" and an artist's version coming soon.


Step 1: Design & Art
Our units start out as ideas:

"Let's make a big tanky unit": The Juggernaut


"What would a long range unit look like?": The Aimbot


Usually these ideas come from the design team but anyone on the team is free to input their ideas. Once we have a cool design we work with artists to help envision the lore of the unit. Our concept art for the Juggernaut shows a big, hulking metal robot. "What should his ability be?" "Uhhh how about he rushes in and throws enemy units in the air?". Makes sense! Or we start with a cool ability idea then create the unit afterwards. Either way, we will always involve an artist to create some initial concept art.

Step 2: Components & Data
After we have our initial design, we need to get the unit into code. A unit in code is comprised of multiple "components". Let's look at the Doughboy, our base unit in the game.

Doughboy


He has an attack component which enables him to attack enemies. His movement component allows him to run around the map. And his animation component handles playing animations. Every unit in our game has these components and are differentiated by their data. For example the Doughboy's attack damage is much lower than the Aimbot's damage. A unit's functionality is determined by his components and the values assigned to the components. The unit's designer sets his initial unit component values.

A unit's initial component values are never final and take many iterations to get right. Our designers are constantly tweaking numbers to ensure playing the game is both fun and balanced. To store each unit's attributes we use JSON files. A JSON file is a data file containing a list of key-value pairs. When the game is started up, each unit will check his corresponding JSON file to create his components. A unit would look in his JSON for "speed" to assign his movement speed in the move component. We use a tool one of our engineers built to create and edit JSON files.

JSON Tool


This is what a unit's attack component looks like in our tool. A designer can edit values such as "damage" which will be read by the unit when the game runs. This tool allows our designers to edit units without having to mess with code.

Step 3: The Ability Component
The final component that our new unit is missing is an ability! This component takes an entire step because we can't reuse the same ability component on every unit. The Euler's Sploosh ability component is wildly different from the Conductor's electric shock ability. The ability component requires an engineer on the team to code new functionality for a unit. Of course some re-use of code occurs between abilities, but often most of the functionality requires new behavior to be programmed and tested.

Let's look at the Euler.


His ability should function as "throw a tar ball at a location, when it hits it slowly spreads out and slows enemies."

Sploosh Ability


An engineer would come in and code what it takes to throw the projectile and slow enemies. But afterwards there is some missing data. How far can he throw the tar ball? How much does it slow by? What is the radius of the tar? These values are once again pulled from JSON. By using our data driven system here as well, designers can make balance changes frequently.

Step 4: Balancing
Our final step is on-going. Once a unit has been tested and is ready for play, designers can begin tweaking a units numbers. Because of our JSON data system, it is easy for designers to change almost anything about a unit. We can boost the damage of an ability or even change how quickly a unit's health regenerates. Also in this final step artists may revisit the unit to give it some finishing touches.




Closing
This was just a brief overview of how we make units in the Maestros. We're looking forward to releasing new units soon. See you in the alpha!

Best,
Taylor

[Impmaster]

The game looks pretty interesting, I don't think I've ever seen an online multiplayer RTS on these forums. However, I hate your UI. I think it looks a little too... flat? I dunno, but I dislike it. I think it definitely needs a bit of color contrast with the background.

Anyways, I wish you best of luck, we need more indie games that aren't platformers!

[maestros_stumpy]

Thanks for your feedback!

We plan on revisiting/redoing the UI after the alpha. We have already begun going over redesigns but decided it would be best to make sure the game is working for our alpha

Thanks again,
-Taylor
Programmer on The Maestros

[FGRaptor]

This looks like good fun. It certainly reminds me of the days of Warcraft 3 custom maps - and I love it. I am very much looking forward to this.

[stopthief]

The Maestros is looking for talent!

We're currently looking for Gameplay & Back-end engineers who are interested in helping us ship this game!

The game is being developed by a small team spread out all over the world looking to build their portfolios and ship an exciting, competitive game.  As such, everybody is working on volunteer basis.  After some successful public trials, we’re hoping to make The Maestros available next year *fingers crossed*

On the gameplay side, we’re adding Bot-AI, character abilities, and new game modes.  The codebase is all in UDK’s UnrealScript (reads like Java/C).

Our back-end services are all written in Node.js and running on Azure.  We’ll be fleshing out & stress-testing services like Player Accounts, Game Servers, & Steam Integration before launch.

Commitment is about 8 hours a week, all online.  Interest & programming experience required!

If any of that strikes your fancy, send me a resume directly at [email protected]

[Mirx]

Hello everyone!

My name is Michael, and I am the Lead Environment Artist on The Maestros, a high action team-based RTS game. You can visit www.maestrosgame.com for more details.

Today I am going to walk you through my process of creating an environment asset from Concept to Final Product that is to be used in The Maestros.

Step 1: Concept
Here is a drawing of a large arkanium crystal surrounded by a wooden fence. This asset is meant to be a major landmark in the center of our 1v1 map, Fissure. Alex, our Lead Designer, is involved with this step to make sure the asset follows certain constraints and is a good fit aesthetically.


Step 2: 3D Modeling
Once the concept is approved, I can start modeling the asset. There are a few things I always keep in mind during this step to help push the asset to its full potential and to help make things easier for myself down the pipeline.

- Silhouette
By applying a black shader, without any lighting, I can see the asset's silhouette. Using this technique I can see how interesting the overall shape is on its own. The camera in The Maestros is in a Top Down view so we need our assets to be readable before we even apply textures to them. I can also see how stylized the overall shape is and can push the shape into a more or less of a “cartoon” direction.

- Optimization
This is really important. If all of our assets exceeded their polygon count and texture size set out from our engineers, the game would run slow and ruin the player’s experience. Everyone on the team works towards a perfect balance of quality vs performance.

Polygon Count is something I always watch for. I want to get the polygon count as low as I possibly can without changing the silhouette. One technique that I use is to remove unseen faces. The camera in The Maestros is in a fixed position. The faces that will never be seen, usually the bottom and back, can be deleted. Not only does it save in polygons, it helps make UV Mapping much easier later on.


Step 3: Texturing
Here are the steps I follow while texturing assets for The Maestros.

• UV Mapping - Pixels are precious! I try to unwrap the model using as much uv space as possible. I overlap any sections that are being duplicated to help increase uv space
• Base Prep - This is where I assign flat colours to sections of the asset. I also overlay any bakes I have to help boost the overall look.
• Details - This step is where the magic happens. I paint in all of the details to make the model come to life.
  
• Other Maps - Normal, Specular, and Gloss maps are made from the final texture.

Note: I turn off any lighting to better see the texture

Step 4: Final Product
Here we see the final product inside the game. I created a custom material that uses the environment to make the arkanium reflective and glossy.



Closing
We have many maps with many different types of colourful terrain and unique pieces like this for you to see. I hope you enjoyed reading and maybe learned a thing or two about the art used in The Maestros. Thank you and be sure to look for our next Dev Log in the future.

[Impmaster]

It's weird I saw you guys irl at USC like a month ago

[stopthief]

Haha, that was really cool to see you there, Impmaster.  I think that was the first time I had encountered somebody IRL who had heard about the game online first  Hope you had a chance to enjoy it at the event!

[stopthief]

Hi everyone!

My name is Min, and I am the Producer on The Maestros, a fast-paced RTS game where you wage war with cute adorable monsters and robots capable of transforming into harbingers of death, destruction, and doom.

This time around, we’ll explore a bit about how the aforementioned were organized in our production pipeline. In this blog post, I will be diving into the production of the game -- more specifically, how our approach shifted when the team went from a large student team to a small group of part-time developers. To start off, some backstory…

A Long Time Ago On A Campus Far, Far Away

Okay. Actually, it was just a year and a half ago in May 2014 at the University of Southern California in Los Angeles… where we presented our game in a large auditorium full of parents, professors, friends, industry professionals, and other student developers. This was the final assignment for the game as a yearlong student project -- a very big student project consisting of an international team of soon-to-be-professional hobbyists. Here’s a family photo of just some of our beautiful faces



We had a large team and a lot of work to do within a year. There were roughly 1,500 man-hour worth of tasks every month, from an average team size of 48 people working about 8 hours a week over the span of a 4-week long sprint. Layered on top were college students’ time and budget (or the lack thereof) so we had to get creative with how we tracked tasks from sprint to sprint. There were a few free online tools but, for the most part, they were limiting. We needed something simple yet elegant and effective…

SimYEE

Allow me to introduce you to SimYEE - the Simple Yet Elegant and Effective solution to your video game producing needs. Built in the super modern Google Spreadsheet engine, it is indeed simple to use. You can view a sample of the task board here.

• Plan. We determine which goals to complete for the sprint and list out the tasks that make up those goals.
• Assign. Tasks are assigned to the team and each task is assigned a certain number of story points (SP), following the fibonacci sequence. SP indicates the relative size of a task.
• Lookup. It would have been utter chaos for everyone to look at a giant laundry list of everyone else’s tasks with 50 concurrent users. Separate sheets are built in where team members can look at just their tasks.
• Track. Once a task is in SimYEE, it is the assignee’s responsibility to keep the status of the track updated. The lifecycle of a task is as follows: open → in-progress → complete → verified.
• Clean Up. At the end of each sprint, the verified tasks are archived and tasks for the new sprint are added to SimYEE to continue the circle of life.

From a bird’s eye view, production was very simple. But nothing ever really goes according to plan. Tasks were often discovered and would be added to the task board midway through the sprints. Sometimes, team members left because they got awesome opportunities to work on game teams that paid in more than pizza and soda.

But I think the biggest challenge was due to the nature of the genre we were developing for. Our game didn’t follow a linear timeline. Designing an RTS was extremely fragile -- add one unit in one sprint, revisit the others the next. This called for constant ideation, iteration, and rebalancing. This topsy turvy juggling act spanned throughout most of production until our presentation for class concluded in May 2014, at which point most of the team graduated and went to work in the industry. A handful stuck around to continue development part-time.

Downsized Development

It was only about 6 months ago (about a year after USC) that we tangibly changed our approach to sprint planning and task management. A 9-person team means that each team member essentially owns his department (e.g. gameplay engineering, design, 3D art, servers, etc.). SimYEE was also simplified to reflect the smaller team: the many tabs from before are consolidated into a single sheet. You can view a sample of the new task board here.



On the flip side, a smaller labor force means a much slower development. Now, every task counts (not that they didn’t before). To streamline our planning, we broke our goals down into something we call “stories”. Stories have a who, a what, and a why.

• Who is going to ultimately benefit from us completing the story?
• What actually needs to be done so that the aforementioned “who” benefits?
• Why the hell do we even need to do this? So what?

For example, a story would read like this:

“As a player, the Blastmeister’s ability is sufficiently strong so that I don’t get rekt by the Tinkermeister.”

In this case, the player is the who. The Blastmeister’s ability being stronger than it is in the current meta is the what. Not getting demolished by the Tinkermeister when I playing as the Blastmeister is the why. Essentially, something needs to be rebalanced.

When we are ready to take on a story, we break it apart into individual tasks (which are then tossed into SimYEE, of course). The story above might be broken down like so:

• Design - Increase the Blastmeister’s ability’s blast zone and damage.
• Engineering - Implement a recoil on the Blastmeister unit casting the ability, pushing her away from the target.
• Art - Make the blast visually bigger.

Breaking down the features we want into stories like this and their subsequent tasks keeps our goals measurable and relevant. Plus, it keeps our sanity in check. As of the writing of this blog post, we have 61 stories left to tackle, which is a lot more manageable than the 400+ individual tasks that we kept in our backlog before. As we continue to chip away every sprint, The Maestros gets closer and closer to the fun and polished game that we all dreamed it would be.

But it’s not done yet, and we could use a little bit more elbow grease and know-how to move things along. We are always looking for more RTS fans to join our humble team. If our game (or production methodology!) piqued your interest, be sure to drop us an email at [email protected].

[stopthief]

Making an RTS in Unreal Engine - Part 1: A Survey of Game Network Models
(Skip to Part 2 for our choice & implementation)

My name is Dru, and I’m one of the guys working to bring The Maestros to you fine folks. If you’re not in the know, The Maestros is a team-based RTS game that allows you to transform your units on the fly. Recently, we’ve talked about how we produce the game, and how we make environment art, but today we’re going to nerd out on some tech. Specifically, how networked multiplayer works in The Maestros.

Networking in Unreal

As you might guess, Unreal Engine (both 3 & 4) is structured around the core elements needed to build Unreal Tournament (though I’m sure their marketing department would contest me on that one). As a result, it makes a few assumptions in things like it’s default networking model. The Unreal Engine’s default network model is a client-server model that shares many core elements with the The TRIBES Engine Networking Model. This is still the white paper on writing networked multiplayer games, so if you’re making your first multiplayer game, I highly recommend reading it.


It works like this: players send commands to a central server who makes authoritative decisions on the state of the game and publishes it to the players at frequent intervals. It excels at providing up-to-the-millisecond info on all the players in the world through through high-frequency (>=20/second) messages about everybody status, and some prediction to fill the gaps. The longer you wait between messages, either due to tick-rate or latency, the more likely it is that prediction is wrong. You might have moved left instead of continuing straight in that time, and then the server has to correct your client. This is where “rubber-banding” comes from.

Server Update Rate of 10/s on Maestros - note the hitching/rubber-banding


Server Update Rate of 30/s on Maestros - pretty smooth



This is why you don’t want to play Halo from New York with somebody in Hong Kong, for instance. Somebody is going to have a bad time.

Where the Unreal (or Tribes) model starts to break down is when the number of characters starts to get really large because the amount of data you need to send starts to exceed what a common player’s internet connection can reliably transfer. Because of this, many classic RTS games with hundreds of units like, Starcraft, Age of Empires, Warcraft, Total Annihilation, etc. take a different approach.

Networking in Classic RTS Games

Instead of one authoritative server, these classic RTS games use a peer-to-peer model where every player sends their commands to every other player. In some ways, this is really cool - you don’t need any dedicated servers because the player’s computers make up the game. Unfortunately, player’s computers can vary widely in power and connection speed, and without a central authority, they all need to operate at the same pace. This means the player with the worst latency to any other player, dictates the game’s responsiveness for every other player.


In peer-to-peer, players will also be initiating connections directly to one another, something that home firewalls are specifically built to stop. In this situation, workarounds like port forwarding or NAT punchthrough become necessary. If you’ve ever played Starcraft: Brood War and you couldn’t join a friend’s lobby, so you made your own lobby, had them try to join, and then had that friend host again you were essentially performing a manual NAT punchthrough. These days, Age of Empires II HD uses a proxy to resolve this problem, but that also increases latency.

As you can see in the model above, only commands are ever sent over the wire, no game states. In this peer to peer model, the game state is maintained by simulating the game identically across every machine i.e. it must have determinism. This model for multiplayer games is known as Deterministic Lockstep, and is described beautifully in 1500 Archers on a 28.8: Network Programming in Age of Empires and Beyond.

In Deterministic Lockstep, players have to execute every other player’s commands at the same point in the simulation on every machine or else the simulations will start to diverge. This means every client has to wait until they have the commands from every other client in order to execute them - talk about input lag. Fortunately for Real Time Strategy games, issuing a command and then having a unit execute it tens or even a couple hundred milliseconds later doesn’t break the game feel, because it’s an indirect action. You aren’t your marine, and your brain makes sense of the fact that it’ll take a moment for him to react to your order. In Unreal Tournament however, you ARE your character, and it would feel completely broken if you took 200ms to react to you dodging left.

[stopthief]

Making an RTS in Unreal Engine - Part 2: How We Built It
(Step back to Part 1 for an overview of the network models we assessed)

Choosing a Network Model

It turns out that determinism (and deterministic lockstep) is quite an endeavour - on PC you’re dealing with effectively infinite hardware profiles and nondeterministic behavior shows up in the darnedest places - virtual machines for certain languages, differing compilers, it might even come up in floating point numbers. To make things worse as an independent UDK developer, we don’t have access to change the underlying engine code in Unreal 3. All in all, we ran too high a risk of running into non-deterministic behavior that we simply could not overcome.

This left us with the traditional Tribes/Unreal model with high bandwidth requirements. In an RTS with thousands of units moving at once, the per-player bandwidth requirements would have been too restrictive - we wouldn’t have been able to make the game. Fortunately, we wanted The Maestros to be something a little smaller, a lot scrappier, and much, much faster. The update frequency of the Unreal networking architecture would give us excellent responsiveness - one of our core design pillars. With a small enough unit cap, the bandwidth requirements wouldn’t hinder players either, as long as they had modern internet connections.

We also wanted the game to be accessible for new players, and the hassle of configuring routers and/or firewalls wasn’t something we wanted players to deal with. We were also going to need servers with pretty large outbound bandwidth, which many home internet connections wouldn’t be able to support. For these reasons, we settled on a dedicated server model, putting the onus on us to host game servers.

Will It Work?

We didn’t take this decision lightly, though. We started with a few assumptions. One, our users would need a reliable 1 mbps internet connection to play The Maestros. This definitely doesn’t apply to every potential player, but after hearing about others coming to the same conclusions, we felt reassured that it was still worth building. How did we know this was good enough for such a bandwidth-intensive network model? First, we did some naive math. If the x, y, z of both position and velocity are stored as 4-byte floats, sending them 30 times a second gives you: 3 * 2 * 4 * 30 = 720 byte / second / unit. Ok, and we’ve got a megabit per second of data which is 1/8th of a megabyte = (1024 * 1024) / 8 = 131072 bytes. So our theoretical cap for moving units, for all players at a single point time should be 131072 / 720 = ~182 units. Now, this is little more than a gut-check number, given how much more complex things could be, but 150-200 units was just enough for us to make a compelling RTS.

As soon as we got the basics of our game up and running in-engine, we put our math to the test. Unreal performs many improvements on the naive model we described above, so we were able to get 200 units moving on the screen simultaneously with little effort, after aggressively pushing the maximum bandwidth per client upwards. We used the ‘net stat’ command in UDK to monitor our network usage. Here’s a snapshot of the stats with nearly 200 units moving at once.


In a 3v3 match, we put the cap for each player at ~20 units, leaving half again as many for neutral monsters that players would fight around the map.

Client to Server Communication

We expected moving units to be our biggest bandwidth hog, but there is a whole category of issues outside of server -> client position updates that we had to solve. Fortunately, we had a lot more freedom to come up with answers. First question: how do we tell the server to start moving units in the first place?

In Unreal, there are two primary ways to send data between client & server: replicated variables, and Remote Procedure Calls (RPC). In UDK, replicated variables are sent from the server to the clients every so often if they have changed, and they can trigger events when the client receives them (i.e. isFlashlightOn goes from false to true and causes an animation to play). RPCs are just functions that a client can tell the server to execute, or vice versa. A “server” function will always be called on the server, and a “client” function will always be executed on the relevant client.

The First Command Payload

So obviously, our commands need to be sent as server RPCs if we want a client to tell the server to do something - like move their units from one place to another. The next thing to determine was the payload. We wanted to come up with something generic that would encompass any kind of command - attack, move, use an ability, etc. Our first pass was sending a json string over the wire with a location and unit IDs. A move command for a full army might have looked something like this:

{“commandType”:”MOVE”,“unitIds”:[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21],”location”:{“x”:100.0,”y”:200.0,”z”:300.0}}

Jsons are certainly generic, and we could imagine an attack or ability command having unitIds and targetUnitId, etc. There are 131 characters in that string so theoretically ~131 bytes in each payload. When tested in-engine, with whatever function data and reliable-transfer data the engine adds, the full call turns out to be ~260 bytes, and we got up to about 8,000 B/s by clicking around as fast as we could. That’s pretty high, but well under a typical player’s outbound bandwidth. It doesn’t help that we’d also to have to send those commands to each player (in most cases), adding up to 48 KB/s to each player’s already-taxed download speed.

A Smaller Command Payload

If you’ve ever made a real-time networked multiplayer game before though, all this probably sounds pretty ridiculous to you. Keep in mind that this was a bunch of college students, trying their hand at multiplayer game programming In reality, that payload is much larger than it needs to be, and the time to serialize and deserialize those strings could really hamper performance. When we put this into practice, more than 2 players in a game tanked server performance to unplayable levels.

So we went back to the drawing board. Json strings inherently have name information (e.g. “commandType”) that is unnecessary if a strict order for each piece of data was maintained. For example, commandType will always be the first four bytes, unitIds will always be an array after that, etc. Additionally, Unreal Engine wasn’t built to tightly pack strings for network transfer. Floats, vectors, and integers, however, are Unreal Engine’s bread and butter, and they’re much cheaper for it to serialize and deserialize. In came the idea of the “FastEvent” which was just a tiny little object packed with primitive data that could be efficiently serialized, transferred, and deserialized. A movement payload still contains 21 integers, a 3-float vector and a 4 character string (21 * 4 + 3 * 4 + 4 = 100 bytes), but when we give Unreal these raw types, our typical command goes from 260 bytes to 110. Clicking around as hard as we could would barely tip 2,000 B/s in upload speed. Packing and unpacking those primitives into little objects didn’t cause so much as a flutter in the CPU usage either, and our 3v3 games became buttery smooth.

We even had space to fit a bunch more floats, booleans, and vectors used by other commands, and our theoretical max payload still sat pretty at ~160 bytes. Of course, UnrealScript didn’t make this transition terribly simple. You can’t pass objects over RPC functions, and you can’t really pass arrays either. On top of that, there’s a maximum number of arguments, so you can’t very well send all those unit IDs one by one. This left us with strings, primitives, and structs of primitives. We settled on an object that looked like this image below.


Yep, we had to hand-build arrays as structs. Coding-terror aside, each command had it’s own object that implements a simple interface with one method for translating the specific command into a generic FastEvent. Once it was translated, we would manually unpack each variable into a function argument, so that they could be individually disregarded if they were 0 or null-type and then we would piece it back together on the other side, and translate it back into its specific command type to be processed by an appropriate handler. It looked something like the snippet below.


It’s quite the function call, but it’s performed beautifully, and upload bandwidth hasn’t been a problem since!

As always, technology places certain limitations on game developer, but in The Maestros case, working with small units caps has really allowed us to make a game that looks nothing like anything else out in the genre right now, which has been pretty cool.

[Impmaster]

How much of this stuff did you guys have to learn vs make up yourselves?

[stopthief]

The basic workings of Unreal and it's network model, such as their Remote Procedure Calls and the way that movement data is replicated were things we had to learn and optimize around, digging into both the documentation and the actual code of Unreal.  All of the underpinnings of game network models in the first post was us really doing our homework, reading up on all the different ways that other people have solved thes problems. So I'd say that stuff was learned.  On the other hand, the eventing model was really our response to the problem of "synchronizing" simple objects in Unreal in a low-bandwidth way. There is a (rather complex/large) object called an Actor in Unreal which is the primary unit of "synchronization" so to speak.  Basic objects can't make network calls, so we had to come up with a way to pass messages to the more performant, smaller objects which we attached to Actors as sort of "components" e.g. an ability component or an attack component.  This was something we made up.

[stopthief]

 

The Maestros team is now fighting for our spot on Steam. When we started making this game as a student project 3 years ago we never thought we would make it this far. We are excited to be one step closer to fully releasing our game.

 

What’s The Maestros?

The Maestros is a fast-paced, team RTS game where up to 6 players battle it out in frantic combat. Map objectives and resources are often in direct competition with your enemies, so players will find themselves duking it out early & often. Combat is core to The Maestros. Coordinate plays with your team to destroy your foes!

 

So... when is this actually going to be released?

Soon... but not too soon. Given the immense effort it took to build this game, we want to make sure we're ready on our side to support all of you playing it for the first time. We are rapidly approaching our beta, and I feel confident in saying you’ll get to flirt with, fondle, and otherwise become intimately familiar with it next year.

 

Please check out our page on Steam Greenlight and vote!

http://greenlight.maestrosgame.com

 

We look forward to playing with you all soon!

-Taylor