gdarchive

Members
  • Content count

    20
  • Joined

  • Last visited

Community Reputation

3180 Excellent

About gdarchive

  • Rank
    Third Party Articles
  1. Composition 101: Balance

    In physics, Balance is that point where a specific distribution comes to a standstill. In a balanced composition, all elements are determined in such a way that no change seems possible. The piece must give the feel of steadiness, otherwise, it will just seem off. Rudolf Arnheim, in his Art and Visual Perception book, stands that there are 3 elements to balance: shape, direction, and location. He also says that in the case of imbalance “the artistic piece becomes incomprehensible […] the stillness of the work becomes a handicap”. And that’s what gives that frustrating sensation of frozen time. In this simple example, you can see all this. Having the sphere off center gives the sensation of unrest. The sphere seems to be being pulled to the corner almost. It’s if like an invisible force is pulling it from the center. These pulls are what Arnheim calls Perceptual Forces. And with the sphere in the center of the walls, you have the sense of balance, where all the forces pulling from the sides and corners of the square are equal. Returning to physics, we can say that when talking about Balance the first thing that pops into our heads is Weight. And that’s what it is all about, what we think. Because, as I said before, perception is just the brain processing images. So, if when we talk about balancing something we think of weight it definitely has to have something to do with it in art, right? Exactly. Arnheim talks about knowledge and weight in balance referring to the fact that anyone who sees a picture of a scale with a hammer on one side and a feather in the other knows that the first one is heavier. If the scales are perfectly balanced it will just seem off. But balance does not always require symmetry, as we might tend to think. Isn’t equilibrium that brings balance. If the scales tilt to the “correct” side (the hammer) perceptual balance would have been achieved. In Art, as in physics, the weight of an element increases in relation to its distance from the center. So an object in the center can be balanced by objects to the sides, and objects on one side of the frame must be balanced with objects in the opposite location. But this doesn’t mean that the objects must be the same (symmetry and equilibrium), for there are properties that give objects weight besides their actual apparent weight. SIZE. The larger the object, the heavier. COLOR. Red is heavier than blue. Also, bright colors are heavier than dark ones. ISOLATION. An isolated object seems heavier than the same object accompanied by smaller ones all around it. Arnheim puts the moon and stars as an example here. SHAPE. Experimentation has shown that different shapes affect the way we perceive weight. Elongated, taller, figures seem heavier than short ones (even though they both have the same area size). To expand on this matter I recommend you to go back to the books I will reference in the sources down bellow. Even though these are really simple examples, I plan to move on with this theory applied to environment art. The whole take on Balance gives all the world building process a solid base stone. Embracing these principles will help you understand and better plan object placement in your scene to avoid the feared feel of steadiness Arnheim warned us about. There is still a bit more to explain about Balance so I will be expanding a bit more on this matter in future posts. Thumbnail art: Madame Cezanne in a Yellow Chair, c.1891 - Paul Cezanne Sources: Arnheim, Rudolf (ed.) Art and Visual Perception. A psycology of the creative eye. University of California. 1954. Bang, Molly. (ed) Picture This. (1991) Baker, David B. (ed.). The Oxford Handbook of the Psychology. Oxford University Press (Oxford Library of Psychology), 2012.
  2. Last Rites is an isometric role-playing game that takes place in TSR’s Planescape setting. It uses the Bioware Forgotten Realms engine with Interplay artists supplying the Planescape ambiance and feel. The player creates a single character. Over the course of the game, the player picks and chooses a series of allies (pals and romantic interests) to join his party and allow him to kick ass more efficiently. The maximum party size at any one time is five. Download: Torment_Vision_Statement_1997.pdf
  3. During the development of Metal Gear Solid 2: Sons of Liberty, Hideo Kojima came up with a Grand Game Plan for the sequel to Metal Gear Solid and how it would be utilized on the PlayStation 2. The Grand Game Plan was included in The Document of Metal Gear Solid 2, although only in the original Japanese text. In July 2006, Marc Laidlaw of Junker HQ released an English translation of the Grand Game Plan: MGS2gameplan.pdf
  4. Ion Storm Design Docs

    Scanned collection of design, planning, and concept documents from Ion Storm. Download: Ion Storm Design Docs.pdf
  5. The Thief 4 Game Concept Submission Document from 2004. From the document: Download here: Thief 4 Submission Document.pdf
  6. The Sims Design Docs

    A collection of design documentation from the development of The Sims from Electronic Arts and Maxis, dating back to 1997. 3DPeopleQuestion.pdf AnimationClassBreakdown.pdf AnimationDocumentation.pdf ArtDepartmentPostMortum.pdf BrainstormProblemListForArtTeam.pdf Ch00-TableOfContents.pdf Ch01-Goals.pdf Ch02-World.pdf Ch03-Objects.pdf Ch04-People.pdf Ch05-PetsAndPests.pdf Ch06-Simulator.pdf Ch08-Framework.pdf Ch09-Architecture.pdf Ch10-Graphics.pdf Ch11-Movement.pdf Ch12-CharacterAnim.pdf Ch13-Sound.pdf Ch14-Resources.pdf Ch16-Tools.pdf Ch17-TDSB.pdf Ch18-ContentDevelopment.pdf Ch19-SoftwareDevelopment.pdf Ch20-Documentation.pdf Ch21-Happy.pdf Ch22-ContainedInteractions.pdf CharacterRenderingDevelopmentPlan.pdf ComprehensiveArtAssessment.pdf ContentCreationRules.pdf CuckooClock.pdf EdithDocumentationOverview.pdf EdithPrimitives.pdf FailureTrees.pdf FigureNG.pdf FloatCompression.pdf GuineaPigCage.pdf HappyFriendsHome-2-10-96.pdf HitSoundRevivew.pdf HitSystemDesign.pdf HowToPursueHappiness.pdf JeffersonCharacterMotives.pdf JeffersonDemoTutorial.pdf JeffersonTools.pdf MasterIDAndSubIndexOverview.pdf MaxisSimRules.pdf MooseHead.pdf NotesFromMaxisNewPencilPostmortem.pdf ObjectFileFormat.pdf ObjectIFFFileFormat.pdf ObjectList.pdf ObjectMakingProcedure.pdf ProgrammingObjectsInTheSimsV3.pdf ProgrammingSimsDialogs.pdf ProposalForExtendingTheSimsFranchise.pdf QuickReferenceGuideForTheBewSimsSpriteExporter.pdf ResourceEXE.pdf ResourceFileOverview.pdf SimsBoxXSpecAndDesign.pdf SimsContentLibraryNotes.pdf SimsFileFormat.pdf SimsScripts.pdf SimTransmogrifierDesign.pdf SimTransmogrifierTODO.pdf SlotMachine.pdf SpriteGeneration.pdf Storytelling.pdf Strategy.pdf SuitConventions.pdf TDRObjects.pdf TDSB.pdf TDSBInfo.pdf TechnicalEmail.pdf TheSimsDesignDocumentDraft3-DonsReview.pdf TheSimsDesignDocumentDraft5-8-31-98-DonsReview.pdf TheSimsDesignDocumentDraft5-DonsReview.pdf TheSimsDesignDocumentDraft7-DonsReview.pdf TheSimsPieMenus.pdf TheSimsProjectCompletion-18-12-98.pdf TheSimsQuickStartGuide.pdf TheSoulOfTheSims.pdf TheStateOfTheArtAndGoingForwardToE3.pdf Tools%20Proposal%20Updated.pdf TransmogriferRenovationPlan.pdf VirtualMachine.pdf VitaboyOverview.pdf VM.pdf VMDesign.pdf WallLights.pdf XAnimatorDesign.pdf JeffersonDevelopmentMilestones.pdf JeffersonGameDescription.pdf JeffersonSpectrumOfChallenge.pdf SpriteRotations.pdf TDSEditToDo.pdf
  7. According to WSJ, the global mobile game market is expected to increase eightfold from $3.77 billion in 2010 to $29.6 billion in 2017. And among all the countries, the Asia Pacific region, with China and Japan as leaders, is the biggest market for mobile game developers with 48% of the global revenue and three times more paying gamers than the second biggest region, North America. Considering these statistics, itaEUR(TM)s no surprise that there are countless mobile games trying to expand abroad each year; however, very few can claim success. Part of the problem is that mobile gaming has become a modern-day gold rush. Worldwide developers flooded the market hoping to strike it rich, making todayaEUR(TM)s mobile game market extremely competitive, no matter in domestic or oversea markets. But the biggest factor is that developers often underestimate the challenges and importance of mobile game localization. In our experience of helping mobile games go global, here are six common mistakes they make when jumping into the international market. Avoid these, and you will greatly increase your chances of success. 1. No explicit international strategy and plan The most basic and early stage mistake a game developer can make is failing to understand that localization is more than word-for-word language translation. Whenever you plan to take your game global, first establish a localization strategy that answers questions like: What factors characterize an attractive market for your company? (e.g population, GDP, mobile penetration, competitors, language, regulation, cultural factors, partners...) WhataEUR(TM)s your prioritized list of the top 10 world markets based on these criteria? Can we test the demand of a market before going all-in? What are the market needs of each? Can your company address multiple markets at the same time? Should you find a local partner? WhataEUR(TM)s your go-to-market strategy for each country? Lack of commitment and understanding in localization often kills an international initiative. Therefore, make sure your company has a strong corporate champion to drive the in-depth research, explore the markets and own the execution once the strategy is done. Without formulating the right strategy and translating it into actions, your game will fail, no matter how many languages it supports. 2. Ignoring localization in the early phase of game development Many game developers try to postpone localization-related discussion until the end of the development cycle, but they donaEUR(TM)t realize that they have made a huge mistake from the moment they write their first line of code. What this typically equates to is a lot of rework and additional costs to go back and modify your code to work when you add new language and localization requirements, costing your company thousands (or millions) of dollars and months of delay in getting into overseas markets. Instead of doing costly rework down the road, your team should make an explicit decision on internationalization upfront. Is your code well-prepared for the pre-translation phase? Are your UI strings all externalized? Have you given careful consideration in international non-text elements such as symbols, colours, time and date formats, and currency symbols? If your code isnaEUR(TM)t localized in the beginning, the problem is getting worse with every line you add. 3. No aEURoeculturalizationaEUR? process To increase the odds of a titleaEUR(TM)s success in international markets, great attention must be paid to the cultural aspects. Basic language translation is the bare minimum that any game developers should be doing. Ideally, your translators should be able to adapt your game content to the local culture because culturalization is a necessity. aEURoeWhat we learned about international markets is that itaEUR(TM)s not enough to localize the content by just translating it. Instead, we have to culturalize it,aEUR? Craig Alexander, VP of Product Development for game studio Turbine, said. In order to create the best gaming experience, your translators have to understand foreign cultural traditions, the latest pop culture in the targeted country, local points of reference, etc. The same applies to non-text assets. For example, while showing a peace sign is normal in the USA, a reverse peace sign suddenly becomes an insult in places like the UK. Why did EAaEUR(TM)s Plants vs. Zombies become one of the biggest mobile hits in China? Just look at the localised design of the zombies and the Great Wall background in the picture below. Keep in mind that you can build gamer loyalty by fully capturing a regionally exclusive experience within the game. 4. Underestimate the challenge of global mobile game distribution If you think that all the mobile game distribution channels in every country are similar, you are making a big mistake! In the rush to launch overseas, this is often the most overlooked problem by game developers. Do you know that China doesnaEUR(TM)t have Google Play? Instead, it has around 200 Android app stores creating a highly fragmented market. Without a system in place to track the performance of these channels, you basically canaEUR(TM)t have accurate strategies for distributing your app in this country. Each of those app stores serve a different audience with their own characteristics. You need to look at their different behaviours and adapt your games to different situations. For instance, market leaders often create different versions for different app stores. In other words, if there are 20 app stores they want to target, they will create 20 different versions and marketing strategies for their games. Due to these complexities, many western game developers work with local publishing and localization partners when they are trying to expand to China now. When your team comes up with the localization strategy plan, make sure to discuss whether a local partner is needed. 5. Failing to localize the monetization strategy Although your code and content may be the most obvious localization candidates, your revenue model is equally critical. In some developing countries, like China, their game players donaEUR(TM)t make as much money as the average US gamers. Your business model needs to reflect that reality as a result. When Plants Vs. Zombies 2 launched in China, they initially tried to optimize for the monetization too much, making the game way too hard and expensive to play, which backfired on useraEUR(TM)s reviews and dropped their rating from five star to two at one point. To overcome this, they learned from the experience and tried to figure out the right balance of difficulty and how to reasonably ask for money by changing the gameaEUR(TM)s economy. Now they get far fewer negative reviews than before. When sharing his learnings at the Game Developers Conference, Leo Liu, GM of EA Mobile in China, said, "The Chinese market is so different, you have to be prepared for anything unusual from the Western perspective.aEUR? Make sure you wonaEUR(TM)t repeat their mistakes. 6. No on-device testing and translation review prior to release This is an amateur problem that is so easily avoidable and yet we came across it time and time again. You work so hard on the game, create a great localization plan, translate UI strings, it launches, and suddenly, you realise something is broken. You find out that some extra long German words break some of your game UI! But the worst part of this scenario is when your CEO asks you how this happened, and you say, "I thought the translator was taking care of itaEUR|aEUR? Never assume and never leave anything to chance. At the end of the day, if something does go wrong, and you could have easily prevented it, the responsibility is on you. Professional translators are human and people make mistakes sometimes, especially in the complex, fragmented and rapidly evolving world of mobile. Make sure your localization partners provide localization testing and review services on a number of mobile devices because you canaEUR(TM)t afford to disappoint your users with buggy games. After youaEUR(TM)ve received a poor rating, there is no way to hide poor quality in the world of mobile. Conclusion ItaEUR(TM)s true that international expansion is hard to get right. Therefore, clear ownership, good strategy up-front, and great execution are critical. That way your mobile game will be in a great position to take advantage of the huge international opportunity! If you want to learn more about whether your mobile games are on the right track in terms of localization strategy, I invite you to get a Free Assessment with our Localization Managers today. WeaEUR(TM)re here to help! Simply click the banner below to join the invitation. Note: This article was originally published on the OneSky Localization Blog and is republished here with kind permission of the original author.
  8. With Toto Temple Deluxe being almost ready for release (aiming for Summer 2015), we decided it was time for us to attend a real big event like PAX East. It was our very first PAX, with our very first 10' x 10' booth, for our very first console game release! We thought it'd be a good idea to share our overall experience, especially since we experimented a bit with marketing, as you can see in the title. Up North Indies We had our very own booth at the convention, but we were part of a bigger (and brand new) group called Up North Indies. We're essentially a group of multiple indie developers from Montreal/Quebec getting together to share knowledge, but also to get easier access to events like PAX. We've been learning and getting a lot of help from the other studios by being part of this group. We're definitely lucky! We made the logo for the group with some generous help from design superstar Cory Schmitz We had a little bit of branding at the event to identify each booth as part of the UNI, but we couldn't get anything big done in time (a huge hanging banner, for instance). We learned a lot from PAX, which was our first group event, so we'll definitely have better presence at future events. Photo by the Parabole crew, check out their game Kona! Designing our first 10' x 10' booth The event was in Boston, so about 5 hours drive south of Montreal. We managed to get there by car to save money, but the downside was that our car was pretty small and we couldn't travel with a lot of equipment. We still managed to get two 7' tall TV stands, two 42" TVs and one 50" TV. Here's how we did it. Empty, but not for long! First thing we took in consideration for the design of our booth is that we were on a corner (still lucky). We took advantage of that and tilted everything diagonally to face both sides simultaneously. We think it played a big role in the success of our booth. We also wanted to have one main TV station for players, and some higher cloned TVs for spectators. Since a single Toto Temple Deluxe match doesn't last very long, we didn't bother with chairs and stuff. Everyone played while standing up and rotation was fast. As this was our first big event with our first "big" booth, we had literally no equipment. We always managed to get by with borrowed stuff, but this time we had to invest in some new equipment. The monsters. We got ourselves some pretty tall TV stands from Displays2Go. They're heavy as hell, but they can support really big TVs up to 7' in the air! Our booth also came with a table, so we had enough to support 3 TVs in total. Speaking of TVs, we had no room in the car for 3 big TVs, so we simply decided to "rent" them at a nearby Best Buy in Boston. And by rent we mean buying them and taking them back after the event by saying it didn't fit our needs after all. No questions asked, thanks Best Buy! How we got noticed To put things in perspective a bit, we originally designed our PAX demo so that matches would be really quick. That way, we'd have a better flow and more players would try the game. Since matches wouldn't last long enough for the crowd to feel any major engagement, or for hype to build up, we needed a better way of getting spectators more engaged in the game as they were looking at it. See that crowd? We sort of designed it. Normally, only the 4 current players would be really engaged in the game. Maybe they were with a friend, and maybe that friend would get engaged and cheer a bit, but we felt like it wouldn't be enough to build enough engagement / hype overall. We then heard of a strategy that the guys from Vlambeer were doing at events for Nuclear Throne. They would have hourly challenges where everyone watching would get a free copy of the game if the current player managed to beat the game. That would normally encourage people to stay and look at the game. They would have something to win (or lose), so they should feel engaged. Yellow warning signs: A pretty good way of getting people's attention! We thought it was really clever and it would totally fit our needs, but we decided to push the idea a bit further. Instead of asking players to come back every hour to have a chance of winning a free copy of the game, we decided that every - single - match would be an opportunity to win a copy of the game. With that in mind, we needed something to link the giveaways to. Ideally, something that wouldn't happen every match, but only once in a while so we don't end up giving away 50,000 copies. That's when we came up with the showdown system. The Showdown system If you've followed the development of Toto Temple Deluxe a bit, or simply played the game, you know there's 2 main game modes. The Classic mode, where you fight for an egg-laying goat to make points, and the Bomb mode, where you fight for an explosive goat in order to kill your opponents with the blast. With the showdown system, pretty much all spectators got to see both modes. Since we needed something to link the giveaways to, we figured we could use the bomb mode for that. Here's how the system works: The winner of each match (in Classic mode) would be automatically thrown in a 1 vs 1 bomb showdown against 1 bot (set at hard). If that player manages to kill the bot 2 times, everybody watching would get a free copy of the game. BAM. It was also a good way of having players experience both modes and discover the game's content without having to come back to play a match in the other mode. The goat hat was necessary to participate in a showdown. To make things more official / exciting / funny, we also crafted goat hats for the winner to wear during the showdown. It had the effect of making the crowd laugh, friends would take pictures (always good), and it made the people passing by wonder what it was. We also needed people to know that they could win a free copy of the game simply by looking at it, so we designed 2 big signs explaining the rules and hung them over the cloned TVs (which you probably already saw in the pictures above). Giving away 1,700 keys in 3 days Every once in a while, a skilled player would win a match AND the following showdown. Here's what it looked like: [media][/media] As you can see, the showdown system managed to build hype and engagement from the crowd. It worked really well! Maybe a bit too well. The amount of showdown victories were reasonable, so we planned them right, but what we didn't expect what the amount of spectators watching the game! What happened was that spectators would literally stay and watch until someone eventually won a showdown. The crowd would grow bigger and bigger over time, but it had the weird effect of clearing the whole booth as soon as we handed out the keys after showdown victory. It was funny how empty the booth was after each victory, but a brand new crowd would form really quickly as 4 news players stopped to try the game. We were handing out printed Steam keys like these. We started out with 900 keys, and thought it would be enough for the whole event. We were dead wrong. We actually ran out of keys by the end of the second day, and Steam wouldn't let us generate more during the weekend, so we had to find a temporary solution on next morning. Actually, Marion kicked us out of our beds really early so we'd have enough time to plan the new solution. Good thing she was there! Our friend Alex from Tiny Build suggested we use a system similar to theirs. We simply had to generate a QR code that would point to a MailChimp newsletter, so that we can contact everyone later and send them their keys. Brilliant! The only detail we added was a unique string code to each paper, so that one QR code couldn't be used by multiple people. We had to cross check them manually, which could be automated with a bit of PHP and a database. The new keys! They are more flexible, so we might end up using that for our next event. We managed to get 1,000 new keys printed at the on-site Fedex office in the morning, which was super helpful. By the end of the event, we handed out about 1,700 keys, of which about 500 have been redeemed at this date. 1,700 keys. Was it worth it? It might look like a lot of keys at first, but they probably won't get all redeemed in the end (fingers crossed for not too many resellers). We also saw a couple players win more than one Steam key. Because why not. For the attention it got us during PAX, we definitely think it was worth it. We actually saw a lot of people stop by out of curiosity, in part because of the huge crowd, in part because they could get something for free. As they stood there and waited for something to happen, they usually tried to make sense of the gameplay. By the time they would reach the controllers as the crowd rotated, most of them already knew how to play. In other words, those big "free keys" signs acted as some kind of salesman, stopping players and introducing them to our game. All of that without us having to say a single word! **UPDATE from Reddit** In terms of how many players saw the game or learned about its existence, it's a bit hard to estimate. We had at least 4 new players every 7 minutes on average. Considering the game was available to the public for about 8 hours a day, we had around 70 matches / day. 70 matches x 4 players = 280 players / day, so 840 for 3 days. Let's round it down to 800, so we get rid of players who played multiple times. We had around 800 players for the whole event. Knowing that we gave away 1700 keys, and that a lot of people watched the game and never got a key, we could estimate that at least 50% of all spectators got a key. It would mean that around 3500 people learned about Toto Temple Deluxe's existence at PAX. That doesn't include people winning a key just by watching and then talking about their experience to their friends. Now we can't say for sure how much more people the promotion attracted, but we feel like it's at least twice as much. Tournament system (elite only) On top of the showdown system, we also experimented with an "easy" tournament system. We say "easy" because we didn't want to manage names, lists, finalists, whiteboards, time, etc. The system we went with was a "ticket" system, where the winner of each match would not only be thrown into a showdown, but would also get a tournament ticket. Pretty sure Charlie would have traded his golden ticket for one of these. A tournament ticket would let you enter the one and only tournament we had each day at 5pm. First-come, first-served! We would then do 4 rounds of 4 players each, and then have the winner of each round play in the final match against all the other winners. So, technically, these 4 last players would be best players of the day. The big winner of the tournament would win a Juicy Beast t-shirt + would end up in the game as an unlockable cameo to replace the goat! The system worked well, as we only had one tournament each day (no need to check the clock every hour or anything), plus since it was first-come first-served, we didn't have to deal with name lists and whiteboards. It was a good system for quick and easy tournaments, but we doubt it'd work for anything bigger or more serious. Expenses Since it was our first big event, we had to invest in stuff we won't need to buy twice, like TV stands and promotional banners. It ended up a little bit expensive for the small budget we had, but we're still pretty happy with the results. Here's a breakdown of the costs, for a total of about $8,000. No, we won't pay for that. It's important to note that, out of the $2,380 for the PAX related fees, there was one specific invoice that could have been avoided. We had a little issue with the company that handles pretty much all the logistics at PAX (Freeman). Before ordering our TV stands, we called Freeman and explained that it was our very first PAX and that we had no idea how we could get the stands to our booth. We heard that we could have them shipped there, but we didn't know what the process was, or what were the details. The person we spoke with told us that we could simply have our equipment shipped at the convention center on a specific date, and they would take care of all the rest (get the stuff to our booth, etc). We were pretty surprised by how simple that was, and they confirmed that it was an included service for all exhibitors. We said "Really?", they said "Yes". We mentioned we had no idea how things work, so they must have told us everything we needed to know! Well, that was easy! We simply ordered our TV stands online and had them shipped at the convention center. When we arrived at PAX, everything was neatly stacked at our booth. Awesome! So on the last day of PAX, we receive a nice little invoice from Freeman, listing all the packages they had to carry to our booth. Since the TV stands weigh 175 lbs each, the invoice ramped up to about $900 USD... *spits coffee* Wait. What? The good news is that, after placing some complaints at their office twice, debating over the fact someone on the phone told us the service was included, and demonstrating that paying $900 for $1000 worth of equipment while we came by car from Montreal made no sense at all, we managed to get the invoice dropped to $380. It's still a lot of money very badly spent, but it's better than $900. Next time, we won't use any of Freeman's services by default. Heck, even using small rolling carts to move our equipment out after the show was expensive. What went wrong Not much actually, but there was still a couple things we'll do differently next time. 1,000 flyers / buttons weren't enough, we should have ordered 1,500. We should have printed more free keys from the start (at least 2,000). We had a lot of equipment to handle for just 3 people with a small car. The goat hats were cheap but wouldn't fit well on everybody. We should make better hats for the next event. Big media appointments didn't show up because of the snow / flights being canceled. Freeman charging too much for handling the equipment (and lying to us on the phone). What went right Overall, pretty much everything went right. We found a couple of new things that we'll probably try to repeat for next events though, like: AirBnB was way cheaper than hotels. We used a Karma to get really cheap wifi for the whole event. Boston was close to Montreal, so it was possible to go by car and save a lot of money. The 2 TV stands helped a lot and made it easier for everyone to clearly see the game. Giving away keys attracted a LOT of people to our booth. Using the QR code trick for the keys also got us a couple extra emails in our newsletter (over 500 for one day, but could have been more if we would have used it from the start). The tournament system worked well, it was an easy solution for quick and simple tournaments. Being positioned on a corner definitely helped, especially with the crowd we had. Having only one playable station was definitely easier to manage with only 3 people. So, was PAX East worth it? Hell yes! We would totally do that again. We've never had such an engaged and fun crowd before. We totally connected with players and it felt great! Hopefully you found something interesting in that super long post. If you have any questions, tips, suggestions or comments regarding our experience or the article, please share them in the comments below! Note: This article was originally published on the Juicy Beast blog, and is republished here with kind permission of the author Yowan Langlais.
  9. Substance Painter Review

    There are two ways to add details to a 3D model. For one, you can increase the number of polygons in a model to add expressive details. The popular modeling packages ZBrush and Mudbox are excellent at this, allowing users to sculpt exquisite models. But, this detail comes at a cost. Ultra high-res models, like those that are sculpted, are hard to animate and don't work very well in even the most advanced game engines. This brings us to the second way to add detail to a 3D model - with textures. An advanced set of textures can make even a simple sphere look incredible and with the use of normal maps, you can even simulate the sculpted effects of a model. The downside to textures is that they are hard to paint and apply to models. The typical workflow includes painting a texture and applying it to the model and then tweaking the mapping to make the texture fit the model and then return to touch up the texture, then rinse and repeat. This is a cumbersome process that takes a lot of time to get just right. This is where Substance Painter enters the scene. Substance Painter lets you paint directly on the 3D model with materials. All the major 3D packages include features that let you paint directly on the models, but they only let you paint with a single color or with a brightness value. Substance Painter lets you paint with complete defined materials and the paint strokes update all the required texture maps at once including diffuse color, brightness, specular, metal, etc. This is a huge benefit, allowing artists to paint a texture in a single package all at once without the whiplash of moving back and forth between various packages. Streamlined Workflow Once a model is loaded into the Painter interface, all its current textures are automatically identified and loaded with it. These can include normal maps, ambient occlusion maps, lighting passes, etc. You then specify the specific channels that you want to include. The options include the usual suspects such as Base Color, Height, Specular, Opacity, Roughness, and Metallic, but you can also include Emissive, Displacement, Glossiness, Anisotropic, Transmissive, Reflection, Ior and several user-defined channels. For each channel, you can specify the format to use when the texture is saved. After the channels are set up, you can then choose a material and begin painting. Each separate channel gets updated as you paint. You can also switch to solo mode to view and work with a single channel by itself. Once the texture is completed, you can export all the various channels with a single command. Each channel will share the project name and will have its channel name added on. Since you can view and verify the results directly within the Painter interface, there isn't any need to return to the originating modeling package. The files exported out of Painter can be loaded and used directly in the game engine. Advanced PBR Viewport Substance Painter isn't just a nice extension to your current 3d software (see Figure 1), it is a full-blown texturing package with its own interface, tools and an advanced viewport that can view realistic textures (PBR). Figure 1: The Substance Painter interface includes moveable panels of presets and tools along with an advanced viewport for viewing realistic (PBR) materials. The viewport gives you controls for adjusting the background environment map, the environment opacity and exposure. Using Substance Materials Substance Painter naturally uses the Substance Materials (Figure 2). Substance Painter comes with a large assortment of materials pre-installed and ready to use or you can purchase and add several additional material libraries. The software also lets you import and use any custom GLSL shaders that you've created. Figure 2: The default Substance materials included with the software offer a wide array of options. The nicest thing about the Substance Materials is that they are gorgeous. These shaders are built by material experts and they hold up really well under all kinds of lighting and environments. In addition to materials, the interface Shelf also includes a large assortment of brushes, decals and tools. These are alpha channel stencils that let you quickly add material details include bullet holes, zippers, frost, fur, bolts and rivets. Painting Tools The available painting tools include Paint, Eraser, Projection and Geometry Decals. Each tool can be customized and tweaked with a large assortment of controls including Size, Flow, Spacing, Angle, Jitter, Shape and Hardness. There is also a real-time interactive preview window that shows the results of the current settings. This is great for double checking your brush settings before you start to paint. There is also a Symmetry mode for applying paint equally on either side of a designated axis. Painting with Particles One of the coolest available features in Painter are the new particle brushes. Using these brushes, you can apply paint using thousands of tiny particles and these particles react to physical forces like gravity and wind so that weathering a model is easy with realistic results. Figure 3 shows a simple sphere painted with several different materials using the Physical Brush tool. Notice the complexity of the results. Figure 3: The ability to paint with particles is an amazing feature only available in Substance Painter. You can also choose the size, shape and effect of the particles. Some of the defaults include broken glass, burn, laser impact, leaking, fracture and veins. Each of these options moves the particles over the surface of the model in different ways and patterns. For example, if you choose the rain particle, then particles will fall from above the object and slowly drip down its side after impact painting the selected material as it flows. Painter includes several unique particle brushes, but it also includes an editor called Popcorn FX that can be used to create your own unique particles and effects. Post Effects Substance Painter uses the Yebis 2 middleware, developed by Silicon Studio, to enable post effects within the viewport. The available post effects include antialiasing, color correction, depth of field, tone mapping, glare, vignette and lens distortion. This lets you create your beauty passes directly in the software without having to export it and reload it in your modeling software. Exporting to Game Engines Once you are through with the texturing workflow, the completed bitmap textures can be exported to several different game engines including CryEngine 3, Unity and Unreal Engine 4. You also have the option to export the textures as PBR, PSD files or as any of the standard bitmap formats. Summary Substance Painter is a revolutionary new product that takes a lot of the busy work out of creating realistic textures and the new ability to paint with particles offers something that no other package has. The results are both stunning and easy to create. The one downside of this package is the weak set of included help files, but these are bolstered with a large set of youtube videos that you can access. Substance Painter is available in both Indie and Pro licensing options. A trial version is also available and can be downloaded from the Allegorithmic web site at http://www.allegorithmic.com.
  10. Most free-to-play games on mobile sell some sort of premium currency: gems in Clash of Clans, donuts in Simpsons Tapped Out, gold in Game of War and so on. I spent some time analysing how 32 games on the App Store sell their premium currency, and some interesting trends and tricks emerged. The Games Before we proceed, meet my data set. The 32 games analyzed are: 8 Ball Pool, Angry Birds Go!, Boom Beach, CastleVille Legends, Clash of Clans, Clumsy Ninja, CSR Racing, Disco Zoo, Dungeon Keeper, Empire, Farm Heroes Saga, Game of War, Hay Day, Hobbit: KoM, Jelly Splash, Juice Cubes, Kingdoms at War, Kingdoms of Camelot, Knights & Dragons, Modern War, Monster World, Moshi Monsters Village, Papa Pear Saga, Pocket Village, Puzzle & Dragons, Real Racing, Royal Revolt 2, Samurai Siege, Simpsons Tapped Out, Smurf's Village, Subway Surfers, Top Eleven. My method for selecting games was pretty unscientific... just a mix of games I had played, wanted to play, or were in the AppStore top grossing. Perhaps I'll expand on the list some day. Trends & Tricks 1) There is not much variety in pricing A lot of games offer the same 5 price points: GBP2.99, GBP6.99, GBP13.99, GBP34.99, GBP69.99. Those are the 5 big bubbles you see in the diagram above. (That's $4.99, $9.99, $19.99, $49.99, $99.99 for American readers). The most popular thing to do is to offer those 5 price points exactly with no changes, as is done in Supercell's Boom Beach for example. This exact price progression accounts for 1/5th of all games surveyed. If you also count price progressions that are within 1 price of the most popular (meaning they can be reached by either adding, modifying or subtracting just 1 price from the progression), you've got over 3/5ths covered. Extend it again to count price progressions within 2 prices and almost all games are accounted for. Very few games deviate from this formula... Moshi Monsters Village and Empire are tied for the most unique price points award, with each offering 4 unique prices that no other game does. It's nice to see someone trying something a little different, it will be interesting to see if their pricing catches on. 2) Players agree on a minimum price, publishers don't The only price that games seem to disagree on is the minimum to charge. I wanted to know: is it worth offering a minimum price cheaper than GBP2.99? The App Store most popular purchase ranking reveals some interesting information. In 100% of cases where GBP2.99 is the cheapest price, it is also the most popular purchase. 17 games had both a starting price cheaper than GBP2.99, as well as a price point at GBP2.99. For the majority (70%) of those 17 games, GBP2.99 was still the most popular price point. The same information visualized: It appears that even if you offer players a minimum price point cheaper than GBP2.99, chances are they will probably still prefer to buy the GBP2.99 option. But some questions remain... a) When GBP2.99 is the cheapest option, how many sales are lost from players only willing to pay less than GBP2.99? b) And how much revenue is gained from players that would have preferred a cheaper option but paid GBP2.99 anyways because there was no cheaper option? c) And most importantly, which is greater? A or B? Unfortunately I don't have enough data to answer it. But it did make me think back to a talk I watched long ago in which a publisher claimed "you'd be surprised how many people who are willing to pay a dollar for something, will also be willing to pay 5 dollars". He goes on to express regret for setting the price too low. If it was up to me, I would probably start pricing at GBP2.99 and then lower the price later through special starter pack offers if need be. It's always easier to lower a price than it is to raise it! 3) Buying more is not always a better deal for the player I assumed that by buying a larger currency pack, I would always get more currency per dollar spent. This is not always the case. The most significant example of this I came across was in Angry Birds Go: Pay 2.5 times as much, but only get 2.1 times as many gems. If you want 2,500 gems, you can save money by buying 2 x 1,200 gems + 1 x 100 gems for a total cost of GBP29.97 - a whole GBP5 cheaper than the 2,500 gems priced at GBP34.99. Those are savings you could use to buy another 300 gems. It's hardly an isolated incident. 70% of the games surveyed do this kind of thing. Sometimes, you see the same thing happening in the US store. Other times I think it has to do with price localization. When something is priced at $4.99 in the US it is typically sold for GBP2.99 in the UK. But for some reason $9.99 (double 4.99) becomes GBP6.99 (more than double GBP2.99) whereas it really should be GBP5.99. Take Hay Day for example. Not sure how or why this practice originated, but I didn't see any games adjust the premium currency given as a result so sometimes we end up getting less currency per GBP1 than you would get per $1. 4) 'Most popular' doesn't have to mean most popular As a player, don't trust everything publishers tell you. In only 1 out of 8 games that prominently displayed a "Most Popular" badge next to a currency pack, was that also the actual most popular purchase in the App Store ranking. Angry Birds Go, the only one to correctly label the "Most Popular" offer: Does this mean everybody else is lying? I guess if at some point in the past or in a different territory the offer tagged as "Most Popular" was actually most popular, then you could say it's just out of date. In any case, it wouldn't be in any publisher's best interest because in all 7 cases where the "Most Popular" was mislabeled, a cheaper offer was the most popular and who would want to encourage players to buy a cheaper pack? Apparently only Rovio is honest enough. 5) There's more than 1 way to calculate a bonus A few games like to tell players exactly how much of a better deal the larger currency packs are. There are different ways of calculating this which can make the discount sound more or less impressive. This first example is from Kabam's Hobbit game. The lowest amount of gems per GBP1 is found in the GBP6.99 pack: 100 / 6.99 = 14.3 currency per GBP1. At this exchange rate, for GBP13.99 you should get 13.99 x 14.3 = 200 currency. But they give you 240 for GBP13.99 instead of 200. 240 / 200 = 1.2, thus you are getting 120%, ie 20% more than you should get. The numbers have been arranged so as to maximize how impressive the bonus sounds while remaining 100% truthful. Not everybody calculates it the same way. Here's a different example from flare's Royal Revolt 2. Like Hobbit, they use the lowest exchange rate which again is from the GBP6.99 pack. At that rate, you should get 5,256 currency for GBP34.99 but instead they give you 7,500. This is where the method diverges from Hobbit. The extra amount of currency being given is 7,500 - 5,256 = 2,244. 2,244 / 7,500 = 0.299, so we can say that of the 7,500 currency you are being given 29% for free. First off, they could easily have rounded 29.9% up to 30%. More significantly, using Hobbit's method you could say that 7,500 / 5,256 = 1.43, therefore it is equally honest to say that you are getting 43% extra. Another interesting example is Monster World. If you try to calculate the bonus using any sane method, it just doesn't make sense. It had me stumped for a little while. Then I checked the US AppStore pricing and it all fell into place. If you use the US prices, the bonuses make perfect sense using the same method as Hobbit. So it appears that when the prices were localized, the bonuses were not. In reality, the bonuses in the UK AppStore are far less generous than their US counterparts (eg 7% UK instead of 25% US for 100 potions and 70% UK instead of 100% US for 4,000 potions). Final Words I hope this information helps anyone working on (or simply curious about) f2p game premium currency pricing. There's certainly a lot more going on with the prices than is obvious at first glance. The more I looked, the more I found. Still not satisfied? Try my spreadsheet. It's full of extra figures and graphs I didn't consider important enough to single out. And if you find something in the data I missed, let us know! Note: This post was originally published on Wolfgang's blog AllWorkAllPlay, and is republished with Wolfgang's kind permission.
  11. This subject is an incredibly important one that gets a lot less attention than it should. Most video game development guides and tutorials fail to acknowledge that communication is a game development skill. Knowing how to speak and write effectively is right up there alongside knowing how to program, use Photoshop, follow design process, build levels, compose music, or prepare sounds. As with any of those skills, there are techniques to learn, concepts to master, and practice to be done before someone's prepared to bring communication as a valuable skill to a team. Game Developers Especially Surely, everyone in the world needs to communicate and could benefit from doing it better. Why pick out game developers in particular? "...sometimes when people are fighting against your point, they're not really disagreeing with what you said. They're disagreeing with how you said it!" I don't meant to claim that only game developers have communications issues. But after spending much of the past ten years around hundreds of computer science students, indie developers, and professional software engineers, I can say that there are particular patterns to the types of communication issues most common among the game developers that I've met. This is also an issue of particular interest to us because it's not just a matter of making the day go smoother; our ability to communicate well has a real impact on the level of work that we're able to accomplish, collaboratively and even independently. Game developers often get excited about our work, for good reason, but whether a handful of desirable features don't make it in because of technical limitations or because of communication limitations, either way the game suffers for it the same. Whose Job is It? If programmers program, designers design, artists make art, and audio specialists make audio, is there a communication role in the same way? There absolutely is. There are several, even. The Producer. Even though on small hobby or student teams this is often wrapped into one of the other roles, the producer focuses on communication between team members, and between team members and the outside world. Sometimes this work gets misunderstood as just scheduling, but for that schedule to get planned and adjusted sensibly requires a great deal of conversations and e-mails, followed by ongoing communications to keep everyone on the same page and on track. The Designer(s). One way to think about the designer's role in game development is to communicate with the player through the game. Indicating what's the goal, what will cause harm or benefit, where the player should or shouldn't try to go next, expressing the right amount of internal state information - these are matters of a game's design more so than its programming. Depending on a game team's skill make up, in some cases the designer's only direct work with the game is in level layouts or value tuning, making it even more critical that within the team a designer can communicate well with programmers, artists, and others on the team when and where the work intersects. On a small team when the person mostly responsible for the design is also filling one or more other roles (often the programming) communication then becomes integral to keeping others involved in how the game takes shape. The Leads. On a team large enough to have leads, which is common for a professional team, the Lead Programmer, Lead Designer, or Lead Artist also have to bring top notch communication skills to the table. Those people aren't necessarily the lead on account of being the best programmer, designer, or artist - though of course they do need to be skilled - they're in that position because they can also lead others effectively, which involves a ton of communication in all directions: to the people they lead, from the people they lead, even mediating communications between people they lead or the people they lead and others. Some of the most talented programmers, designers, artists and composers that I've met have been quiet people. This isn't an arbitrary personality difference though. In practice it limits their work - when they don't speak up with their input it can cost their game, team, or company. The Writer. Not every game genre involves a writer, but for those that do, communication becomes even more important. Similar to the designer that isn't also helping as a programmer, a team's writer typically isn't directly creating much of the content or functionality, aside perhaps from the actual dialog or other in-game and interstitial text. It's not enough to write some things down and call it a day, the writer and content creators need to be in frequent communication to ensure that satisfactory compromises can be found between implementation realities and the world as ideally envisioned. Non-Development Roles. And all that's only thinking about the internal communications on a team during development. Learning how to communicate better with testers, players, or if you've got a commercial project your customers and potential new hires (even ignoring investors and finance professionals), is a whole other world of challenges that at a large enough scale get dealt with by separate HCI (Human-Computer Interaction) specialists, marketing experts, PR (public relations) people and HR (Human Resources) employees. If you're a hobby, student, solo, or indie developer, you've got to wear all of these hats, too! There are two main varieties of communication issues that we tend to encounter. Although they may seem like polar opposites, in reality, they're a lot closer than they appear. In certain circumstances, one can even evolve from the other. Challenge 1: Shyness The first of these issues is that some of us can be a little too shy. Some of the most talented programmers, designers, artists and composers that I've met have been quiet people. This isn't an arbitrary personality difference though. In practice it limits their work - when they don't speak up with their input it can cost their game, team, or company. It's unfortunately very easy to rationalize shyness. After all, maybe the reason a talented, quiet person was able to develop their talent is that they've made an effort to stay out of what they perceive as bickering. Unfortunately, this line of thinking is unproductive in helping them and the team benefits more from what they know. Conversation between team members serves a real function in the game's development, and if it's going to affect what gets made and how it can't be dismissed as just banter. Sometimes work needs to get done in 3D Studio Max, and sometimes it needs to get done around a table. Another factor I've found underlying shyness is that a person's awareness of what's great in their field can leave their self-confidence with a ding, since they can always see how much improvement their work still needs just to meet their own high expectations. Ira Glass has a great bit on this: It doesn't matter though where an individual stands in the whole world of people within their discipline, all that matters is that developers on the project know different things than one another. That's inevitably always the case since everyone's strengths, interests, and backgrounds are different. Challenge 2: Abrasiveness Sometimes shyness seems to evolve as an overcompensation for unsuccessful past interactions. Someone tried to speak up, to share their idea or input, just to add to someone else's point and yet it somehow wound up in hurt feelings and no difference in results. Entering into the discussion got people riled up, one too many times, so after one last time throwing hands into the air out of frustration, a developer decides to just stop trying. Maybe they feel that their input wasn't properly received, or even if it was it simply wasn't worth the trouble involved. As one of my mentors in my undergraduate years pointed out to me: "Chris, sometimes when people are fighting against your point, they're not really disagreeing with what you said. They're disagreeing with how you said it! If you made the same point differently they might get behind it." He was absolutely right. Once I heard that idea, in addition to catching myself doing it, I began to notice it everywhere from others as well. It causes tension in meetings, collaborative classroom projects, even just everyday conversations between people. Well-meaning folks with no intention of being combative, indeed in total overall agreement about both goals and general means, often wind up in counterproductive, circular scuffles arising from an escalation of unintended hostility. There are causes and patterns of behavior that lead to this problem. After 10 years of working on it, I've gotten better about this, but it still happens on occasion, and it's still something that I have to actively keep ahead of. It's understandable how someone could run through this pattern only so many times before feeling like their engaging with the group is the cause of the trouble. This is in turn followed by backing off, toning down their level of personal investment in the dialog, and (often bitterly) following orders from the action items that remain after others get done with the discussion. In either case - shyness or abrasiveness - and in any role on a team, nobody gains from having one less voice of experience, skill, and genuine concern involved. Simply tuning out isn't doing that person, their team, the game, or the players any real benefit. The issue isn't the person or their ideas, the issue is just how the communication is performed, and just as with any other skill a person can improve how they communicate. Failing to figure out a way to overcome these communications challenges can cause the team and developer much more trouble later, since not dealing with a few small problems early on when they're still small can cause them to grow and erupt later beyond all proportion. Listening and Taking to Heart You've heard this all your life. You'll no doubt hear it again. Hopefully, every time communication comes up this gets mentioned too, first or prominently. Listening well, meaning not just hearing what they have to say or giving them an outlet but trying to work with them to get at underlying meaning or concerns and adapting accordingly, is way harder than it sounds, or at least more unnatural than we'd like to think. You can benefit from practicing better listening. I can say that without knowing anything about you because everyone - presidents and interns, parents and kids, students and teachers - can always listen better. There's a tendency, even though we rationally know it's out of touch with reality, to think of oneself as the protagonist, and others like NPCs. Part of listening is consciously working to get past that. The goal isn't to get others to adopt your ideas, but rather it's to figure out a way forward that gains from the multiple backgrounds and perspectives available, in a positive way that people can feel good about being involved with. Don't Care Who Wins, Everyone Wins There's no winner in a conversation. This one also probably sounds obvious, but it's an important one that enough people run into that it isn't pointed out nearly enough. Development discussion doesn't need to be a debate. Even to the extent that creative tension will inevitably present certain situations in which incompatible ideas are vying for limited development attention on a schedule, debate isn't the right way to approach the matter. In one model for how a dialog exchange proceeds, two people with different ideas enter, and at the end of the exchange, one person won, one person lost. I don't think (hope?) that anyone consciously thinks about dialog this way, but rather it may emerge as a default from the kinds of exchanges we hear on television from political talking heads, movie portrayals of exchanges to establish relative status between characters, or even just our instinctive fight or flight sense of turf. Rather than thinking in terms of who the spectators (note: though avoid spectators when possible, as it can often pollute an otherwise civil exchange with defensive, ego-protecting posturing) or an impartial judge might declare a winner, consider which positions the two people involved would likely take in separate future arguments. If all of your prior references have led you to believe strongly about a particular direction, you only do that rhetorical position (and the team/project!) a disservice by creating opponents of it. Whenever we come across as unlikeable, especially in matters like design, art, or business where a number of directions may be equally viable, then it doesn't matter what theoretical support an option has if people associate it with a negative, hostile feeling or person. It doesn't matter what theoretical support an option has if people associate it with a negative, hostile feeling. Be friendly about it. Worry first about understanding the merits and considerations of their point, then about your own perspective being understood for consideration. Notice that neither of those is about "convincing" them, or showing them the "right" way, it's about trying to understand one another because without that the rest of discussion just amounts to barking and battling over imagined differences. You Might Just be Wrong Speaking of understanding one another: don't ever be afraid to back down from a point after figuring out what's going on, and realizing that there's another approach that'll work just as well or better. There's a misplaced macho sense of identity attached to sticking to our guns over standing up for our ideas - especially when the ideas aren't necessarily thoroughly developed and aren't exactly noble or golden anyhow. A smart person is open to changing their mind when new information or considerations come to light. You're not playing on Red team competing against Blue team. You're all on the same team, trying to get the ball to go the same direction, and maybe your teammate has a good point about which direction the actual goal is in. The other side of this is to give the other person a way out. Presenting new information or concerns may make it easier for them to change their mind, even if that particular information or concern isn't actually why they change their mind, simply because it can feel more appropriate to respond to new information then to appear to have been uncertain in the first place. Acknowledging the advantages in the position they're holding doesn't make your position seem weaker by comparison, it makes them feel listened to, acknowledged, and like there's a better chance you're considering not just your own initial thoughts but theirs too. When a point gets settled, whichever way things go, let the difference go instead of forming an impression of who's with or against you. (Such feelings have a way of being self-fulfilling. In practice, reasonable people are for or against particular points that come up, not for or against people.) When an idea inevitably gets compromised or thrown out, being a skilled communicator means not getting bitter or caught up in that. Don't take it personally. It's in the best interests of the team, and therefore the team's members (yourself included), that not every idea raised makes it into implementation or remains in the final game. Benefit of the Doubt, Assume the Best A straw man argument is when we disagree with or attempt to disprove a simplified opposition position. In informal, heated arguments over differences in politics or religious/cultural beliefs, these are frequently found in the form of disagreeing with the most extreme, irrational, or obviously troubled members of the group, rather than dealing with the more moderate, rational, and competent justifications of their most thoughtful adherents. This leads to deadlock, since both sides feel as though they're advancing an argument against the other, yet neither side feels as though their own points have been addressed. When the goal is to make a more successful collaboration, rather than to just make ourselves temporarily feel good, the right thing to do is often the opposite of setting up a straw man argument. Assume that the other person is coming from a rational, informed, well-intentioned place with their position, and if that's not what you're seeing from what has been communicated so far, then seek to further understand. Alternatively, even help them further develop their idea by looking for additional merit to identify in it beyond what they might have originally had in mind - maybe from where you're coming from it has possible benefits that they didn't realize mattered to you. If the idea you may be holding is different than what someone else is proposing, welcome your idea really being put to the test by measuring it against as well put-together an alternative as the two of you can conceive. If it gets replaced by a better proposal that you arrived at through real discussion and consideration, or working together to identify a path that seems more likely to pan out well for both of you, all the better. Your Frustration is With Yourself This is one of those little life lessons that I learned from my wrestling coach which has stayed with me well after I finished participating in athletic competitions. Most of the time when people are upset or frustrated or disappointed, they're upset or frustrated or disappointed mostly with themselves, and directing that at somebody else through blame isn't ever going to diffuse it. Even if this isn't 100% completely and totally true in every situation - sure, sometimes people can be very inconsiderate, selfish, or irresponsible and there may be good reason to be upset with them - I find that it's an incredibly useful way to frame thinking about our emotional state because it takes it from being something the outside world has control over and changes to focus to what we can do about it. Disappointed with someone violating our trust? Our disappointment may be with our failing to recognize we should not have trusted them. Upset with someone for doing something wrong? We may be upset with ourselves for not making the directions or expectations more clear. Frustrated with someone that doesn't understand something that you find obvious? Your frustration well may lie in your feeling of present inability to coherently and productively articulate to that person exactly what it is you think they're not understanding. If your point isn't well understood or received but you believe it has value that isn't being rightly considered, rather than assuming the other person is incapable of understanding it, put the onus on yourself to make a clearer case for it. Maybe they don't follow your reference, or could better get what you're trying to say if you captured it in a simple visual like a diagram or flow chart. Maybe they understand what you're saying but don't see why you think it needs to be said, or they get what you mean but don't see the connection you have in mind for what changes you think it should lead to. If your point isn't well understood or received but you believe it has value that isn't being rightly considered, rather than assuming the other person is incapable of understanding it, put the onus on yourself to make a clearer case for it. Clarify. Edit it down to summary highlights (people often have trouble absorbing details of an argument until they first already understand the high level). Explain it another way to triangulate. Provide a demonstration case or example. If there's a point you already made which you think was important to understanding it but that point didn't seem to stick, find a way to revisit it in a new way that leads with it instead of burying it among other phrases that were perhaps too disorganized at the time to properly set up or support it. Mistaking Tentative for Definitive Decisions can change. When they're in rough draft or first-pass, they're likely to - that's why we do them in rough form first! It's easier to fix and change things when they're just a plan, an idea, or a prototype, and the more they get built out into detail or stick around such that later decisions get made based on them, then the more cemented those decisions tend to become. There are two types of miscommunication that can come from this sort of misunderstanding: mistaking your own tentative ideas for being definitive, or mistaking someone else's tentative ideas for being definitive. During development, and as more people get involved, projects can change and evolve a bit to reflect what's working or what isn't, or to take better advantage of the strengths and interests of team members. If there was an idea you pushed for earlier in a project and people seemed onboard with it then, it's possible that discoveries during development or compromises being made for time and resource constraints have caused it to appear in a modified or reduced form. It might even be cut entirely, if not explicitly then maybe just lost in the shuffle. Before raising a case for it, it's worth rethinking how the project may have changed since the time the idea was initially formed, to determine whether it would need to be updated to still make sense for the direction the team and game has gone in. Sometimes the value of ideas during development is to give us focus and direction, and whether the idea survives in its originally intended form is secondary to whether the team and players are happy with the software that results. It may turn out to be worth revisiting and bringing back up, possibly in a slightly updated form, as maybe last time was at a phase in development when it wasn't as applicable as it might be now. Or it may be worth letting go as having been useful at the time, but perhaps not as useful now, a stepping stone to other ideas and realizations the team has made in the time that has passed. People get optimistic, people make planning mistakes, and people cannot predict the future - but it's important to not confuse those perfectly human imperfections with knowingly lying or failing to keep a promise. The other side to this is to make the same mistake in thinking about someone else's ideas: thinking they are definitive when they are necessarily tentative. This happens perhaps because of how far off the idea relates to the future, and how much will be discovered or answered between now and then that is unknown at the time of the initial conception and discussion. If a project recruits people with the intention of supporting a dozen types of cars, but during development reality sinks in and only three different vehicles make sense in favor of putting that energy into other development necessity, those things happen. People get optimistic, people make planning mistakes, and people cannot predict the future - but it's important to not confuse those perfectly human imperfections with knowingly lying or failing to keep a promise. If early in a project someone is trying to spell out a vision for what the project may look like later, don't take that too literally or think of it as a contract, look at it as a direction they see things headed in. Implementation realities have a way of requiring compromise along the way. Soften That Certainty Away A common source of fighting on teams is from a misplaced sense of certainty in an observation or statement which reflects value priorities that someone else on the team doesn't necessarily share, or especially when the confidently made statement steamrolls value priorities of someone else on team. Acknowledge with some humility that you only have visibility on part of all that's going on, and that the best you can offer is a clarification of how things look for where you're coming from or the angle you have on things. Leave wiggle room for disagreement. Little opening phrases like "As best as I can tell..." or "It looks to me like..." or "I of course can't speak for everyone, but at least based on the games that I've played in this genre..." may just seem like filler, but in practice they can be the difference between tying the team in a knot or opening up valuable discussion about different viewpoints. Consultant's Frustration School surrounds people with other people that think and work in similar patterns, with similar values, often of the same generation. Outside the classroom, whether collaborating on a hobby game project, joining a company, or doing basically anything else in the world besides taking Your Field 101, that isn't typically how things work. Often if your skills are in visual art, you have to work with people that don't know as much about visual art as you. If your skills are in design, you'll have to work with a lot of non-designers. If you have technical talents, you will be dealing with a lot of non-technical people. That is why you are there. Because you know things they don't know. You can spot concerns that they can't spot. You understand what's necessary to do things that they don't know how to do. If someone else on the team or company completely understood everything that you understand and in the same way, they wouldn't really need you to be involved. Your objective in this position is to help them understand, not to think poorly of them for knowing different things than you do. Help them see what you see. Teach a little bit. That is why you are there. Because you know things they don't know... Your objective in this position is to help them understand, not to think poorly of them for knowing different things than you do. Help them see what you see. I refer to this as the consultant's frustration because that's a case that draws particular emphasis to it: a company with no understanding of sales calls in a sales (or design, or IT, or whatever) consultant, because they have no understanding of that and that's why they made the call. A naive, inexperienced, unprepared consultant's reaction to these situations is one of horror and frustration - how on Earth are these people so unaware of the basic things that they need to know? The consultant is there to spot that gap and help them bridge it, not to look down on them for it. Meanwhile they're doing plenty of things right the specialist likely doesn't see or fully understand, because that's not the discipline or problem type that they're trained and experienced in being able to spot, assess, or repair. When you see something that concerns you, share that with the team. That is part of how you add value. You may see things that others on the team do not. Values Are Different Per Role The other side to the above-mentioned point is appreciating that other factors and issues less visible to your own vantage point may have to be balanced against this point, or in some cases may even override it. Frustration can arise from an exaggerated form of the consultant's frustration: a programmer may instinctively think of other roles on the team as second-rate programmers, or the designer may perceive everyone else on the team as second-rate designers, etc. This is not a productive way to think, because it's not just that they are less-well suited to doing your position, but you're also less-well suited to doing theirs. A position goes beyond what skills someone brings to move a project forward, it also brings with them an identity and responsibility on the team to uphold certain aspects of the project, a trained eye to keep watch for certain kinds of issues. The programmer may not be worried about the color scheme, the artist may not be worried about how the code is organized, the designer may not care about either as long as the gameplay works. ...a programmer may instinctively think of other roles on the team as second-rate programmers... That's one of the benefits of having multiple people filling specialized roles, even if it's people that are individually capable of wearing multiple hats or doing solo projects if they had to. In the intersection of these concerns, compromises inevitably have to get made. The artist may be annoyed by a certain anomaly in how the graphics render, but the engineer may have a solid case for why that's the best the team's going to get out for the given style of the technology they have available. The musician or sound designer may feel that certain advanced scoring and dynamic adjustment methods could benefit the game's sounds cape, but the gameplay and/or level designer may have complications they're close to about user experience, stage length, or input scheme that place some tricky limits on the applicability of those approaches. One of the reasons why producers (on very small student/hobby/indie teams this is often also either the lead programmer or lead designer) get a bad rap sometimes, as the "manager" that just doesn't get it, is because their particular accountability is to ensure that the game makes forward progress until it's done and released in a timely manner. So the compromise justification that they often have to counter with is, "...but we have to keep this game on schedule" which is a short-term version of "...but this game has to get done." If someone isn't fighting that fight for the project, it doesn't get done. Be glad that other people on a team, when you have the privilege of working with a good and well-balanced team, are looking out for where you have blind spots. Push yourself to be a better communicator so that you can help do the same for them. Too Much Emphasis on Role After that whole section on role, I feel the need to clarify that especially for small team development (i.e. I can total understand military-like hierarchy and clarity for 200+ person companies) role shouldn't pigeonhole someone's ability to be involved in discussions and considerations. While it's true that the person drawing the visual art is likely to have final say on how the art needs to be done (not only as a matter of aesthetic preference, but as a side effect of working within their own capabilities, strengths, and limitations), that does not mean that others from the team shouldn't be able to offer some feedback or input in terms of what style they feel better about working with, what best plays to their own strengths and limitations (ex. just because an artist can generate a certain visual style doesn't mean the programmer's going to be able to support it in real-time), and what they like just as fellow fans of games and media. Does one team member know more about animation than others on the project? Then for goodness sake, of course, that person needs to be involved in discussions affecting the implementation or scheduling of animation. But even if you're not an animator, that you've accumulated a different set of media examples to draw upon, and have an idea for how that work may intersect with technical, design, or other complications, there's still often value in being a part of that discussion (though of course still leaving much of the decision with whoever it affects most, and whoever has the most related experience). It's unhelpful to hide behind your role, thinking either "Well, I'm not the artist so that isn't my problem" or "Well, I'm the designer, so this isn't your problem to worry about." The quality of the game affects everyone who got involved with making it. You make a point of surrounding yourself with capable people that are coming from different backgrounds and have different points of view to offer. Find ways to make the most of that. A related distinction to these notes about role is the concept of servant-leadership. Rather than a producer, director, or lead designer feeling like the boss of other people who are supposed to do what they say, it can be healthy and constructive for them to approach the development as another collaborator on the team, just with particular responsibilities to look out for and different types of experience to draw from. They're having to balance their own ideas with facilitating those of others to grow a shared vision, they're trying to keep the team happy and on track, that's their version of the compiler or Photoshop. Handling Critique Productively When critique comes up - whether of your game after it's done or of a small subpoint in a disagreement - separate yourself personally from the point discussed. When people give feedback on work you're doing, whether it's on your programming, art, audio, or otherwise, the feedback is about the work you're doing, it's not feedback about you (even if, and let's be fair here, we could all honestly benefit from a little more feedback about ourselves as a work-in-progress, too!). Feedback is almost always in the interest of making the work better, to point out perceived issues within a smaller setting before it's too late to fix the work in time for affecting more people, or before getting too far into the project to easily backtrack on it. Sometimes the feedback comes too late to fix them in this case, in which case rather than disagree with it accept that's the case and keep it in mind to improve future efforts (this isn't the last game or idea you're ever going to work on, right?). Defensiveness, of the sort mentioned in the recent playtesting entry, is often counterproductive, or at lease a waste of limited time and energy. Systems and Regular Channels Forms and routine one-on-one check-in meetings can feel like a bureaucratic chore, but in proper balance and moderation they can serve an important function. People need to have an outlet to have their concerns and thoughts heard. People need to be in semi-regular contact with the people who they might need to raise their concerns with, before there is a concern to be raised, so that there's some history of trust and prior interaction to build upon in those cases and it doesn't seem like a weirdly hostile exception just to bring up something small. In one of the game development groups I've been involved with recently we were trying to narrow down possible directions for going forward from an early stage when little had been set into action yet. From just an open discussion, three of the dozen or so ideas on the whiteboard got boxed as seeming to be in the lead. When we paused to get a show of hands to see how many people were interested in each of the ideas on the board, we discovered that one of the boxed items had only a few supporters - those few just happened to be some of the more vocal people in the room. Even introducing just a tiny bit of structure can be important in giving more of an outlet to the less outspoken people involved with a project, who have ideas and considerations that are likely just as good and, as mentioned earlier, probably weighing different sets of concerns and priorities. Practice, Make Mistakes to Learn From Seek out opportunities to get more practice communicating. In all roles, and at all scales. As part of a crowd. In front of a crowd. In formal and informal settings. Out with a few people. Out with a lot of people. Now, for personal context: I don't drink. I don't go to bars or clubs. I've admittedly never been one for parties. This weekend I have no plans to watch the Super Bowl. I'm not saying you should force yourself to do things that you don't want to do. What I am saying is to look for (or create) situations where you can comfortably exercise your communication abilities. Whatever form that may take for you. Given a choice to work alone or work with a group, welcome the opportunity to deal with the challenges of working with a group. Attend a meetup. Find some clubs to participate in. When a team you're on needs to present an update, volunteer to be the one presenting that update. Communication is a game development skill. As with any other game development skill, you'll find the biggest gains in ability through continued and consistent practice. Recommended Reading A few books that I've found helpful on this subject include: How to Win Friends and Influence People by Dale Carnegie (1936) The 7 Habits of Highly Effective People: Powerful Lessons in Personal Change by Stephen R. Covey (1989) To Sell Is Human: The Surprising Truth About Moving Others by Daniel Pink (2013) Note: This article was originally published in 2 parts (Part 1, Part 2) on Chris DeLeon's blog "HobbyGameDev.com". Chris kindly gives permission to reproduce his content.
  12. How To Publish on GameDev.net

  13. It's been two years since we launched Taptitude on Windows Phone, and we're still going strong! Keeping with our tradition of openly sharing our download and revenue stats, we'd like to take a look back at the last two years to see how far we've come, and where we have room to improve. This article will primarily focus on the Windows Phone version of Taptitude. We've recently ported Taptitude to Windows 8, Android (Google Play) and iOS, but we haven't been out long enough to collect meaningful numbers. Later in the year we'll do a follow up to see how those platforms are turning out. Let's start with some high level observations and then dig into the details. Windows Phone continues to be a great market for indie developers. The mini-game collection model continues to resonate with our users. There is significant headroom for future growth. Downloads We recently announced that Taptitude has broken the 1 million download mark on Windows Phone. Let's take a look at how these were distributed. As you can see we had a fairly slow start with < 1,000 downloads per day for the better part of the first year. Near the end of the first year we saw a large spike which added over 200k downloads over a two month period. This spike (middle of the graph above) aligned well with a number of things that worked in our favor. The first was that Nokia started releasing solid Windows Phone devices and our daily downloads started to grow faster than normal, and second we worked our way up the top downloaded chart which has a feedback effect adding further to the download spike. After the spike died down we went back to < 1,000 downloads a day for the rest of the summer. Around the time Windows Phone 8 came out (fall 2012) we started to see the numbers pick up again. We've had a relatively long stretch where 2,500+ downloads per day has been the norm. Let's look closer at the last 5 months. As you can see we haven't dipped below 2k/day in quite a while. From time to time we get a spike over 5k and in some cases over 9k. The spikes correspond to getting featured in the marketplace, and the higher average is likely due in part by Windows Phone 8's growing marketshare. WP8 brought with it changes to the marketplace that feature top rated games. Taptitude is one of the highest rated games on the marketplace with over 26k ratings and a 4.7 star average. Crashes Microsoft provides crash reports in their Dev Center portal. We find it helpful to monitor these reports weekly and fix any obvious bugs before we ship the next update. Generally our crashes per day are reasonably low compared to our user base, but from time to time a bug will slip through and we'll see a spike. As you can see we generally have < 200 crashes per day. Around November of 2012 (a) we started seeing a huge number of crashes due to a bug with Bally Bounce (a popular mini-game). Unfortunately once a bad bug like this gets through our QA process, we have little hope of fixing it in a timely manner. The first day the bugged version was released we started getting reports and had a fix for the bug. We submitted the fix later that day, but since Microsoft's cert process takes nearly a week we knew we were going to pay. In a more mature platform, we would have been given the ability to roll back to the previous version instantly to stop the bleeding while the fix is in cert, but we weren't that lucky. In the following week many of our users picked up the bad version and we were helpless until the fix went in. Even then, some residual set of users who didn't update to the fixed version. It took over a month before our crashes were back down below 200 per day. On the bright side, we're now under 200 per day again, which is better than the 200 per day we were getting last year because our user base is considerably larger now. With 30,000+ active users, the 200 remaining crashes represents a broad spectrum of hardware malfunctions, hard to reproduce race conditions and memory leaks. We fix them as we isolate the problems but most of the low hanging fruit has been picked. Advertising Taptitude is still primarily an ad-supported game, and we've enjoyed considerable success pursuing this business model. We keep things simple; showing a single ad on the screen at all times, and cycling once every 30 seconds. Users can remove the ad by purchasing Taptitude Gold from the in-game store. Over the last two years we've grown steadily up to ~40 million impressions per month. We had a dip after falling out of the top downloaded chart, but have since worked our way back up to a new high of nearly 50m impressions per month. We haven't increased the number of impressions per user per minute, so the growth is coming from an increase in both active users, and time-in-game. While impressions are growing, unfortunately eCPM (dollars per 1000 impressions) has been on the decline. This has been widely reported by other users of Microsoft's pubCenter Ads. The data from the first year averaged in excess of $1 eCPM, however this was when we were first ramping up, so the revenue wasn't ridiculous. The second half of this year has been netting us in the area of $0.35 eCPM, which some say is good compared to other games at the same time period. The combination of increased impressions and decreased eCPM has almost exactly cancelled each other out. You can see from the graph above that our monthly revenue from Taptitude is pretty steady around $15k/month. We peaked (a) at the end of our first year with a $40k month due to good eCPM (~$1) and great impressions (~40m). This dipped (b) mid last year due to a bug where we weren't showing ads for over a week. Not our bug, mind you, but one Microsoft kindly left in the pubCenter control. When you submit an app to the store it scans your app and looks for certain things to trigger capabilities. One update (of the over 100 we've done so far) we removed an unused component that happened to load the web browser control, which caused us to lose the browser usage capability. That was expected, but unfortunately pubCenter manually checks for this even though the XNA version doesn't use the web browser. We worked around the bug, but not after losing substantial revenue. The important thing to take away from the graph above is that games don't have to have a hockey stick revenue graph. We've seen tons of games that have a good start, but don't retain users and revenue dies off after a month or two. Many of them spike way higher than Taptitude, but the important thing is the area under the curve. We have optimized Taptitude to be the go-to game that you come back to every day for a long period. In-game stats show that many of our users haven't missed a single day of play time in well over a year, and this has led to fairly steady income. In App Purchase We added IAP to Taptitude at the beginning of 2013 and have seen pretty steady uptake. IAP still accounts for a very small fraction of our revenue (~5%), so we can't say we've nailed this business model yet. We feel like Taptitude's rich virtual economy would mesh well with the IAP model; however we're hesitant to push it too far for fear of turning off customers. We'll dive deep into IAP in another article, but for now let's just say we're working on monetizing IAP better in a customer friendly way. Summary Now that we've seen the numbers, let's look back at my original observations: 1. Windows Phone continues to be a great market for indie developers. Taptitude has been more successful than we had ever dreamed, and even after two years we're still bringing in significant revenue off of Windows Phone advertising. While eCPM has dropped, the market has grown, and we're happy with the results. IAP was added in WP8, which opens up new revenue streams, but we've yet to fully realize this potential. 2. The mini-game collection model continues to resonate with our users. Taptitude has grown from a small collection of only 5 mini-games to over 80 mini-games with increasing quality and complexity. We can see from in-game stats that our users are very sticky, some of which have put many days of in-game time into Taptitude. We have optimized for bite sized fun, getting users to come back every day, and continuously expanding the game so users stay engaged for months. This has yielded consistently high impressions per user. 3. There is significant headroom for future growth. While Taptitude is doing well on Windows Phone, we've only just begun. We've recently ported Taptitude to iOS, Android, and Windows 8 and we look forward to having enough data to compare. By some reports, Windows Phone only has ~5% of the market share, so with the addition of Android and iOS we could be looking at substantial gains in the next 6 months to a year. We've nailed the ad-supported model, but we have a lot of work ahead to monetize IAP without impacting the game negatively. Conclusion We hope sharing this data will help other indies understand the market and make better decisions about how to roll out fantastic mobile games. It's too tempting for most developer to see huge numbers on iOS/Android and think that these are the only platforms worth targeting. We're living proof that Windows Phone, even with its smaller market share, is a great platform to kick start your game project while you get it ready for the big (and more competitive) markets. If your game isn't developed with a million dollar budget, you might consider a similar strategy.
  14. Autodesk Maya 2015 Review

    Autodesk recently released Maya 2015. It took a little longer to get this release out than in years past, but the extra time was worth it. Maya 2015 is packed full of new features, new effects engines, improvements and updates that make it easily the best version ever. The developers at Autodesk have really gone above and beyond with this release. In particular for gamers the new simulation tools, including Bifrost for liquids and Bullet Physics for rigid and soft-body dynamics, add a huge level of realism to animated scenes. For background scene population and control over hair and fur, the new XGen system is remarkable and the ability to create shaders directly in Maya with the ShaderFX Editor is a huge time-saver. Couple these new features with the ability to see all these effects in real-time within Viewport 2.0 and you have one strong tool for game artists. Bifrost Simulation Maya 2015 introduces a new liquid simulation platform called Bifrost. It was initially created by Naiad and has now been fully integrated into Maya 2015. It is quite powerful and surprisingly easy to use. To create a liquid effect, you simply need to select a geometry object and choose the Create Liquid option from the Bifrost menu. Then you need to select the collision objects and change settings as needed. Bifrost will automatically compute all the splashes and spray from the water particles caused by the collisions and their fall due to gravity. You can also specify animated geometry to act as emitters and accelerators for the simulation. These emitters and accelerators are used to add forces to the liquid object to create flowing rivers and gentle waves. Figure 1 shows an example of the type of results that Bifrost can create. Figure 1: Bifrost makes it possible to create amazing liquid effects. Once the simulation is started, the solution is computed in the background using a Scratch Cache and the available frames are shown in green on the animation timeline while frames still to be computed are displayed in yellow. This lets you continue to work while the simulation is still being computed. When you are satisfied with the results, you can save out a User Cache so the simulation doesn't need to be re-computed each time you scrub the timeline and for rendering the simulation. The resulting water particle motion from the simulation can be viewed in the viewport if Viewport 2.0 is selected . This provides a way to view and tweak the simulation without having to render out frames. If you are unsure where to start, the Visor has several Bifrost examples to get you started. XGen Particles The new XGen system gives you great control over the placement and style of curves, spheres and instanced geometry particles on the surface of other objects. This is a great system for creating unique hair and fur styles. It can also be used to populate an environment with instanced models such as trees and flowers. Custom objects can be exported as an archive and then read back in as multi-instances spread across the face of the scene and multiple archives can be selected and used together. For all the instanced geometry, you can control the length, width, depth, tilt, twist and density of their placements or even define them using expressions. The XGen system also includes an array of brushes that are used to edit various attributes of the applied objects. These brushes include the ability to attract, repel, part, bend, twist, smooth and add noise, among other things. The system includes support for Ptex maps that can define areas clear of particles. Figure 2 shows a scene where the plants are populated using the XGen system. Figure 2: The XGen system is great for adding a variety of plants to the current scene. Bullet Physics Dynamic animations are a breeze with the new Bullet Physics features. Simply select an object, choose an effect and click the Play button. The constraints and forces, such as gravity, are automatically applied and a full set of settings are available for tweaking the results to get just the motion you want. The Bullet engine includes support for both rigid and soft-body objects and ragdolls. Be aware that the Bullet engine has to be loaded using the Plug-In Manager before it can be used. Selected objects can be set as Active Rigid Body objects or Passive Rigid Body objects. Active objects will react to gravity and will collide with other rigid body objects. Passive objects will stay put and will collide unyielding with active objects. You can also animate rigid body object to interact with other objects such as a meteor impacting a group of rocks. Using the Shatter effect, you can break solid objects into pieces which break upon on impact. ShaderFX Editor Shaders can now be created within Maya using a real-time shader editor called ShaderFX. This node-based editor lets you connect nodes together and see the results directly within Viewport 2.0. The ShaderFX Editor supports both OpenGL and DirectX 11. Once a shader is applied to an object, you can select the Open ShaderFX option in the Attribute Editor for the shader node. Within the editor, you can add nodes using the list to the right or you can right click and select them from the menu. Input and output channels are connected by simply dragging between them and color coding between the channels makes it easy to know which channels are compatible. Each node also has a preview that you can access. Shaders can be saved to the HLSL, GLSL and CgFX formats. Viewport Improvements Maya's Viewport 2.0 now supports viewing dynamics and particles. This is a huge benefit for simulations allowing you to see the results without having to wait for the render. There is also support for viewing Paint Effects, Toon shading, nCloth, nHair, nParticles and fluids. There are also controls to enable and disable Ambient Occlusion and Anti-Aliasing on the fly. Viewport 2.0 is now set up to be the default renderer in Maya 2015. Figure 3: Viewport 2.0 supports particles and makes it easy to tweak effects to get the right look without having to render the scene. Image courtesy of Autodesk For navigating an existing scene, the new Walk tool is awesome. Using this mode, you can move through the scene as if you were playing a first-person shooter using the S, W, A and D keys. This allows navigation of the scene using a method that is familiar to most gamers. Another navigation option specifically for tablet users is support for Multi-Touch devices including certain Wacom, Cintiq and MacBook systems. Using the common two-finger pinch gesture, you can zoom in and out of the viewport. You can also tumble the scene with a swipe and return to home with a two-finger double-tap. Texture and Shrinkwrap Deformers Texture Deformers provide an easy way to view and use displacement maps. Once applied you can control the amount of influence the texture has over changing the surface of the model. Another new deformer is the Shrinkwrap deformer that wraps one object around another. This is a great way to apply flat textures to the surface of another object like a decal or to completely engulf an object like armor on a character's arm would. OpenSubDiv Support Maya 2015 now supports Pixar's OpenSubDiv mesh smoothing method. This allows for much faster playback of animated meshes over legacy smoothing methods. This is possible because OpenSubDiv utilizes parallel CPU and GPU architectures. Support for OpenSubDiv lets you view animated mesh-smoothed characters and objects as smoothed meshes without slowing down the frame rate. Modeling Improvements If you look closely at the manipulator for moving and scaling, you'll see that there are now plane handles that let you move and scale within a plane along two axes at once. The Quad Draw tool has been updated with some great new features including Edge Extend and Auto Weld. Edge Extend lets you create new polygons by extending a current edge and when vertices are place near one another, they can automatically be welded together when Auto Weld is enabled. There is also a new Relax brush that smoothes the mesh across the surface. The Make Live tool lets you set a scanned or dense mesh as a surface to follow. This makes tasks such a retopology much faster and easier. The Quad Draw tool also includes a new setting that lets you customize the hotkeys for controlling the different tool features. You can also customize the color display that is highlighted when using the different tools. The Split Polygon tool has been combined with the Interactive Split tool and the Cut Faces tool to create a single cutting tool called the Multi-Cut tool. This single tool can now be used to cut, split and combine polygons without having to switch to different tools. Beveling has been improved allowing for non-destructive bevel of corners. Boolean operations have also been improved to be faster and cleaner. There is also a new Convert Selection option to change the current component selection to the edges or vertices that make up the perimeter of the selection. UV Updates The UV Editor has also been improved with several great new features. The new multi-threaded Unfold3D mapping option lets you define cuts and then automatically unfolds the mesh for painting. The results are good because neighboring faces are kept together. There is also an Optimize feature that cleans up the UVs that are twisted along with a Distortion shader that lets you visually see the areas that are tightly bunched with red areas showing the stretched UVs and blue areas showing the compressed UVs, as shown in Figure 4. Figure 4: The Distortion shader quickly shows which UVs are stretched and compressed. Image courtesy of Autodesk There are also several new editing features such as Nudge UVs, Normalize: Scale on Closest Tile, and Create UV Shell, which creates a UV shell from the current selection. The UV Editor also includes support for multi-tiled textures that are common in Mudbox and ZBrush. These tiles are presented in a grid and you can easily move UV shells between the different tiles. Character Skinning Skinning characters is one of the trickiest aspects of character modeling, but the new Geodesic Voxel Binding feature handles this task by allowing for some flexibility when dealing with overlapping objects. It can also work with multiple objects. The system voxelizes the skeleton and the skin mesh and computes a good fit. This results in skin weights that are more realistic than other binding options and the system is compatible with most game engines. Summary Since Maya is used in so many different industries, it is common to see features custom-made for other types of users. However, with this release, game developers should rejoice because almost every new feature is specifically designed to help game creators be more efficient and cool effects just got easier to do. From the advanced simulation tools like Bifrost and Bullet Physics to the new ShaderFX Editor and improved Quad Draw and Multi-Cut tools, game developers have a lot to be happy about. And all the back-end engines wouldn't be that helpful if you couldn't see their results, but the new Viewport 2.0 improvements make it possible to see all these simulation improvements directly in the viewport letting you tweak the effect until it is just right and rendering it out only once. Maya 2015 is available for Windows, Linux, and Macintosh OS X. For more information on any of these products, visit the Autodesk web site located at http://www.autodesk.com. A free trial version is also available at http://www.autodesk.com/freetrials.
  15. Like operating systems, software office suites, and computers themselves, there exist a large variety of computer languages. And the reason for such variety is the same as the reason for variety anywhere else -- because there is not a single solution that solves all problems. Some languages are better at raw speed. Some languages make it easier to write crash-resistant code. Some languages are very good at parsing strings of text and work effectively on a server. Some languages have very large corporate investment. And some languages still exist because they are compatible with large amounts of existing code that is impractical to rewrite. Your choice of language will affect the rest of your project, and it's impossible to change languages in the middle of a project without a complete (or at least very extensive) rewrite, so it is not a choice you should make lightly. It is also not a choice that you should allow to be colored by your own personal preferences or the urging of friends. Your choice of computer language for your project should be well-researched and pragmatic. What counts most is the quality of your results and not that the language be worthy of your programming skills. This article will cover some of the languages that are popular with game programmers. This list is neither complete nor deep. This article is intended to give you a bird's eye view of the most popular game development languages out there along with a short overview and a few situations where they would be a good or a poor choice for a project. One final note before you read the list. This list does include plenty of terminology that might not be familiar to you as a beginner, and there simply isn't enough space to define everything. It is recommended that you keep Wikipedia handy for the terminology with which you are not yet familiar. This article was originally published to GameDev.net back in 2000. It was revised by the original author in 2008 and published in the book Beginning Game Programming: A GameDev.net Collection, which is one of 4 books collecting both popular GameDev.net articles and new original content in print format. We'd like to update this document once again from its 2008 version, so please use the comments to add new language sections and we will place them in the article. Additions and updates to current sections are welcome as well! C The C Programming Language is either the direct parent or a heavy influence to every other language discussed in this article. While it was itself derived from a couple of other languages that have fallen into disuse, C is now considered to be one of the "root" languages of computer science. Some other languages that predate C (COBOL, FORTRAN, Lisp, Smalltalk) are still in use today and owe nothing to C, but just about every language that's been produced since the 1980's owes at least some of its syntax to C. C is a classic "brace language", which is to say that it's a structured goto-less language that uses the open and closed curly-braces to group statements together. It's a structure that's repeated in many of the languages that follow (C++, Java, C#, ActionScript, PHP). One advantage of the endlessly-imitated structure of C, braces and otherwise, is that once you understand how things are done in C, you can carry them over to the other languages with almost no changes. The if(), while(), and for() statements in C and PHP, for example, are basically identical. For that very fact alone, it is recommend that you familiarize yourself with C syntax, as it is something that you can keep with you. Advantages: C is good for writing small fast programs. It is easy to interface with assembly language. The language itself as well as the library routines are standardized, so moving programs to other platforms can be a straightforward process if you plan ahead. Disadvantages: The ability to write small programs quickly also works against C, as C is not normally used for object oriented programming[sup][note][/sup], which is a method of structuring your code that's better suited to large programs with distributed development, and large C programs can grow disorganized easily. While many very large projects have been written in C (Unix, Windows, Oracle), managing a large C-based project requires more discipline than in languages that are built around more modularity. Portability: While the core of the language itself and the ISO function calls are very portable, these calls are limited to control flow, simple memory management and simple file handling. Modern user-interface constructs, like menus, buttons, dialog boxes, etc., are not portable between platforms, so you will need to either write your code to work with a third-party UI toolkit or plan to write your user-interface twice. While the language was ahead of its time when it was created, the C library is showing its age. Many non-trivial library functions, like memory management and strings, have a simplistic syntax that has been significantly tuned up in the language's successors. While C has been redesigned and re-standardized several times to keep up with the times, some of the syntax is counterintuitive by necessity. Some of the quirkier language constructs remain for the sake of compatibility with existing code. Suitability for Beginners: Not very good. While the core of C is fairly compact and easy to grasp, many of C's library calls are antiquated and are easier handled in some of its successor languages. Resources: While Kernighan and Ritchie's The C Programming Language is the "classic" book on the subject, the book does cover topics fairly quickly, and it might be too quick for a rank beginner at programming. Other well-recommended books include C How to Program, C Programming: A Modern Approach, and C Primer Plus C++ C++ is C's most established "child" language. It was designed in the 1980's as an extended version of C with support for "classes"[sup][note][/sup], which are abstract data structures that aggregate primitive data types and algorithms into something that is better able to model real-world (or in the case of games, simulated-world) objects. C++ classes also support the concept of "data hiding" in which you can hide the underlying implementation of an object from the rest of your program. While this method seems a bit inscrutable, it is extremely useful when programming in a team environment. It allows you to agree on how the object's interface is intended to work without regard as to how the object works internally. It's a bit like saying "I'm giving you a job, and I don't care how you do it as long as it gets done, and the result looks the way I want". Advantages: Supports the object-oriented (OO) paradigm very completely, which is much better than C for supporting large projects. Unlike C, it contains a very well-designed library of common data structures and algorithms. Disadvantages: The syntax of C++ has grown larger and more complicated with each iteration, and the language is absolutely byzantine now. The syntax lends itself very easily to abuse and, while the language does support team programming very well, its huge and deep syntax can make code difficult to read. Portability: Despite its roots in C, C++ has better portability than C[sup][note][/sup]. This is because most modern portability toolkits are implemented as C++ object libraries rather than the old-style C function libraries. In addition, C++'s standard library and very useful Boost library is very standardized and cross-platform despite the complexity of both. Suitability for Beginners: While the memory management and I/O operations in C++ are significantly easier to understand than C, C++ has a pretty high learning curve just from its sheer size. Thankfully, one doesn't have to learn the entire language to be productive with it. Resources: A perfect beginner's book for C++ is C++: A Dialog by Steve Heller. It's very well-paced and approachable, and it's perfect for beginning programmers. For a more comprehensive approach, Bruce Eckel's monumental two-volume Thinking in C++ series will tell you all you need to know about C++ in only 1,600 pages. As an added bonus, these books are available for free download. Google for them, and you should have no trouble finding the official sites. There has since been a new standard released, C++11[sup][note][/sup] (to be followed by C++14) that should be considered when learning this language. See the reference note on some ideas for resources C or C++: Short of "DirectX or OpenGL", this is one of the most-asked questions when getting ready to learn the language. C++ is, with a couple of very minor exceptions, a proper superset of C. That means that all that C does, C++ does the same. Every C++ compiler will also compile C, and C-only compilers are very hard to find nowadays. While those facts might make it seem logical to start with C and then learn the "rest" of the language later, it is a better idea to learn classes and OO programming early on rather than having to "unlearn" techniques that don't model the environment (real or simulated) very well. Objective-C Objective-C is an object orientated, strongly typed programming language with a dynamic runtime. In it's nature, it is a superset of C. It inherits the majority of it's basic syntax rules from C, while having some more major changes to the structure as well. That for instance would include method calls, overall definition rules and so on. Objective-C is the primary language for MAC OS X and iOS programming and is an Apple exclusive. It supports a wide variety of development techniques, functionalities, libraries and many other bonus features that make this language stand out (for more information, see reference). The language supports a really wide range of built-in libraries for handling 2D and 3D graphics (OpenGL based) which can help a junior game developer in building his/her first game bu using a powerful, yet native solutions. Other libraries help game development as well, especially for mobile. Another standout feature is the reference counting garbage collector, working in a close collaboration with the very sophisticated memory management system (see reference). Advantages: Objective-C is a powerful superset of C and can produce and run very powerful and flexible applications. It can utilize C/C++ code and through that it is easy to port new projects and extend the power of already existing such. The language possesses a really wide variety of helpful libraries and one of the best development environments in the face of Xcode. This is a powerful OOP language that can be used in many ways. Disadvantages: Objective-C is an Apple exclusive, thus you need an Apple computer, running the latest version of Mac OS X in order to develop your applications. Another thing to note is that some of the syntax rules of the language can end up being confusing for the beginner to intermediate programmer. The method calls are far from the standard, the class definitions are also going to cause some confusion for beginners that have no experience in C/C++. Something else to note - knowledge of memory management on a higher level is absolutely required if you plan to develop apps for iOS. Portability: There is none. What ever is written in Objective-C stays within the Apple products. You cannot port an Objective-C project to another platform without completely re-writing it in another language. The bottom line here is - Objective-C is only suitable for Mac OS X and iOS development. Suitability for Beginners: Objective-C is not the most beginner friendly language, though it's not the hardest one as well. You'll have an easier time learning C# or Java, yet getting proficient in Objective-C is relatively easier then C++. A beginner will most certainly need to put in a lot of reading into concepts such as memory management, so on and so forth and that can be a painful process to go by if you are just starting out, however it will pay out in the long run. Resources: Aside from the official Apple guides, there are a lot of free e-books on onlineprogrammingbooks.com - http://www.onlineprogrammingbooks.com/objective-c/ References: Objective-C basics: http://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/Introduction/Introduction.html http://www.otierney.net/objective-c.html http://mobile.tutsplus.com/tutorials/iphone/learn-objective-c-day-1/ Objective-C memory management: https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/MemoryMgmt.html http://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmRules.html Objective-C for game development: http://people.oregonstate.edu/~doneb/downloads/iPhone%20Game%20Development%20Developing%202D%20%26%203D%20games%20in%20Objective-C~tqw~_darksiderg.pdf http://www.idevgames.com/articles/for-beginners/2 Objective-C compared to Java: http://assoc.tumblr.com/post/28261068461/objective-c-versus-java Objective-C compared to C++: http://www.mactech.com/articles/mactech/Vol.13/13.03/CandObjectiveCCompared/index.html General iOS development compared to Android development: http://java.dzone.com/articles/android-vs-iphone-development Java Java is, for practical purposes, the first "post web" language. While some languages like Perl suddenly found their string-handling capabilities to be a natural for retrieving values and sending display-able HTML to web browsers, Java initially found its footing in the browser itself, first in the very interesting but monumentally quirky HotJava browser (written in Java itself), and later in the form of extensions for existing browsers. Java, while on its face structured similarly to C and C++, behaves very differently on the "back end". The Java compiler, rather than compiling Java source code to native machine-code, compiles to "bytecode" that is run by a Virtual Machine or VM. The Java bytecode is an assembly language of sorts, but it is not an assembly language that is married to a particular processor. The Java VM, which is actually a runtime interpreter of bytecode, will then interpret the bytecode for your machine's target processor. The advantage of this approach is that Java bytecode can be moved from machine to machine and executed without changes provided that the target machine has a compatible Java VM or, as Java promised, "write once, run everywhere". The disadvantage of this approach is that Java bytecode is not native machine code, and while technologies such as "just in time" compilers can improve VM performance, the fact is that you're doing some level of interpretation at runtime, and that does entail a minor, but measurable performance hit. The other disadvantage is that realities of Java have not lived up to the language's early promises. While the idea of executing games inside web-pages captured everyone's hearts almost immediately, the reality quickly set in that Java VM's aren't as compatible with each other as they should be, and a Java application or applet written on one machine using a particular VM may or may not run nicely on another machine with another VM version. "Write once, run everywhere" was snarkily renamed "write once, port everywhere", which is to say that once you finished writing your Java code and it's running beautifully on one platform, you then had the non-trivial task of making sure the application will actually run well and look nice on all systems. The third disadvantage of Java came with its GUI. While the first "pass" at making a Java GUI used native OS controls (buttons, scroll bars, etc) and was reasonably small and fast, it wasn't very deep. The next pass, Swing, looked better but performed worse and was entirely different from the original controls. And, worst of all, Sun (Java's parent) was slow to add OS features that had been in existence in the underlying OS for years, like support for ClearType font rendering. Hence, Java applications always seemed to look a few versions away from state-of-the-art. There is one place, though, where Java took a good hold and Java's advantages outweighed its disadvantages, and that was in server programming. One big advantage of a VM is that since it's not an actual processor but just a simulation of one, crashing the VM isn't much of an issue. If you do manage to completely confuse the Java VM, that doesn't really affect the parent operating system, and you can close and restart a session without having to reboot the entire machine. Couple that with the fact that Java's memory management scheme is a generation evolved from that in C++ and C, and suddenly problems like allocating memory without releasing it back to the system became much less of a problem. And a system like this is perfect for a server environment. A server can pop up and kill VM's as necessary without affecting the underlying OS. Also, the GUI problems don't really apply, as it doesn't matter if your server software doesn't look spectacular unless you just want to impress server-admins. Today you'll find many commercial Massively Multiplayer games that use Java on the server side. A good example would be the multiplayer games by Three Rings that are fully Java on the client as well as the server-side. Another place where Java has very strongly caught on is in the mobile phone market. J2ME[sup][note][/sup] (Java 2, Micro Edition) is a "miniature" version of the Java VM with a significantly truncated class library which is designed to run on mobile phones and other small devices. In fact, if you include the mobile phone demographic, Java is one of the most popular platforms in existence. Advantages: Java's Virtual Machine coupled with its memory management and automatic collection of no-longer-needed memory allows you to make software that is very robust and crash-resistant. It also has a strong tradition of extensive documentation[sup][note][/sup]. Disadvantages: Java's "write once, run everywhere" promise wasn't fulfilled. The Java class libraries have been rewritten multiple times without removing old calls, so while the libraries are very backward-compatible with old code, there seems to be three ways of doing everything, all but one of which are discouraged as being "obsolete". Portability: Fairly good, but not as good as it should have been. Making an application in Java that is portable and uses the underlying OS's latest features is almost as difficult to do in Java as in C++. Suitability for Beginners: Reasonably good. While figuring out the "right" way to do things without bumping into a deprecated object is a bit of a pain for beginners wading through the language, the core of the language itself is well-designed and easy to understand. Also Java is a standard language for many university courses. Resources: Oracle Inc., the Java authority, has plenty of great resources for Java programmers. .NET Languages (specifically C# and Visual Basic) .NET (pronounced "dot net") is basically Microsoft's answer to the Java VM. Actually, .NET is the name for the overarching technology. The actual VM's name is CLR (common language runtime), and everything that was said earlier about the Java VM also applies to the CLR with one significant exception: the CLR was designed from the ground up to not be "married" to a single language, as Java was. And because of this, there are a whole host of languages that use the CLR to do the back-end processing. Everything from ancient legacy languages like COBOL and FORTRAN to modern languages like Python can target the CLR. Mind you, some of the CLR projects out there are little one-man projects, so don't get too excited if you find your favorite language in a CLR version, as some of the compilers are far from mature. C# and Visual Basic, both developed by Microsoft, are the most popular CLR-based languages. C# is a language clearly derived from Java, and it shares about 90% of Java's syntax despite sounding more like something derived from C or C++. C# does have several nice language extensions that Java has been slow to add as well as a completely rewritten class library. Visual Basic, which was briefly renamed VB.NET, is a CLR implementation and replacement for Microsoft's established and popular Visual Basic environment. While it is still called "Basic" and is no longer in all-caps, it bears very little resemblance to the old BASIC interpreters that were burned into the ROM of just about every computer sold in the 1980's. The syntax is now structured similarly to the other languages in this list, although it still doesn't use braces to group statements. It also uses the more object-oriented "dot notation" to call functions rather than the large function library of the pre-CLR versions of the language. Advantages: While Java does have a couple of minor efforts to compile languages to the Java VM, the CLR is designed from the ground-up to support this. Hence, there are several CLR-based languages, and it's relatively easy to get them to communicate with each other. The .NET technologies are very well-supported by Microsoft's Visual Studio environment, which is a very mature and feature-rich development environment. C# is the premier programming language for Microsoft's XNA technology, which is a method of making games that are portable between Windows and the XBox 360 game console. Disadvantages: Unlike Java, CLR applications can't run as applets within web pages. While the "Silverlight" technology does allow this, it's fairly late to the game and is not entrenched in browsers the way that Java and Flash are. Silverlight has also been discontinued after release 5. CLR-based applications are much less portable than they should be. Portability: While there are third-party efforts to port the CLR to operating systems other than Windows, the efforts in that direction are significantly smaller than the work being done in Windows. So while you might be able to create a very robust .NET application for Windows, your Mac and Linux efforts won't be nearly as smooth. Suitability for Beginners: Good on both counts (C# and Visual Basic). Both languages are straightforward and easy to understand. In addition, their tight integration with the Visual Studio environment makes setup fairly easy. Resources: Microsoft.com Flash and ActionScript Flash is a bit of an unusual member of this list, as its roots do not exist with the language itself but with an animation tool. In the 1990's, a couple of developers were dismayed at the size required to display animated graphics on web pages and the method by which they were displayed, so they developed a browser plug-in called "FutureSplash" as well as a drawing and animation tool that could create very compact vector-based animations. Macromedia, already a player in the interactive web-business with their Shockwave plug-in that could play content from their Director animation tool, purchased FutureSplash, renamed it "Flash", and proceeded to take the browser animation market by storm. A few versions later, Macromedia added a subset of JavaScript (discussed later), dubbed "ActionScript" to the plug-in, and Flash became a fully fledged programming environment, although it did take a few versions for the language as well as the development tool to "grow up" into a first-class environment useful for content other than simple web-based games. Today, Flash, now owned by Adobe, is based on ActionScript 3, which is a full implementation of the ECMAScript standard and is as capable as anything on this list. A few years ago, Adobe introduced a tool called "Flex" which was an attempt to "grow up" Flash into something more suitable for building browser-based user interfaces and RIA (Rich Internet Application) content rather than just animations and games. While not a replacement for Flash, Flex is better suited for building user interfaces, as it is an XML-based programming language with rich UI support rather than an animation tool with a built-in programming language. Along with the most recent version of Flex, Adobe introduced a product called AIR which decoupled Flash content from the browser. Using AIR and some newly-created objects intended to give Flash content access to more machine resources than the browser plug-in, you can now create first-class executables out of Flash (as well as JavaScript, HTML, and PDF) that run cross-platform. Advantages: Flash's integrated drawing and programming tools make programming web-based games absurdly easy. The Flash environment, while not having the pedigree of Visual Studio, is extremely feature-rich. Disadvantages: Flash, while a great environment for one person, does not support team programming very well. While the Flex compiler is free, the very nice FlexBuilder Flex content-creation tool is not. Unlike the other languages on this list, ActionScript is a client-only technology. While some kind of server-side ActionScript interpreter might prevent you from having to learn a separate server language, such a thing does not exist. Portability: Flash runtime players are available on Windows, Mac, Linux, several breeds of mobile phone, and some game consoles. Not all devices support the same version of Flash, though, so you will need to learn the capabilities of each version and what you want to target before you get started. Suitability for Beginners: Excellent, especially with its aggregation of drawing and animation tools. Although such ease of building in the Flash environment will not apply to other languages. A technique or build tool used in C++, for example, will likely have an equivalent in Java and vice-versa. The Flash development environment is unlike all others. Resources: Just like Microsoft is one-stop-shopping for all of your .NET needs, Adobe is the place to go for Flash. Python Python, unlike the previously-mentioned languages, did not start out as a large corporate or university project. It was much more of a grassroots effort among university students and, later, among people in the industry who liked the language's structure as well as its lack of legacy features. The language itself is fairly compact and is easy to use. It is also easy to embed a Python language interpreter into existing projects, which is why you'll see Python as an embedded scripting language in many games. Python also functions well as a server language as it features many of the server-friendly attributes of Java. In fact, Python compilers exist that can compile Python code to both the Java VM and Microsoft's CLR. Many services that you would recognize (YouTube, Google, and Yahoo) use Python extensively for back-end processing. Python is also becoming quite popular in the gaming community with the user-supported PyGame library. PyGame is an object library that abstracts the well-established SDL cross-platform graphics library into something friendly and easy-to-use from Python. Several impressive arcade games have been written entirely in Python. Advantages: Free and open-source. Very dedicated user community. Integrated fully into Google AppEngine, which is Google's "pay to play" processing server. Disadvantages: Virtually everything is handled not by a large corporation but by its user-community, so it might be a hard-sell to get a company to sign off on a Python-based project, although some very big players are now invested heavily in Python so Python now looks like much less of a "hobby language" than it used to be. Portability: Pretty good. Most of the third-party libraries made for Python are built around portable technologies like SDL and OpenGL, so it's not too difficult to write something in Python that will run on several platforms. Suitability for Beginners: The Python language has an easy-to-follow syntax and is easy to learn. In addition, there are several good community-written tutorials out there. Resources: Python.org is a well-organized home for all things Python. It is also the home of many active community forums where you can get your questions answered. Assembly Language There are two things that you must know about assembly language. The name of the language is "assembly". The name of the tool that converts assembly language into low-level machine code is called an "assembler". It's a common mistake, even among experienced programmers, to call the language "assembler". So please start out on the right foot by calling the language by its proper name. Assembly language is, by default, the smallest and fastest language in this article. Since it is not a high-level language but is actually a mnemonic representation of your CPU's instruction set, there is nothing written in a higher level language that can't be done faster in assembly And given fact number two above, you might think your search is over. After all, if a language is necessarily the smallest and fastest of the bunch, why not use it? In fact, why do other people bother with C or C++ or anything else when you can write your code in assembly and get the best results by definition? That's because the term "best code" doesn't just refer to the raw speed and size of your program. There is the quality of readability, as you might need to hand some of your code over to a colleague so he can work on it. There is the quality of portability, as you might need to move your code to another operating system or hardware architecture. There is the quality of maintainability, which is the need to easily fix problems at the close of the project. There is the quality of abstraction, in which you can write code in terms of moving a character down a hallway rather than manipulating numbers in locations in memory. And in all of those factors, assembly language comes in dead last. Assembly language is very difficult to read and maintain. Unless meticulously commented, it is of little use to anyone else inheriting the code. Fixing bugs and extending the existing code is difficult at best. You have to keep a constant eye on portability, lest you end up writing code that won't even run on different processor models by the same manufacturer. And the closest you'll get to "move the alien ten pixels to the left" are some register updates followed by several instructions to call the bitmap-display function. In practice, assembly is almost never used for complete games. Assembly, when it is used, is used in parts of programs that do a lot of calculations and are called a lot of times. Sometimes whittling a few machine-instructions out of a function that is called millions of times can provide enough of a benefit to make the extra work worthwhile. But this is a process that isn't undertaken from the beginning of a project. It is something done in early testing, after determining where the programming bottlenecks actually are. Assembly language is not for the faint of heart, and if you're reading an article to try to figure out what language to use, then you should probably look elsewhere. Advantages: Is the fastest and most compact way to go if you know what you are doing. Disadvantages: If you are reading this, you probably don't know what you are doing. Prepare to spend a long time learning a million little tricks to shave off processor ticks here and there. Portability: Worse than bad. Unless you are programming for the baseline processor, your programs might not even run on other "compatible" processors. For example, some special instructions on AMD processors are not available on Intel and vice versa. Suitability for Beginners: Run away. Resources: Assembly Language for Intel-Based Computers is well-recommended if you intend to write for Intel processors. If not Intel, check out the makers of your target CPU for technical resources. Server languages While many of the languages mentioned above will work nicely on the server, some of the technologies around which they were built are rather archaic, and much smoother easier-to-use solutions are now available. The original standard for writing a custom back-end for web-pages was called CGI, and it was a simple standard for running a customized executable on the server-side, passing it data from the page that called it, and collecting text output and returning it to the user. And while it was simple to implement on the server-side, it really doesn't model the interactive experience as the web is used today, and CGI-based solutions for interactive web-applications can be clunky at best. PHP PHP was one of the first true "embedded" scripting languages for the web, and in many ways it revolutionized the way that pages are scripted. While PHP can operate as a scripting language that takes input from a web form, processes it, and returns output, its real strength is its usage as a hypertext preprocessor. PHP, once configured to work as a preprocessor for a server, can process code that's embedded the page itself. So rather than writing a piece of standalone code that will, for example, print out the current date in a page, you can just embed the PHP code directly into your web page that prints the date, and the code will be quietly replaced with the resulting text as it is sent to a browser. PHP also added a library of native commands to communicate with the free and powerful MySQL database, making storing and retrieving persistent data easy. Another thing that made PHP instantly popular was the price. It was free, thus cementing it in the popular server configuration known as LAMP (Linux, Apache, MySQL, and PHP). The combination of these four technologies gave beginning or low-budget web designers an easy-to-use, scalable, and very powerful web setup for free. And as a bonus, it could run on low-cost hardware. And this fact was not lost on web developers. Today there are a large number of free or low price PHP scripts to perform just about any task, from simple user databases to complete "website in a box" setups. ASP.NET Not to be outdone, Microsoft quickly put together their own PHP-esque configuration based entirely on Microsoft's technologies, namely Windows, Internet Information Server (Microsoft's web server), CLR, and SQL Server. While far from free and not in PHP's league in the breadth of third-party scripts available, ASP.NET does have the advantage of all the tech support money can buy as well as support for languages other than PHP. If you're familiar with Visual Basic on the client side, for example, you can use it on the server-side with ASP.NET. But if you're working within a budget, a LAMP setup will likely be a better fit. Ruby on Rails Ruby on Rails (often just called "Rails") is not itself a programming language but is a class library built with the Ruby programming language. While Ruby itself is a not-very-revolutionary object-oriented scripting language that owes its heritage to both Python and Perl, it is the Rails library that makes the system revolutionary. The Rails library fully integrates the MVC (Model View Controller) paradigm and is designed to prevent as little repetition of technique as possible. And this does allow you to build a fairly rich server-based system with a minimum of code. And the Rails folks will proudly show off web-forums and social networking sites that have been written in an absurdly small amount of code. Like PHP, Ruby on Rails is free. Other Languages That Are Worth Mention The sections above cover most of the languages that have a pedigree in the game development world, both on the client and server. That is to say that large scale or popular games have been written using these languages. There are, however, a couple of interesting technologies out there that, while not yet established as first-class languages for games, show lots of promise. It would not be surprising to see these languages score some major projects in the future. JavaScript JavaScript received brief mention in the section about Flash and ActionScript. JavaScript has the same root as ActionScript, the ECMAScript standard, and the languages resemble each other quite a bit. JavaScript first gained popularity as a language for scripting web pages, and today it's ubiquitous as the language used to nudge and squeeze and stretch and convince web browsers to display web content exactly the way you want. If you've ever been annoyed by a web page that resizes itself to fit the page's content, you can rest assured that JavaScript was behind that. But JavaScript is useful for more than just web annoyances. It's becoming a popular language for writing all of those interesting and mostly-useless widgets that are sticking on desktops everywhere. Even better, the language is robust enough to write complete games, running inside the browser or standalone if used with a widget framework. There are two primary problems that are preventing JavaScript from becoming more popular as a language for web games (compared to Flash, for example). One is that, unlike the Flash plug-in, JavaScript's interpreter is dependent on the maker of the browser. And while the language is based on the very complete ECMA standard, the JavaScript implementations used by browsers differ both in language features and performance. Hence it is difficult to write a truly large and robust JavaScript application that works in all browsers. The second problem is one of protecting your intellectual property. JavaScript is not compiled and is streamed to browsers as source code, which is then interpreted by the browser itself. And while there are some clever tools that attempt to obfuscate and hide your code from a user, the source code to your game is never very far away from the "View Source" command of your browser. If you don't want your game to be borrowed/improved/stolen, you should first take a hard look at the security solutions available. D D is a sort of "unofficial" grandchild of C, C++, and Java. It is the brainchild of Walter Bright, who is one of the pioneers of C and C++ compiler construction on PCs. Growing frustrated with the ever-growing class libraries as well as the fanatical need for backward compatibility, Mr. Bright decided to build something from the ground-up that took the best features of C, C++, and Java while jettisoning anything that didn't have a very good reason for existing. And the result was a language that was tighter and easier to learn than its "parents" without sacrificing important features or runtime speed. D is what happens when you take language design away from the realms of the committee. While D does jettison backward compatibility in the name of simplicity, it does have excellent methods for communicating with C code, so if you have a third-party library or some C source code that you are loath to rewrite, you can still talk to it without much difficulty. That is to say that D would be the best of all worlds if it gained more support. It simply doesn't yet have the huge libraries of code, wealth of tools, and base of user support of the other languages. Hopefully its support will grow and it will receive the attention it deserves, but that will take some time. Conclusion Early on it was clear that this article would not reach a satisfactory conclusion as to what language to use. Fact is, there's very rarely a single solution that will solve all problems. Hopefully this list will at least whittle your choices down to two or three good candidates. The rest of the research is up to you. Thankfully, virtually every solution mentioned above has a free implementation, so you can try out these languages and choose the one that you think will best suit your project.