Monday, May 19, 2014

Announcing UNET – New Unity Multiplayer Technology May 12, 2014 in Company News and Info, Technology by Erik Juhl

http://blogs.unity3d.com/2014/05/12/announcing-unet-new-unity-multiplayer-technology/

A few weeks ago, at our Unite Asia conferences, we announced that we are developing new multiplayer tools, technologies and services for Unity developers. The internal project name for this is UNET which simply stands for Unity Networking. But our vision goes well beyond simple networking. 

As you all know, the Unity vision is to Democratize Game Development. The Unity Networking team wants to specifically Democratize Multiplayer Game Development. We want all game developers to be able to build multiplayer games for any type of game with any number of players.

Before joining Unity, members of the networking team worked mainly on MMOs such as Ultima Online, Lord of the Rings Online, Dungeons and Dragons Online, Marvel Heroes, Need for Speed Online and World of Warcraft. We have a lot of passion for and a ton of experience with making multiplayer games, technology and infrastructure. 

The Unity vision was known to each of us and was always very appealing. 

When the chance to do something truly great like specializing the Unity vision with multiplayer came up, it was impossible to decline.  So we all left our former jobs and joined Unity to make this vision happen. 

Right now, we’re working hard to deliver these tools, technology and services so anyone can make their own dreams of a multiplayer game a reality.

This is of course a pretty big undertaking, but, like I said, we have all done this before, and we are all very driven to do it again (because it’s really, really cool!). The way we have tackled this is to divide our overall goal into phases which should be familiar to Unity developers. 

We take the approach of releasing a Phase 1, getting feedback from our users, adding that feedback to our work to make the next phase even better and repeating that cycle.

For UNET, Phase 1 is what we call the Multiplayer Foundation – more on that in a bit. Phase 2 is where we build on Phase 1 to introduce server authoritative gaming with what we call the Simulation Server, we’ll blog about this later. Finally, Phase 3 is where we want to introduce the ability to coordinate multiple Simulation Servers through a Master Simulation Server. 

As usual, exact dates for this are not possible and of course things can change, especially after gathering feedback from our users. But we can say that Phase 1 will be part of the 5.x release cycle and Phase 2 is in R&D right now.

So what do we mean by the Multiplayer Foundation for Phase 1? The main features are as follows:
  • High performance transport layer based on UDP to support all game types
  • Low Level API (LLAPI) provides complete control through a socket like interface
  • High Level API (HLAPI) provides simple and secure client/server network model
  • Matchmaker Service provides basic functionality for creating rooms and helping players find others to play with
  • Relay Server solves connectivity problems for players trying to connect to each other behind firewalls
We had some inherent limitations with our legacy system that we needed to address and with our greater goal in mind it became clear that we needed to start from scratch. Since our goal is to support all game types and any number of connections, we started with a new high performance transport layer based on UDP. 

While it’s true that a lot of games are done quite well with TCP, fast action games will need to use UDP as TCP holds the most recently received packets if they arrive out of order.

From this new transport layer we built two new APIs. We have a new High Level API (HLAPI) which introduces a simple and secure client/server networking model. If you’re not a network engineer and you want to easily make a multiplayer game, the HLAPI will interest you.

We also wanted to address feedback we’d received on our old system: some users needed to have a lower level access for greater control. So we also have the Low Level API (LLAPI) which provides a more socket-like interface to the transport layer. If you are a network engineer and want to define a custom network model or just fine tune your network performance, then the LLAPI will interest you.

The Matchmaker service is used to configure rooms for your multiplayer game and get your players to find each other. And finally the Relay Server makes sure your players can always connect to each other.

We know from our prior experiences that making multiplayer games involves a lot of pain.  So the Multiplayer Foundation is a new set of easy to use professional networking technology, tools and infrastructure for making multiplayer games without this pain. 

To even get started, I think it is fair to say that making a multiplayer game requires a fair bit of knowledge of networking and protocols. You either overcome the painfully steep learning curve yourself or find a network engineer to join you.  

Once you’ve gotten past that, you then have to solve the problem of getting your players to find each other.  And once you’ve solved that problem, you now have to deal with getting players to be able to actually connect with each other, which can be troublesome when they are behind firewalls with NAT.  

But then if you’ve solved all of that you’ve created a bunch of associated infrastructure which wasn’t game development and probably wasn’t fun. And now you have to worry about dynamically scaling your infrastructure which usually takes a bit of prior experience to get right.

Our Phase 1 addresses each of these pain points. 

The HLAPI eliminates the need for a deep knowledge of networking. But the LLAPI is there if you are a network engineer and you want to do things your own way. 

The Matchmaker solves your problem of getting your players to find each other. 

The Relay Server solves your problem of getting players to be able to connect to each other. 

And we also solved your problem of the associated infrastructure and dynamically scaling it. 

The Matchmaker and Relay Server live in Unity’s Multiplayer Cloud. So not only do the physical servers scale up and down based on demand, but the processes scale up and down as well.

We are very excited about UNET and are eager to share more details. Over the next few weeks we’ll follow up with more blogs from the rest of the team.  We would love to hear what you think, and we can’t wait to see what you all make with this in the future.

Saturday, November 23, 2013

Doctor Who's 50th Anniversary_Google Doodle Game

http://www.google.com/doodles/doctor-whos-50th-anniversary

Doctor Who's 50th Anniversary




Nov 23, 2013




The Doctor Who doodle started life as a request from a huge fan at Google. It seemed daunting- 11 Doctor's, 50 years of adventures, countless enemies and time travel!

But we loved the idea of science fiction, technology and fun coming together, so we set about creating a multiple level game. 


The game was always a simple premise- those dastardly Daleks have stolen the Google letters and we need Doctor Who to retrieve them.

Artists don't make games, programmers do. I provided the designs and various pieces of animation but without the engineers the game would only exist in another dimension! I was fortunate to work alongside people that genuinely cared:

 

Engineering Gurus - Rui Lopes, Corrie Scalisi. Mark Ivey
Additional support - Doug Simpkinson, Jonathan Shneier
All things D of 3 - Leon Hong
Deity of rain, lava & lightning - Kevin Laughlin
Additional game ideas - Gregory Capuano
Sounds - The BBC, Tom Tabanao, Manuel Clement and Cody!
Creative consultant - Chris Dibona
User testing - Jennifer Zamora

 

We thank the BBC for trusting us and also helping us whenever needed. So what are you waiting for?! Jump in your TARDIS (Time and relative "doodle" in space) and become the fastest time lord in the universe!









Location: Global
Tags: Dalek, Cybermen, Cemetery, Tardis, Weeping Angel, Game, Doctor Who, London, Time Lord, Interactive

Tuesday, November 19, 2013

Monday, November 18, 2013

Designing a game that breaks friendships (SpeedRunners) by Casper Van Est on 11/12/13

http://www.gamasutra.com/blogs/CasperVanEst/20131112/204579/Designing_a_game_that_breaks_friendships_SpeedRunners.php#!

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.


 
Cursing. Screaming. Victory dances. Lots more cursing. Occasional airborne controller. This is daily routine when working on SpeedRunners. You recognize this feeling if you played it.

SpeedRunners is like Mario Kart if it was a 2d ultra competitive platformer. It will make you reevaluate certain friendships after playing. It will bring out your inner-rage. The competitive nature of the game is probably the most important focus for us.

So here's a step by step crash course of how we approach the design behind SpeedRunners:

1. Making it fun for new players

We're not designing the next Starcraft with a 4 hour learning curve. We are making something that's super easy to pick up, that makes you instantly understand what's going on. In SpeedRunners, you simply hold RIGHT or LEFT to start running. Running is usually enough in the beginner maps. You can instantly start having fun without knowing any of the deeper mechanics. You discover how to jump, jumping over platforms. Everyone knows how platformers work.

You don't need to know all mechanics of SpeedRunners to start having fun.

2. Easing into deeper mechanics

Within 3 matches you will know how to grapple onto white ceilings, do super quick wall jumping, and that you can boost mid-air to quickly change your direction (Devil May Cry style). You will start discovering more interesting ways to use items. Dropping boxes onto people's heads while wall jumping makes them lose grip and fall. The shockwave mid-air makes people fall to their deaths. The grapplehook can change the outcome of a match in a matter of seconds. Sliding just before getting hooked makes you dodge it.

It gets really deep really quickly, without feeling overwhelming.

On the 4th match or so, out of nowhere a Wheel of Fortune will appear. It will choose one of several modifiers - like all items being grappling hooks or everything being super fast - to spice up the game. What it also does is force people to use key mechanics in different ways.

When everyone has grappling hooks, you quickly realize how to use them more effectively, and how to dodge them.

3. Level design & choices

Even if you have all the mechanics in place, the game easy to pick up, etc -- it won't matter unless your level design is spotless. We spend most of the time balancing and fine-tuning levels. This makes or breaks SpeedRunners.

If you look closely to all the levels we have, there's always a risk-and-reward thing going on, along with mini-races to specific goals.

Illustration of Factory's right part
Messy illustration of a hard and easy path in the upcoming Factory level. The easier path enables you to block the harder path, or to choose an item instead. If you succeed on the hard path, it's almost a guaranteed point. 

The most fun - and competitive - aspect of SpeedRunners is when you're about to win, or about to lose. This makes alternate paths in levels very important. Each path has it's own risk/reward. You can take a more risky path with lots of spikes and tricky jumping sections, at the end of which is a trigger. The trigger closes the other path, giving you an almost-guaranteed point. Fail that path and face certain defeat.

These paths spawn mini races. You clearly see someone going for a trigger. It makes your heart race. Palms sweat. Unintentional cursing. Glory of winning or shame of defeat.
Levels are designed so that everyone always has a fair chance. You mess up a small wall jump, your gate gets closed. You weren't fast enough. If you were friends with your opponent, you're not anymore.

The mini races become more interesting with specific rewards. Item pick ups are strategically placed, giving you incentive to try specific paths. More experienced players will hold on to their items and wait for specific moments. It's much smarter to hold onto the Invincidrill (a drill powerup, making you fast, invicible and knocking down opponents) until you are in a narrow corridor, than using it in a wall jumping section.

In the recent Theme Park level we have two large Leaps of Faith. These are long jumps that result in insta-death if you mess them up. Each time you are about to do one of them, it's a good idea to be aware of what items other players have and prepare to counter.

Think split-second reaction of assessing the situation on-screen, timing your counter -- or item use -- and preparing to double jump to land on the platform correctly. These split second decisions contribute to the competitiveness, and keep SpeedRunners interesting for more experienced players.

4. Testing, testing, testing

It definitely helps to be in Steam Early Access. We can getaway with breaking the game and label it as testing. Before introducing the Wheel of Fortune, we had an event every Thursday where we'd break the game. We'd make rockets fall from the sky, force everyone to use only grappling hooks, mirror all levels, etc. The fun game breaks made it into the final game as a Wheel of Fortune modifier.

Wheel of Fortune in SpeedRunners
Pictured: Wheel of Fortune that modifies the game every 4 matches or so

During a Twitch Lets Play session with several thousand viewers, the players got a bit confused and started running _wrong way_ around the map, which doesn't exactly work. This is when we started to pay more attention to labeling maps as finished or Prototypes.

Prototypes are levels in development. Some levels we're instantly confident in - they are just really fun to play and easy to understand. Others we will release without much artwork, with the intention of doing more tweaking based on player feedback. We take that feedback and perfect levels before putting in final artwork. And we'll sometimes do 3 releases a day.

Past few months we've been working out the core mechanics of SpeedRunners, and how to streamline new level creation. Both are nailed down by now, and are going into overdrive mode on creating new levels for the next couple of weeks. The initial success of levels is usually measure by the amount of cursing during local playtesting.

What NOT to do when starting as an indie game developer by Roger Paffrath on 11/15/13

http://www.gamasutra.com/blogs/RogerPaffrath/20131115/204871/What_NOT_to_do_when_starting_as_an_indie_game_developer.php

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.


This text was originally posted on Roger Paffrath's personal blog.

A while ago I stumbled upon a talk submission form for an event called The Developers' Conference. It's a gathering of people who want to learn a little bit more about topics like architecture, digital marketing, Arduino and others. Sure enough, games were going to be discussed there too.

The event was close to at least four universities that have game courses, so I thought many young faces would show up. Right after I saw the submission form, I started thinking what I could tell those people that want to be a part of the game developing scene here in Brazil. 

It didn't take long before I realized I wanted to share with them the things I messed up on the past two years and maybe help them be more aware of some of the tricks you can fall for when you are too eager or too optimistic to do something.

When my talk got accepted I wanted to validate my arguments with other people's own experience. That was something I didn't have time to do and this post is an attempt to fix that. What this post is not, however, is a receipt to follow blindly. Feel free to disagree with me and bring your ideas to the table.

Here's what I've come up with:

1. Do not fall for survivorship bias.

For those who may not know, survivorship bias is the tendency to consider only successful cases when analyzing market data, behavior, etc. It even influences warfare.
How does that apply to game development then? Well, when I started, I remember being really optimistic and enthusiastic about building an iPhone game. I was reading article after article of developers that were making good money out of the App Store and I thought maybe I could get some bucks myself. I didn't stop to think things through and it did not go well.
"Resistance outwits the amateur with the oldest trick in the book: it uses his own enthusiasm against him." - Steven Pressfield, The War of Art
Take your time. Think of the obstacles ahead. Talk to people and ask for advice. Analyze every option. Then take some more time. Only after that make a choice and never look back.
To know more about survivorship bias I strongly recommend reading this.

2. Do not start with a complex idea.

I see a lot of guys that want to start out doing things like an FPS. They seriously want to start doing that. They have only the basic skills, but that's what they want to do.
When these guys sit down to actually do the job, they are easily defeated. That's because they don't realize the amount of energy you need to put into a project and they have even less idea of their own professional capabilities.
I am not saying your first game cannot be an FPS, but you have to consider all the things ahead. If you choose an FPS, it will take really long before it is finished and it will be on the market alongside Call of Duty. Isn't it better to start with a smaller project to get under the radar of the press and fellow developers earlier?
For me, the smaller the better. But, no matter the size of the project, I like to read this piece by Tommy Refenes every once in a while. You have to divide your project in parts, tackle those parts individually and every now and them step back and enjoy the progress you made.

3. Do not make a simple idea complex.

Do not overcomplicate things. This happened with Little Red Running Hood. If you start thinking about adding stuff, stop and evaluate if those things are really going to improve player experience and if they sit well with the core mechanics.
I found that the two next items on the list are important agents on avoiding adding useless stuff to a game you've been working on for months. You can also read more about this here.

4. Do not skip the prototype phase of development.

So, how do you keep from adding useless things to your game? You do this kind of thing on a prototype. That's why it is important not to skip prototyping, specially when you're really eager to start making something. It's an opportunity to let your big creative brain run on overdrive.
By making a prototype, you can find out if the mechanics created really work by their own. You can also get folks to play your idea and get decent feedback to improve it. Yes, you will probably need to improve it.
Discover if your game, in its simplest form, is fun before investing months of your time developing it.

5. Do not forget to make a GDD [game design document] or write your ideas down somehow.

Ideas have this weird behavior. Sometimes they run away and are lost forever. Other times they mutate... it can be to something better - which is cool -, but they can also transform into something nastier than their original version. Writing them down is a way to avoid such messy scenario.
When working with teams there is also this strange thing that happens sometimes. You can try to explain your idea to me and I can choose what to listen or twist it somehow. Or maybe your explanation isn't clear enough. When the time comes to actually implement it, it won't turn out as you expected. Hopefully, a well documented idea can solve this situation.
A GDD also makes things easier when there is need to bring someone new to the team, specially if the person is working remotely. It gives a full perspective on the game.

6. Do not underestimate the power of good planning.

Deadlines are awesome. Most of the things done on this planet have only been accomplished because of them. Without them, we feel too comfortable and a comfortable creative mind starts wandering. Before you realize, you're taking double the time to complete simple tasks.
Other positive aspect of good project planning is that you are able to focus on one thing at a time. You don't have to worry about those awful bugs, because you will have the proper time to deal with them later.
Some people might think that's only for larger teams or projects. That's OK. In the end, if you sit down every day and do the work you need to do, it all falls into place. Me? I like a good old fashioned deadline.

7. Do not leave marketing to the last months of development.

Legend has it that when Brazilian cartoonist MaurĂ­cio de Sousa started drawing, his father told him that there was no problem with that, as long as he learned how to sell his creation too. Thankfully, he listened.
Here is something I see most of indie game developers around me doing: they focus exclusively on the technical aspect of making a game, without even thinking about how to get it in front of larger audiences. Not even to play test the things they make. They worry about it much later, when the project is near the finish line. Alexander Bruce has some great insights on how that can lead to obscurity.
Hopefully, as the industry matures, beginner indie developers will become more aware of that and will start getting word out earlier and saving bigger budgets for marketing.

8. Do not play test only by the end of the project and/or only with friends.

Like stated before: it is best to have large groups of people playing your game as soon as possible. You followed the advice provided here and built a prototype? Show them to strangers on the street. Go to events with the latest build of the game and get as much feedback as possible. After that, make some adjustments and go to the next festival.

9. Do not start on the mobile market.

This one is the one I get most of people disagreeing with me. It's the first item on this list making young developers see everything optimistically. The real truth is: the good things on mobile are far less numerous than the bad things going on on the platform.
Seriously, if you are starting, with no fans, no press awareness and no big money to invest on marketing, forget the mobile market. This is something I learned the hard way. I saw months of hard work fall into the limbo of the App Store. Obscurity is a bitch.
Even if you forget the discoverability of games on the mobile market being all messed up, I really don't think you should start there. There are easier and faster ways to make and distribute games. Part of the reason we didn't play tested Little Red Running Hood accordingly was the fact that it was hard for us to send the app to people outside of our friend circles.
I realize there are two sides for that discussion and that there are down sides to any market, but I will remain encouraging people to start reading more about the problems of mobile and all the stories of other developers who fell for the mermaid's song.

10. Do not forget the budget for attending events and festivals.

Hands down, this is the best way to show your game to other people and starting networking with other developers and press. These are creative minds that gather on the same place at the same time because they love games. That's inspirational. At least I heard. I was stupid enough to consider only submitting my game to these festivals, but never thought of showing up in person. When I realized the benefits of attending these events, I had no money to do so.

11. Do not ignore the fact that you are part of an industry.

Starting out on any industry is hard. It is even harder if you are blind to all the topics and people that are relevant in the business. Luckily, this is the easiest tip on the list to follow. Just check this list Rami Ismail wrote with some interesting twitter accounts on the gaming world (don't forget to follow @tha_rami himself). Don't have a twitter account? Fix that now, it's free!

12. Do not wait for a diploma to start making things.

You are not studying to be a doctor, lawyer or engineer. Maybe if you were you would have realized something most of my colleagues at university don't.
You want to work in a certain field? Start thinking of your career early.
Stop throwing that unfinished project away at the end of the semester. Stop doing things for grades. Stop doing things for love, too. Do it for your career. Love your career itself. Become a professional and finish things!

13. Do not hide those things.

I know for a fact that there are a lot of people around me doing things related to game development. However, I know very few of those people and even less of their games. Why is that?
If you are working on a game and you hide it from people, you are being selfish. You are keeping them from having fun. You are also overconfident. Before spending more time working on the awesome idea you had, how about you let us play it and them we can give you feedback?
I am currently trying to organize meetings with developers to get something going. If you are a local indie working on a game, please get in touch. It isn't hard to find me. If you made it this far on the post you are truly persistent, therefore I would like, not only to play your games, but also to personally high five you.

Bonus for Brazilian developers:

This consist of only one tip, but it can make all the difference for people with tight budgets. Maybe it applies to other countries too, but for now I only know how this works in Brazil.

14. Do not open a company.

You are just starting out. You don't need to pay taxes, you don't need to have an accountant and you don't need fancy paperwork (and believe me, there is a lot of paperwork).
Focus on building something first. Make some games, get some word out and try to find your voice. Partner up with different people and get informed about their experiences. There are many other ways to start out other than opening a company right away.
Actually, those who encouraged me to start a business were the ones who were interested on doing the accounting for us. Coincidence? I think not.
The damage wasn't that much, but the money we put into the company could've been used to show our game on events. International ones.
Now, I only see a point on going through all the paperwork to register a business here if you are aiming to get a deal with an investor, join government programs or sign a contract with Sony or Microsoft. You have to really trust your gut to go for those things as a beginner. But, if you decide to do it nonetheless, let me know how it turns out.

Anyway,

Even if you don't take any of my advice, you are probably here because you are interested on game development. So, I wish you keep making great games. Maybe someday I'll get to play them.

Follow Roger Paffrath on Twitter.