gdarchive

Members
  • Content count

    14
  • Joined

  • Last visited

Community Reputation

3180 Excellent

About gdarchive

  • Rank
    Third Party Articles
  1. 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
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. How To Publish on GameDev.net

  8. 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.
  9. 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.
  10. 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.
  11. 3ds Max 2015 Review

    Occasionally the development team at Autodesk focuses their efforts on improving the application performance instead of adding flashy new features. The 2015 release of 3ds Max seems to be one of these times. This version has a few nice surprises, but the biggest change is under the hood. The viewports seem more responsive and the software doesn't crash nearly as often as the previous version. New Welcome Screen You don't have to go very far into the software to see some new features. The Welcome Screen that appears when you first start the software has been overhauled. It is now divided into three different sections including Learn, Start and Extend. The Learn section has links to a list of 1-minute movies that cover all the basics of using the software. The videos touch on just the fundamentals, but they are great for those new to the software. There are also links to the 3ds Max Learning Channel on YouTube as well as some example content pages. The Start section of the Welcome Screen has the same features from the previous Welcome Screen including a list of recently opened files along with a Workspace drop-down list and path to the current Project Folder. The Extend section includes access to Autodesk Exchange and highlights a new plug-in each time the software is loaded. There is also a link to various scripts found on the Area website and a link to Autodesk 360 where you can access new content such as animation sequences from the Animation Store and new trees and plants using the Download Vegetation link. One of the new features available through the Autodesk Exchange application store is the Stereo Camera plug-in. This plug-in helps to quickly create stereoscopic scenes with the red and blue views for each eye that creates a 3d effect when viewed using the red/blue 3d glasses. Placement Tools One of the more difficult skills to master for new users is positioning and orienting objects in the scene. 3ds Max 2015 includes a new tool called the Select and Place tool that makes it easier to position objects relative to one another. Using the Select and Place tool, you can drag the selected object and it automatically snaps the pivot of the object to the surface of the other scene objects. If you right click on the tool in the main toolbar, then you can access a dialog box of settings that give you even more control. Within the dialog box is a Rotate button that causes the selected object to spin about its pivot. The Use Base As Pivot button in the Placement Settings dialog box causes the points closest to the other objects to be the pivot point. For example, a sphere would just touch the edge of another sphere instead of being embedded since its pivot is in the center if this button is enabled. The Pillow mode button moves the object over the surface of the other objects without allowing the two objects to intersect. The AutoParent automatically makes the moved object a child of the object that it is positioned next to. You can also control the Object Up Axis using the buttons in the Placement Settings dialog box. This tool is great for beginners, but it is also helpful when placing objects such as characters on the ground surface of a scene. Figure 1 shows this tool in use as the raised object is neatly placed on the surface of the rounded housing. Figure 1: The Select and Place tool lets you place the selected object by moving it over the surface of the other scene objects. Image courtesy of Autodesk Working with Point Cloud Datasets A Point Cloud is a dataset that includes a large number of points that together make up a real-world object. Point Cloud datasets are created by scanning an environment and the points are all saved using the RCP or RCS file formats. The points within a Point Cloud object are unique because each point defines a location in space, but they also have a color associated with it, so you could get a point cloud dataset of an entire bridge that can be used as a backdrop for your scene. Autodesk also has an application called ReCap that works with point scanners to create Point Cloud datasets. These datasets can then be imported into 3ds Max where they appear as a Point Cloud object. These Point Cloud objects aren't affected by the scene lighting, which makes them ideal for backdrops. The drawback to using a Point Cloud object is that they cannot be edited using the modeling tools. Usually the points are so dense that you wouldn't want to edit them anyway, but you can pare down the points to a specific volume to reduce its size. You also cannot apply materials to Point Cloud objects. These objects automatically get a Point Cloud material applied to them. This material lets you change the color intensity of the points and you can also change the ambient occlusion and shadow reception settings. If you are planning to render out a scene with a Point Cloud object, then you'll need to activate the mental ray renderer. Within the Grid and Snap Settings dialog box is a option to snap to Point Cloud points, but most point clouds are so huge, that it could easily take hundreds of hours to convert a Point Cloud object to an editable geometry object, so this really isn't feasible. When a Point Cloud object is created, you can change the color channel and level of detail of the point cloud using the settings in the Display rollout. The Color Channel options include True Color, Elevation Ramp, Intensity Ramp, Normal Ramp and Single Color. There is also a map button for applying a map to the Point Cloud object. The Level of Detail setting includes a slider that moves from Performance to Quality. It also updates the number of points included and the total number of points in the Point Cloud object. There are also settings for changing the size of each point, which is helpful to fill in all the empty space. Although the Point Cloud object seems like a useful construct, most Point Clouds are way too dense to be interactively used within a scene. Also, Point Clouds typically have large gaping areas without any detail that hurts the visual look of the object as a background. More specifically for game developers, Point Clouds aren't supported by any game engines and the work to convert a Point Cloud object to a useable piece of geometry would take too long to be beneficial. Quad Chamfer For those that like to model with edge loops, the Chamfer modifier has a new Quad Chamfer option that insures that all chamfer edges are divided using quad-based polygons. This results in cleaner edits that deform better. The tool also lets you smooth across just the chamfer area or across the entire object. You can also define the number of edges to include, remove the chamfer area or isolate the chamfer sections. Figure 2 shows how edges are smoothed using the enhanced Chamfer tool with a Quad Chamfer setting. Figure 2: The new Quad Chamfer settings results in smoother objects when applied to edges. Image courtesy of Autodesk Using the ShaderFX Editor Previous versions of 3ds Max allowed you use external apps to generate and import shaders, but 3ds Max 2015 finally has added a ShaderFX Editor to the software. When the DirectX Shader material is added to an object, then the Open ShaderFX button appears in the rollout. The ShaderFX Editor lets you right click to access the various shader nodes. These nodes can be connected together by dragging from output channels to input channels just like using the Slate Material Editor. The inputs and outputs are all color-coded which helps to insure that the right data type is being passed. At the top of each shader node is a preview that shows what the current texture map looks like. Once you are happy with the shader results, you can export the shader to the HLSL, CLSL or CgFX formats. Created shaders can then be viewed in the viewports, as shown in Figure 3, without having to export the shader to the game engine. Figure 3: Shaders created in the ShaderFX Editor can be viewed directly in the viewports. Image courtesy of Autodesk Layer Explorer The Scene Explorer has been overhauled and now is docked to the left of the viewports for immediate access. Although the Scene Explorer appears docked to the left by default, you can quickly drag it to the right or top of the interface also. Having the Scene Explorer docked to the side of the interface provides a quick, easy way to select and organize all the scene objects. It also makes it easy to link objects to create a hierarchy. It has also been upgraded with a layer manager mode that you can quickly select. This makes dividing your scene into layers quick and easy. You can also nest layers which is a huge benefit. Populate Improvements The big feature from the last version of 3ds Max was the Populate tool that quickly added diverse animated crowds to a scene. Populate has been improved in a number of ways for this release including the ability to add runners to the crowd and more control over the speed of the crowd characters. There is also an ability to add seated characters to the idle areas so crowds can include restaurants and concert venues. There are also new controls that let you set the appearance of the characters. Finally, if there is a particular character that you like, you can bake its geometry and animation into the scene. Small Changes with Big Rewards Autodesk has always been really good at listening to requests from their users. They've even established a set of forum pages called Small Annoying Things that lets users identify annoying parts of the software and then vote on which ones get fixed. One of the winners in the latest release was to add the Undo and Redo buttons to the main toolbar. This is a good example of a simple change that helps many users greatly. Another small change that will be a big boost is that mental ray renderings can be viewed within the ActiveShade preview window (Figure 4). The iray renderer also supports render elements, so you can break down rendering to several compositing layers. Figure 4: Enabling mental ray within an ActiveShade window lets you interact with the scene in real-time. Image courtesy of Autodesk Scripters will be happy to hear that there is now a 3ds Max Python API that lets you execute Python scripts from the 3ds Max command line. Summary Most of the work in this release was done to improve performance, which is great for users, but can be hard to quantify. The biggest new features in this release are the Point Cloud support and the ShaderFX Editor. As far as game developers go, the Point Cloud features aren't really feasible for game scenes since most Point Clouds are extremely dense and they cannot be used within most of the major game engines. The ShaderFX Editor is a nice addition and one that game creators can take full advantage of, but most shader effect builders already have a process outside of the software and it will take some time before complex shader trees will be built within 3ds Max. Overall, the improved performance of the software will help users immensely, but something as vague as better performance might be a hard sell for cost-conscience managers. 3ds Max 2015 and 3ds Max Design 2015 are both available as a stand-alone products. 3ds Max 2015 is also available as part of the Entertainment Creation Suite, bundled with Autodesk Maya, Mudbox, MotionBuilder, Softimage, and Sketchbook Designer. For more information on 3ds Max 2015, visit the Max product pages on Autodesk's web site at http://usa.autodesk.com. A free trial version of 3ds Max is also available at http://www.autodesk.com/3dsmaxtrial.
  12. The 4Ps of Marketing

    A preface for this article is that the game market changes extremely quickly. While the foundation of this article is the 4Ps of marketing and those will never be out of date, the specifics may change fairly rapidly. The original article published to GameDev.net focused on a lot of things that were very specific to the downloadable market. Instead I will focus this more on the marketing principals; so it won't be out of date by the time you read it. The most common mistake people make is assuming that if you make it, they will download it. If you create a game, the publishers will find you. If you make the game, the players will find you. That when you are done pounding the code and graphics into the software you have but to sit and watch the money roll in... Wake up! It doesn't work that way anywhere in the world. If you are not spending at least 25% of the time it took you to create the game marketing it, you are doing something wrong. There are a million things to be done, but before you do any of them you have to learn a little bit about what marketing is, keeping these key concepts in mind for each and every decision you make. The foundation of all marketing, where it all begins, is referred to as the 4Ps. They are Product, Price, Place, and Promotion. In this article I will go over the 4Ps in the broadest sense and try to relate it to game specific items. If there is a specific problem with your product that needs overcoming, such as designing a package, I suggest picking up some more detailed texts on each of the 4Ps individually. This article was originally part of a series published on GameDev.net back in 2004. It was revised by the original author in 2008 and included in the book Business and Production: A GameDev.net Collection, which is one of 4 books collecting both popular GameDev.net articles and new original content in print format. Product In video games, product is probably the thing coders and developers think about most. It is a good thing, because in gaming, product IS the most important factor. I know, we all remember some really BAD products which had good marketing and turned out to make a bundle, but those are the exceptions, not the rules. It is far easier to market a good product than a bad one, and I doubt any indie developer has the assets to market a bad product. The two key words in product are want and need. You have to make sure you are giving customers both, and those two things are not always the same! Ok so I can't tell you how to make a good product... well, not in a few paragraphs anyway. Long story short here is make the game good, but there are some items in Product that impact your sales that we can talk about in this small space. Design of a demo product is one. A key concept, for instance, is making your product accessible to a wide audience. This means compatible with as many systems as you can. Try to design the game and the demo to not require any reading and preferably any help files. You only have a limited amount of time to show your new client your game, you don't want to squander that time having them read help files. That said, if the game is complex enough that some help file type reading needs to be done make sure you force them to read and understand. Remember: The customer wants to instantly play but needs to learn the basic controls! A very common question concerning the product is what is the best way to make a demo? There are 3 basic demo types: Time Limited Pro: Gives the user a taste of what the full version is like. Most portals require a 60 minute demo.. Con: It is very hard to time the demo to end where the person is hungry for more. Feature Limited Pro: Easy to dangle the additional features right in front of the user. Con: Some people may not buy because they didn't experience a feature they wanted, or didn't know a feature was there that should have been dangled better. Episodic Pro: Easy to end the plot or game at a cliff-hanger. Giving away an episode can count as having a "free" game to use to promote your site. Con: Could give too much of your game away. People may be content playing only your demo and never upgrading. There is no right answer when it comes down to it. Every demo type has been used successfully by some people. The key to designing a good demo is that the demo ends right when the person is really getting into it. I like to use this motto: Give the customers all that they need and a taste of what they want and then leave them hanging. I point out the irony that time limited to me is the least effective demo type but the one used by most portals. Why? Uniformity. If every demo was different, portals worry it would confuse users and they frankly don't trust you to do a good job making it any other way. Still, it shouldn't stop you from trying to get them to use what model you think suits your game best. Product also refers to what is sometimes called the 5th P - Package. You'd only use that in retail marketing, as online stuff really has no package. Here we are focusing on online goods, so no box and no package, When you go into retail know this: A good box sells games! Price Possibly the most complicated process in any industry, Price is a huge factor in the success of your product. A key concept of price is that price is not the same as value. The main concern you should have is to deliver your product so that its value is greater than its price, otherwise people won't buy it. In this section I am going to touch on four different concepts of price. There are many more, but these are some of the biggest. Prestige Pricing is a term that basically says, "A more expensive product IS a higher quality product." 9 out of 10 people will tell you, when faced with two identical products; the one with the higher price tag is the higher quality product. Prestige price refers to this effect; a 20 dollar game is a better game than a 10 dollar game. A higher price does raise the value of the product, but not necessarily equal to the increase in price. Sometimes it is possible to use a discount to give a product the volume of a lower cost without loss of prestige. Penetration Pricing is the price strategy that says a lower price will generate more volume. More volume means more market share. More market share means more future sales. A 10 dollar game generates more sales than a 20 dollar game, but maybe not more profit. Penetration is best used with a product that has strong viral capacity. That is, the more people who buy the game create more potential for future people to buy the game. Read that line as many times as it takes to sink in. In penetration pricing you are often sacrificing profit per unit in order to generate more sales for your next product or for this product at a much later date. The Hardest Dollar concept. In online sales it is common that anyone willing to spend 1 dollar on your game would be willing to spend 10 or 20. This is saying that the hardest part of an online sale is simply getting a user to open his wallet. This is also why subscription sales work so well, as the customer's wallet is automatically open every month; thus neutralizing the largest hurdle. It is quite possible to use this "If they'd spend 1 dollar" mentality as justification for a higher price, but it is important to note that the impact of this decreases the further from 1 dollar you get. At 30.00 it's likely you'll be back to your normal demand curve. Intangible Terms of Sale is often seen in offerings outside of a pure dollar and cents value. Customer support, support from the developer, getting 25% off your next purchase. These are just a few of the intangible benefits you can tack onto your product. By offering intangible benefits you can often increase the value of the product without altering the price of the product. Place Luckily for all of you there are not too many place decisions to make in games. Download, CD, Retail or Online Publisher... that covers all the main ones you will encounter. Place is the distribution and where people get the product to try or buy it. Each place decision has its own benefits, pains, and odds are you can put your product in every 'place' Download is what I work most with, though you can offer a CD as a part of the download package from places like Swift CD. In general, getting downloads amounts to getting your game in as many places as possible. To that end you have places to submit downloadable games like shareware directories, you have places that review and cover games, and you have forums and interest groups that you should approach. Getting downloads is a tough business these days, as there is a lot of competition. Retail is the most expensive and most difficult. You will NEED a publisher if you want to get into a retail store. In general, putting a retail title on a shelf runs anywhere between 100,000 and 200,000 dollars or more. That is just to get your title on a shelf! Usually marketing is not handled by the developer here, so most of this is out of your hands. Sadly this can also mean you are just part of long tail sales, and your individual product is just a meaningless number to them. Yep, expect to get raked over the coals in retail. These days it's a collapsing market, but there is still money to be made there. Nowadays the most common form of place is an online publisher. These non-exclusive houses hold most of the downloadable market. The amount you get per sale tends to range between 20% and 40% and in exchange you have access to their users. They don't actively market your product, but the exposure you get on their site can be turned and used in your favor. It will get people looking for your product actively, so make sure there is a good way for them to use search engines to find your site so you can promote your games directly; hopefully stealing away a few users from the portals. Promotion Last but not least, promotion. Ask 10 people on the street what a marketing person does and all 10 will probably tell you that this is what they do. The above 3 are also what we do, but it's not what people think about. Promotion is the combination of advertising, publicity, and buzz (a subset of publicity). Buzz is the hardest to create and the hardest to control. Most firms actually avoid trying to make buzz because of the havoc it can cause. Buzz items are typically fads, and the problem it most frequently creates is demand exceeding capacity. In the download world it is not as big a deal, thankfully. To create buzz basically you need a viral product and a huge quantity of publicity, advertising, and customer discussion over your product in a very short period of time. I'll go on a limb and say it should be your goal to achieve as much buzz as possible, but not really the focus of your efforts. Publicity is 'free' advertising. Reviews, Interviews, and Previews are the most common forms of this. Also included are press releases, screenshots, and link exchanges. The downside of publicity is that it usually takes a lot of time and work to get. Remember, if you build it they will NOT come. Reviewers will not bang down your door, and you have to do more than just submit your game to some unknown E-mail address. To get publicity you must be tenacious. Get people's contact info and talk to them as frequently as you can both before and after your game is released. Even after they review it, stay in touch and keep them informed of what you're up to. You never know when someone will write an article and mention upcoming games or ideas. Advertising is a much easier creature; it's also much more expensive. To correctly advertise you must know your target market and your conversion rate. Conversion rates are how many sales you get for every 100 downloads. Ads must also be targeted. Target refers to what group is most likely to buy your game. Lately there has been a lot of emphasis on Google Adwords from sites, and Google is a good advertising source, but part of me thinks it's a copout from doing research and finding better deals. In recent years Google has become less and less profitable for online games due to increased competition. The 4 (or 5) Ps are pretty much the backbone for everything else in promotion. The simple goal here is to get you to think about each of them. How does your product look and how well is the demo designed? Where will we be distributing it and are we guaranteed to get where we want to go? Who is handling the promotion of our product, what budget do we have for that person and advertising? Does that person have all the contacts in place and ready to go when the product is ready? Will we charge the standard 19.95 for this game or are we going to try something different? What intangible benefits to the sale can we add? Think about these things and others that come to your mind, I recommend writing the question and the answer (if you have one) in a document and bringing it up once in a while to remind yourself of the focus and goals of each of these 4 items. You'll be glad you did!
  13. This article will be about a new way to approach narrative design in games - the 4 Layers Approach. It is based on a GDC talk I gave in March this year. The approach is primarily meant to suggest a workflow that focuses on the story and makes sure the narrative and gameplay are connected. The end goal is to create games that provide a better interactive narrative. Narrative Basics First off, "narrative" will need to be defined. At its most fundamental level, the narrative is what happens as you play the game over a longer period. It is basically the totality of the experience; something that happens when all elements are taken together: gameplay, dialog, notes, setting, graphics etc.; the player's subjective journey through the game. I know this clashes with other definitions that refer to narrative as a separate aspect of the game, but I think this is the one that's most helpful when discussing game design. It also fits with job titles such as "narrative designer", who is a person that doesn't just deal with writing or cut-scenes, but who works at a much higher level. Quick note: A deep dive into various story-related terminology can be found here. Let's compare this to the other basic elements of a game. Looking at a game second-by-second, you see the core mechanics. Moving up to look at it using a time-frame of minutes, you see tactics and problem-solving (which also includes things like puzzles). Higher still, often on the scale of hours, you see the narrative. Almost all game design is focused on the two lower levels, mechanics and tactics, and narrative mostly comes out as a sort of byproduct. Designing the narrative becomes a sort of patchwork process, where you try and create a coherent sense of storytelling from the small gaps left behind by the layers below. For instance, in games based on combat mechanics the narrative usually just acts as a form of set-up for encounters and is heavily constrained by how the fights work and so forth. So a crucial step towards better storytelling in games is to give at least as much focus to the narrative layer as to the other two layers, mechanics and tactics. It is important to not devote all the focus to the story though; having a symbiosis between all of layers is a core element of what makes video games special. If we want proper interactive story, we need to preserve this. Simply saying that we want to put more focus on the narrative level is still pretty vague; it doesn't tell us anything useful. So I'll make it a bit more concrete by listing five required cornerstones of an interactive story. This is where we get into highly subjective territory, but that can't be helped - there's a wide span of opinions on how narrative and gameplay should work together (some would even object to having focus on the narrative layer at all!). But in order to move on we need to have something concrete; if we just continue to talk in vague terms of "improving storytelling", any suggestion can be shot down on the basis of some personal preference. Doing it like that will just get us stuck in boring discussions and it becomes much harder to set a proper goal. Core Elements of Storytelling The following elements shouldn't prove too controversial and I think most people will agree with them. But it still feels important to acknowledge that this is an opinion and not something I regard as an eternal truth. That said, here are my core requirements for a game with focus on narrative. 1) The focus is on storytelling. This is a trivial requirement, but still way too uncommon. Basically, the main goal of the game should be for the player to experience a specific story. 2) The bulk of the gameplay time is spent playing. We want interactive storytelling, so players should play, not read notes, watch cutscenes, etc. These things are by no means forbidden, but they should not make up the bulk of the experience. 3) The interactions make narrative sense. This means actions that: Move the story forward. Help the player understand their role. Are coherent with the narrative. Are not just there as padding. 4) There's no repetition. Repetition leads to us noticing patterns, and noticing patterns in a game system is not far away from wanting to optimize them. And once you start thinking of the game in terms of "choices that give me the best systemic outcome", it takes a lot of focus away from the game's narrative aspects. 5) There are no major progression blocks. There is no inherent problem with challenge, but if the goal here is to tell a story, then the player should not spend days pondering a puzzle or trying to overcome a skill-based challenge. Just as with repetition this takes the focus away from the narrative. There is a lot more that can be said about these requirements, all of which you can find here. Good Examples To Strive For Now for the crucial follow up question: what games satisfy these requirements? Does Heavy Rain manage this? Nope, there's too little gameplay (requirement #2). Bioshock, with all the environmental storytelling? Nope, too much shooting (requirement #4). These two games symbolize the basic issues almost all video game storytelling have: either you do not play enough, or most of what the gameplay does is not related to the narrative. There are a few good examples, though. Thirty Flights of Loving is a game that I think lives up to the requirements. But the problem here is that the storyline is extremely fuzzy and disjointed. The game is a series of vaguely connected scenes, and is lacking a certain pure storytelling quality. We come much closer to finding something that lives up to the requirements by looking at specific sections in games. Two good ones are the giraffe scene in The Last of Us and the end sequence in Brothers: A Tale of Two Sons. Both of these sections have this strong sense of being inside a narrative and fulfill my requirements. You are definitely playing a story here. But these are just small scenes in a much larger game, and that larger game breaks most of the core elements that I have gone over. So what we really want is to have a full game filled with these sorts of sections. That would be perfect! However, that isn't possible. These scenes depend on tons of previous game content and are extremely hard to set up. You cannot just simply strive to fill the game with stuff like this, it's just not doable. In order to get a game that consistently evokes this feeling, we have to approach it from a different direction. This leads us to the main bulk of this article, where I'll talk about a way to achieve this. This is an approach named "4 Layers" and the basic idea is to not attack the problem directly, but reduce it into steps and thereby be able to get proper interactive storytelling into just about any section of the game. The 4 Layers Approach The framework is something that's been developed between myself and Adrian Chmielarz, the man responsible for Painkiller, Bulletstorm, etc. At Frictional Games we are using this a cornerstone for our new game SOMA, and Adrian's new company, The Astronauts, is using it for their upcoming The Vanishing of Ethan Carter. They way this approach works is that you divide the design process into four big steps. You start with the gameplay and then work your way through adding more and more layers of storytelling. The additional layers are Narrative Goal, Narrative Background and finally Mental Modeling. Before I get more in-depth it is important to note that in order to use this approach correctly, the game must be broken down into scenes. Each scene could be a puzzle, an enemy encounter, and so on. Normally, gameplay refers to how the game plays out as a whole, but for this framework, we must split it up into sections. This is connected with the above requirement of not having repetition, and usually means that there needs to be a lot of logic and gameplay coded into the world. I think that this is presents a crucial piece of the puzzle for having better storytelling: to drop the need for an overarching play loop and instead make the gameplay fit each specific scene of the game. So instead of having the gameplay describe the player's overall experience of the game, the narrative will provide this structure. Exactly how this is done will become more apparent as we go through the different layers. Layer 1: Gameplay First we need to start with the basic gameplay and it's crucial that the narrative aspects are kept in mind from the get-go. If the gameplay doesn't fit with the story, then problems will start to accrue and it'll make the later layers much harder to achieve and reduce the final quality. As a first step for ensuring this, there are four basic rules that must be followed: 1) Coherency The gameplay must fit with the game's world, mood and characters. There should be no need for double-thinking when performing an action; it should fit with what has been laid out by the narrative. The player should be able to think about the actions made to get a deeper understanding of the game's story. What the player does must also make some sort of sense and not just be a sequence of random or nonsensical interactions. The infamous "moustache and cat"-puzzle from Gabriel Knight 3 is a shining example of what not to do. 2) Streamlining It is important that the gameplay is not too convoluted and doesn't have too many steps. This is partly to minimize the chance of the player getting stuck. When the player is stuck for longer periods they focus on the mechanics or tactics for gameplay. Also, we want to have situations where the player can plan ahead and feel like they understand the world. If the steps required for any moment are too complicated, it's very easy to lose immersion and to lose track of the goal. This happens very often in classic adventure games, where the solution to something straightforward requires a massive number of steps to accomplish. 3) A Sense of Accomplishment This sort of thing is normally built into the core gameplay, but might not be as straightforward in a narrative-focused game. It is really easy to fall in the trap of doing "press button to progress" type of gameplay when the main goal is to tell a story. But in order to make the player feel agency, there must be some sense of achievement. The challenge needed to evoke this sense of accomplishment does not have to be skill or puzzle-based, though. Here are a few other things that could be used instead: memory tasks, out-of-the-box thinking, grind, endurance tests, difficult story choices, sequence breaks, understanding of the plot, exploration, navigation, maze escape, overcoming fear and probably tons more. 4) Action Confirmation When the player does something in the game, they must understand what it is that they are doing and why they are doing it. For basic mechanics this comes naturally, "I jumped over the hole to avoid falling down", "I shot the guy so he would not shoot me back" and so forth. But when taken to the level of a scene it is not always as straightforward. For instance, the player might accidentally activate some machinery without being aware that this was going to happen beforehand and afterwards not knowing what it accomplished. If this occurs too frequently, the player starts optimizing their thinking and stops reasoning about their actions. This then leads to an experience where the player feels as if they are just pulled along. Getting all of these four rules into a gameplay scene and also making sure it is engaging is no small feat. Most games that want to focus on storytelling stop here. But in the 4-Layer approach this is just the first step. Before moving on to the next layer of the framework, I will give a simple gameplay example. Say the player encounters a locked door blocking their path. Some earlier information has hinted that there is a key is hidden nearby, and now they need to search the room to find it. Once they find the key they can unlock the door and progress. Very simple, and not very exciting, but it fulfills rules set up above. A locked door and hidden key should not conflict with the story. Given that the search space for the key is rather small, it is not likely the player will get stuck. It requires enough from the player to give a sense of accomplishment. Set up correctly, it should be very obvious to the player that the door needs to be opened and the key is the item used to accomplish this. I will come back later and expand upon this with the other layers to give you a better feel for how the approach works. Layer 2: Narrative Goal So, next step: the narrative goal. Normally the reason for the player to get through some gameplay segment is just pure progress. There is often some overarching story goal like "kill the evil wizard", but that is quite far into the future, so when the player encounters an obstacle they try to overcome it because that is what the game demands of them. It is often very clear that they are in "gamer mode" at this point and until the obstacle is cleared. This is useful in order for the player to know what to do, but it is very problematic for the narrative - it removes the experience of being inside a story. The player stops seeing their actions as part of a story and instead sees them as steps towards an abstract gameplay goal. What can often happen is that the player starts thinking stuff like "Now I just need to get this section out of the way so I can get on with the story", a forced mental division between narrative and gameplay, which is diametrically opposed to the fusion we're striving for. The way to fix this is to give the player some sort of short-term narrative goal, one that is directly connected to the current gameplay. The aim is to keep the player in narrative mode so they do not brush the story aside for some puzzling or shooting action. When the player is engaged in the gameplay at hand we want them focused on and motivated by this narrative goal. This makes it harder for the player to separate the two, as the narrative goal is always in sight. It is no longer about "doing stuff to get the story going", instead it is about "doing stuff because of the story". The distinction might not seem that big, but it makes all the difference. Keep in mind this is at a local level, for a scene that might just last a few minutes or less; the narrative goal is constantly visible to the player and a steady reminder of why they are going through with the actions. A nice side-effect of this is that since the goal is narrative in nature, it becomes a reward for completing the gameplay section. The player is motivated to go through actions because of story and is then promptly rewarded with a fresh piece of the story. In all, this binds the gameplay much more tightly to the storytelling. An additional side-effect is that it can keep the player on the right track. The player might not be sure what to do next, but if the narrative goal is connected with the solution to the obstacle, then the player will progress simply by being interested in the story. Here are three different types of narrative goals that could be used: Mystery The most obvious and simple is mystery; that there is something unknown you want find out about. It's pretty easy to have environmental assets that constantly reminds the player of this - this sort of goal is also pretty easy to fit into a gameplay scene. Uncomfortable Environment Another way is to give the scene a narrative reason for the player not wanting to stick around. The most trivial example of this would be a dark and scary environment; the player is scared and wants to leave. It could also be that the situation is awkward or emotional in a way that the player can't cope with and wants to escape. For example, it could be a depressing scene, like a funeral reception, that makes the player sad. It's important, though, not to get caught up in game mechanics; it must be a story reason that makes the player uncomfortable, not some mechanic (spikes popping up here and there, etc.). We want the focus to be on the narrative, not the underlying systems. Character Conflict Character-based conflict can also be used as a narrative goal. Walking Dead is full of this; what are really just fairly simplistic activities become engaging because of story reasons. A great example is the food distribution "puzzle" where the player is instructed to determine how the remaining stash of food is divided. What makes it interesting is that the player cannot come up with a division that doesn't upset at least one of the characters. Any gameplay that results in the player changing the social dynamics can act as powerful narrative goal. These are just three examples of what could be done and there are bound to be a ton more. I think you could use basic writing techniques to come up with more. Now let's update the example from before and add a narrative goal. To keep it simple let's go with some mystery. Say there's a man on the other side of the door trying to get in. He wants to retrieve something that's in the room that the player is currently in, and is asking them to open the door. Now all of a sudden there's a short-term goal for wanting the door open, and it's no longer just due to wanting to progress. "Who is this man?", "What object is it that he's after?" You want to get these questions answered and that adds narrative motivation. The 4-Layers framework is not a linear method, you'll have to constantly skip back and forth between the layers. In this case, you need to check the first layer, gameplay, and see if there's anything that could be updated in order to improve the narrative goal. You might need to change where the key is hidden, or even exchange the key for something else. Layer 3: Narrative Background With the addition of a narrative goal, the scene is now framed in a much more story-like manner. But there is still an issue: the actions the player does are quite gameplay-focused. In the above example, the player searches the environment simply in order to find a certain item; there is no proper sense of story-telling going on as the player goes through these actions. That is what this layer is all about fixing. The basic idea is that the actions the player is supposed to be doing are immersed in story substance. So when the player is interacting, it is not just pure gameplay, they are constantly being fed story at the same time. When the narrative goal was added, the player's thinking was changed from "doing stuff to get the story going" to "doing stuff because of the story". With narrative background in place we change it to "doing stuff in order to make the story appear". Narrative-wise, the player's actions are no longer just a means to an end, they are what causes the story to emerge as you play. Or at least that's how we want it to appear to the player. By having the gameplay actions and the narrative beats coincide, we make it hard for the player to distinguish between the two. The goal is for this to lead to a sense of always being inside a story. Here are a few examples of the kind of background that can be used: Story Fragments This means having narrative clues scattered through the environment which are stumbled upon while playing. An important note is that shouldn't just be the standard audio logs and diary entries. While it can consist of those sort of elements, it's important that they never mean a large interruption in the gameplay, and that they're found as the player goes through with the actions needed to overcome the obstacle. The act of collecting clues should not feel like a separate activity, but come as a part of the scene's main gameplay. Complementary Dialog There can also be dialog going on at the same time, giving context to the player's actions. Bastion uses this to great effect. All of the standard gameplay elements like enemies, power-ups and breakable crates are given a place in the world and a sense of importance. It also gives a great sense of variation to similar activities, as their narrative significance can be quite diverse. Dear Esther is another good example of this at work. Here the simple act of walking is given the sense of being vital to the story. Emotionally Significant Assets If the the items involved in the gameplay have some sort of emotional value or a strong connection to the story, the player is much less likely to see them as abstract tools. Inside of picking up "item needed to progress", the player finds something that can be a story revelation in itself. There is a huge difference in finding "standard knife A" and "the murder weapon from a hideous crime". These three are of course not the only methods at your disposal to create narrative background. Just like with the previous layer, there are bound to be tons of other things too. To make things a bit more concrete, let's go back to the example scene and add some narrative background. First off, let's add story fragments in the form of clues. These can give hints to the player about who the man behind the door is. Pictures, painting, documents and so on. So while the player is searching for the key they'll also be fed hints about the story. Secondly, let's have the man comment on the player's actions and give hints, making him reveal his character a bit. Third, we could say that it was the man who hid the key and that he did so for some very important reason. That way the key has some narrative significance and is not just an abstract tool. Getting all of these things in might require us to change the puzzle a bit, but as said before, this not a linear design approach. What you learn from the later layers must be fed back into the previous ones. Layer 4: Mental Modeling Now comes the 4th, and final, layer - Mental Modeling. The goal with this layer is to change the way the player perceives and thinks about the game. We want to tap into how the player evaluates their experience. The first and crucial fact you must be aware of is that what is actually on the screen when the player is playing is not what ends up in their head. Nor does the player rely directly on any abstract system to make choices. The player's brain builds up a mental model of the game, a sort of virtual representation based upon what they see, hear and do. It's this model that's used when you choose what to do next. This might seem a bit bizarre and counter intuitive but it really isn't. Just consider how a player doesn't rely on direct feedback from the underlying systems in order to traverse a space. They don't bump into every wall in order to check where they can go. Instead they use their knowledge of the real world, intuition of the systems, and visual and auditory clues to plan a path. And once that plan is finished (which for simple tasks like walking takes a fraction of a second), the plan is executed. Stated like this it sounds really trivial, but if you think about it a bit more, it's actually quite profound. The underlying gameplay systems only really become evident for the player if they do something wrong or when they directly contradict their mental model. Otherwise they play and plan largely in part based on an imaginary game. Obviously the underlying system is what keeps it all working, and the feedback between the systems and the player's input is crucial for anything to happen. But the systems are never directly queried to lay out the boundaries and options available to the player. In fact, keeping the player's sense of immersion is often directly related to keeping the systems hidden. The player is not a computer and doesn't make decisions based on tables of abstract data. Built-in brain functions handle all that, and the smoothest sense of play comes about when the player is relying on gut feeling and intuition. Constantly having to probe a system to figure out its exact make-up is almost never a pleasing experience. (Unless that is what the game is all about, as is the case with some puzzle games). Side note: I need to note that the player's intuition is updated the more that a system is revealed to them. If the player first assumes some enemies can jump but later finds out that they can't, their mental model is updated accordingly. This can have devastating effect on a narrative-focused game, making life-like characters turn into dumb automatons and so on. For more information on how all that works, check this out. Brian Upton has a great example of mental modeling in action based on his work with the original 1998 Rainbow Six. In Rainbow Six the player dies from a single shot and has to be very careful how they progress. Since they are constantly on the look out for hostiles, even a very simplistic world can have a lot of gameplay, and that's without the player doing much. For instance, if they are about to enter a new room they stop and try to figure out the best approach. They need to consider if someone might be hiding out of sight and so forth. Based on their mental model of the game they will simulate many different approaches in their mind, trying to figure out which will work best. Even an empty hallway can conjure up these sorts of thought processes. The game is filled with possibilities that the player needs to be aware of, and the only way to do this is to use their intuition on how the game's virtual world and its inhabitants work. These constant mental gymnastics are a crucial piece of the experience. The important point here is that most of what exists in the player's mind has no systemic counterpart. The player might imagine a guard hiding behind a corner, thinking of how he might be looking around. But in reality there is no guard behind the corner. Thus, a great deal of the playing time is spent just imagining stuff. This might seem like a cop-out, and not like proper gameplay, but that's not the case at all. It's sort of like chess, where most of the gameplay comes from you thinking about a situation, and the actual interaction only makes up minor portion of the playing time. Making mental models is very much a valid form of play. The takeaway here is that there is a lot of gameplay which doesn't translate into an input-output loop within the game's systems. And more importantly, this sort of mental model-based gameplay comes from the player's high level interpretation of the game's systems, graphics, sound and so forth. This means that it basically ties directly into narrative. The mental model and the narrative lie on the same level, they are the accumulation of all the lower level stuff. And if we can get them to work together, then what we have is the purest form of playable story where all your gameplay choices are made inside the narrative space. This is clearly something worth striving for. What's also interesting is that these sort of thought processes share the imaginary nature of books and film. The player doesn't have to be 100% correct with all assumptions, just like you don't have to have a perfect mental recreation of the locale a novel takes place in. If the player imagines a non-existent guard being around the corner then that is OK. He might approach slowly trying to get signs of the guard's whereabouts and not finding a guard behind the corner doesn't need to mean the fantasy is broken. The player can now imagine that the guard soundlessly snuck away, or something similar. When interacting directly with systems, like shooting bullets at a clearly visible enemy, the player's assumptions can't stray very far from reality. If the player imagines the bullets hitting when they in fact don't, that fantasy will quickly be broken. Quick note: In case you haven't already noticed, this layer isn't just confined to a single scene. It's something that overlaps a lot of of the game. While you could potentially have mental models that only last for short durations, it is more effective when it spans a greater part of the game. Many narrative games already have some degree of mental modeling, but in the worst way possible: collectables. Say you have this story about a creepy forest and a protagonist trying to figure out what is real. And then picture the mental model constantly saying: "find all the thermoses, you know there are some around". This will obviously make the game lose a lot of its potential. Be wary of this kind of issue. Instead you want to have a mental model that fits with the rest of the narrative. What follows are a few suggestions: Danger There is something lurking about that constitutes a threat for the player. It's important that this threat is not some common occurrence that relies on twitch reflexes or similar, as it's just a normal gameplay element then. Instead it must be something hiding, only making brief appearances. The idea is for the player to constantly scan the environment for clues that the danger is near and present. Goal-focused Mystery This can mean that the player has the objective of solving a crime or similar. What we are after is that the player should see the game world as a place where important clues are to be discovered. So whenever the player finds a new location they should instantly start thinking about what new things it can teach them about the mystery. Social Pressures The player is amongst other people that they have to try and figure out. Now whenever the player finds something new or watches NPCs interact it updates their mental model of what makes the characters tick and what their motivations are. The above should give an idea of what is possible, but as before, there are probably tons more to explore. Now it's time to go back to the example scene and update it with the 4th and final layer. Let's add some sort of danger. Say the player is hunted by shape-shifting demons throughout the game and that these are also a big part of the story. This means the player won't be sure if the man behind the door is a friend or foe. We can tie this into the layer 3 stuff as well; as the player uncovers the narrative background they receive hints about the true nature of the man behind the door as well. We've now gone from just having a really simplistic puzzle about opening a door to an entire story experience. The player is now under threat that there might be some kind of demon on the other side and is desperately trying to find clues on what the secret man's true identity is. At the same time, the man is also the key to a mystery, a mystery the player is very curious to figure out. The player is scavenging for the key, digging up more information as he goes along and when he finally finds it he needs to decide whether to use it or not. The basic gameplay hasn't changed much, but we've changed the wrapping and it totally transforms the experience. Endnotes What I think is extremely interesting about this approach is that it always forces you to think about story. Normally it's so easy to just be satisfied with a well-thought-out gameplay segment and to leave it at that. But when you follow 4-Layers you need to make sure that there's some story significance to the activity the player is currently doing. Story becomes an essential part of the game design. It can also act as a filter. You can evaluate every gameplay scene and make sure it fulfills the criteria in each of the layers. This way you can easily tell if a some segment is just filler, or lacks in some other way. This is a great way to keep the design on track and make sure there is a strong narrative focus. The method is not without its problems though. First is that it requires a lot of planning. You need to design a lot of this up front and it's not very practical to build a scene from experimentation and iteration alone. Design documents are crucial, as there are just too many aspects to keep track of. Second is that its core strength is also the biggest weakness. The gameplay and narrative are intertwined and if you change one the other needs to be updated too. This mean that you need to throw out and remake a lot more than usual during development. But I don't see this as a failure, I see this as evidence that the approach really is bringing gameplay and narrative close together. In a way this approach doesn't really change the core ingredients of a game. It just adds a bit of trickery on top. This is exactly what I like about it though. It doesn't rely on anything that we don't have at our disposal. And, as with all good storytelling, it relies on the audience's imagination doing the bulk of the work. I am really excited to see how this approach will turn out in the finished games. So far it's been of great use to us, and hopefully someone else will be inspired to give it a go. Acknowledgments: Adrian Chmielarz, for all the great e-mail discussions that led to all this and feedback on the talk. Brian Upton, for letting me read an early copy of his book and providing the basis for the Mental Model section. Matthew Weise, for providing valuable feedback to the lecture. Ian Thomas, for copy-editing this whole thing. This article was originally published on the Frictional Games blog, and is reproduced here with kind permission from the author.
  14. This is Orbital Debris, a small game I made in HTML5 with Phaser for a game jam organized by FGL. It won 3rd place! :) Considering I only had 48 hours and was working with technology I'd never used before, I'm really proud of the result. Making Of I assume you've already gone through the Phaser starting tutorials and know how to create a basic game. If this is not the case, please read this and this first. I'm only going to cover the things unique to Orbital Debris. A link to the souce files (code + art) is included with this article. But be warned, it is game jam code and my first time working with Phaser so it's far from perfect code. The Concept The theme set by FGL was "silent, but deadly". Which made me think of "in space nobody can hear you scream". Which made me think back to Gravity, my favorite movie of 2013. And just like that I had my idea within 15 minutes of the jam starting: you play as a space station orbiting the earth and have to dodge space junk released by satellites crashing into each other. Gravity, The Main Inspiration for Orbital Debris Basic Game Logic Orbiting A Planet The first thing I did was get some objects orbiting around the earth. Every orbiter is just a Phaser sprite with some special properties that gets added to a group that contains all orbiters. function spawnNewOrbiter(graphic) { var orbiter = game.add.sprite(0, 0, graphic); orbiter.anchor.setTo(0.5, 0.5); orbiter.moveData = {}; orbiter.moveData.altitude = 0; orbiter.moveData.altitudeTarget = 0; orbiter.moveData.altitudeChangeRate = 0; orbiter.moveData.altitudeMin = 0; orbiter.moveData.altitudeMax = 0; orbiter.moveData.orbit = 0; orbiter.moveData.orbitRate = 0; orbiterGroup.add(orbiter); return orbiter; } Orbiter.moveData.altitude and orbit describe the orbiter's current position relative to the planet. The altitude is the distance from the center, and the orbit is how far along its orbit it is. So making the orbiters move is a simple matter of using the values to update them in Phaser's built-in state update function. So I loop through the group: function updateOrbiterMovement() { orbiterGroup.forEach(function(orbiter) { if (orbiter.alive) { updateOrbiterAltitude(orbiter); updateOrbiterOrbit(orbiter); } }); } And position the orbiters accordingly. function updateOrbiterOrbit(orbiter) { if (orbiter.moveData.orbitRate != 0) { orbiter.moveData.orbit += orbiter.moveData.orbitRate; if (orbiter.moveData.orbit >= 360) { orbiter.moveData.orbit -= 360; } } var oRad = Phaser.Math.degToRad(orbiter.moveData.orbit); orbiter.x = game.world.width/2 + orbiter.moveData.altitude * Math.cos(oRad); orbiter.y = game.world.height/2 + orbiter.moveData.altitude * Math.sin(oRad); } I also set the orbiter's sprite angle to its orbit so it appears aligned with the planet - except for pieces of space junk that rotate according to a tumble rate out of sync with their orbits. if (!orbiter.isJunk) { orbiter.angle = orbiter.moveData.orbit - 90; } else { orbiter.angle += orbiter.tumbleRate; } Player Input I wanted to force players to keep re-adjusting their altitude to stop them from idling at a fixed altitude, and I also wanted movement to feel quite flow-y. So I came up with a simple acceleration-style system. First I check the keyboard and adjust the altitudeChangeRate accordingly. You can think of altitudeChangeRate as velocity towards / away from the earth. function processInput() { if (game.input.keyboard.isDown(Phaser.Keyboard.UP)) { station.moveData.altitudeChangeRate += ALTITUDE_CHANGE_RATE; } if (game.input.keyboard.isDown(Phaser.Keyboard.DOWN)) { station.moveData.altitudeChangeRate -= ALTITUDE_CHANGE_RATE; } station.moveData.altitudeChangeRate = Phaser.Math.clamp( station.moveData.altitudeChangeRate, -ALTITUDE_CHANGE_RATE_MAX, ALTITUDE_CHANGE_RATE_MAX ); } And then I apply it to orbiters like so: function updateOrbiterAltitude(orbiter) { if (orbiter.moveData.altitudeChangeRate != 0) { orbiter.moveData.altitude = Phaser.Math.clamp( orbiter.moveData.altitude + orbiter.moveData.altitudeChangeRate, orbiter.moveData.altitudeMin, orbiter.moveData.altitudeMax ); } } Collision Since all orbiters are added to the same group, a single call to Phaser's built-in overlap method checks for all collisions: game.physics.overlap(orbiterGroup, orbiterGroup, onOrbiterOverlap); All collisions are then checked. Orbiters that are space junk are not processed further, because I only want satellites and stations to spawn junk: function onOrbiterOverlap(orbiterA, orbiterB) { if (!orbiterA.isJunk) { orbiterWasHit(orbiterA); } if (!orbiterB.isJunk){ orbiterWasHit(orbiterB); } } When a satellite or station is hit, I spawn new pieces of space junk. They are just orbiters (just like the space station or satellites). Their altitude, and orbit direction are based on the satellite or station that was destroyed. When the space station is hit, it's a bit of a special case: I spawn a lot more junk than usual to make it feel more dramatic and end the game. function orbiterWasHit(orbiter) { if (orbiter.alive) { var junkQuantity; if (orbiter.isStation) { junkQuantity = 40; } else { junkQuantity = game.rnd.integerInRange(2, 4); } for (var i = 0; i < junkQuantity; i++) { var junk = spawnNewOrbiter(IMAGES_JUNK[game.rnd.integerInRange(0,IMAGES_JUNK.length)]); junk.moveData.altitude = orbiter.moveData.altitude; junk.moveData.altitudeMin = 60; junk.moveData.altitudeMax = 700; junk.moveData.altitudeChangeRate = game.rnd.realInRange(-1.0, 1.0); junk.moveData.orbit = orbiter.moveData.orbit; junk.moveData.orbitRate = game.rnd.realInRange(0.4, 1.2); if (orbiter.moveData.orbitRate < 0) { junk.moveData.orbitRate *= -1; } junk.tumbleRate = game.rnd.realInRange(-10, 10); junk.isJunk = true; } if (orbiter.isStation) { playerDied(); } orbiter.kill(); } } Remaining Bits & Pieces That's pretty much all there is to it! To complete the experience I added some powerups, scaled the difficulty up over time, and added a bunch of HUD stuff and music. And then I was out of time and had to submit the game for the competition. If you have any questions about how anything was done that I didn't explain here, please leave a comment and I'll get back to you. Thoughts on HTML5 / JavaScript / Phaser This was my first time working with the Phaser HTML5 game engine. Usually I avoid unfamiliar technologies during game jams... every hour counts and I don't have time to start learning new things. It was risky, but I decided to try it anyways. I liked that 1) it can run in mobile phone web browsers which makes it easy to share 2) it's similar to flixel which I know inside-out and 3) I already knew some Javascript / HTML5. Overall I really like the engine, it has a lot of great features and is easy to work with. Phaser gets updated often, which is great because it's constantly improving. But it also means that a lot has changed from previous versions. This was sometimes frustrating when I would read about how to do a certain thing in an older version of Phaser, which no longer works the same in the latest version. I plan to use it again soon, but for a hobby project without such a stressful deadline so I can spend more time getting to know it. I could see it one day becoming one of my go-to development tools. Performance I couldn't get the game running smoothly in my phone's browser in time for the deadline, so I had to cancel the mobile version. It's a shame because being able to play the game in mobile phone browsers was the #1 reason I wanted to use Phaser in the first place :( It appears it's something you really have to keep a close eye on. I used the Chrome JavaScript profiler to take a peek at what's taking up most of my processing time. From what I can tell the biggest performance drain is the collision system. Especially when the space station crashes and 30 new pieces of junk are spawned, my iPhone 4S performance slows to a crawl. Using the Chrome JavaScript Profiler to Check for Performance Issues Since I was unfamiliar with the engine, and had to no time to clean up my code or learn how to do things properly I know I did a lot of things badly. I'm careless with creating objects and freeing up memory. I could pre-compute some stuff. I could simplify other things. But I didn't have time to do it. Next time, I'll do better and keep testing on my phone along the way! :D Source Files This is not optimal code. It was my first time working with Phaser. I had a 48 hour deadline. There are lots of things that could should be improved upon. I am including the source files as a download anyways. They are not intended as some sort of model perfect Phaser project. Download at your own risk! This article was orginally posted to Wolf's blog AllWorkAllPlay - head on over there for some more great content
  15. Over the past few years I have had a growing feeling that videogame storytelling is not what it could be. And the core issue is not in the writing, themes, characters or anything like that; instead, the main problem is with the overall delivery. There is always something that hinders me from truly feeling like I am playing a story. After pondering this on and off for quite some time I have come up with a list of five elements that I think are crucial to get the best kind of interactive narrative. The following is my personal view on the subject, and is much more of a manifesto than an attempt at a rigorous scientific theory. That said, I do not think these are just some flimsy rules or the summary of a niche aesthetic. I truly believe that this is the best foundational framework to progress videogame storytelling and a summary of what most people would like out of an interactive narrative. Also, it's important to note that all of the elements below are needed. Drop one and the narrative experience will suffer. With that out of the way, here goes: 1) Focus on Storytelling This is a really simple point: the game must be, from the ground up, designed to tell a story. It must not be a game about puzzles, stacking gems or shooting moving targets. The game can contain all of these features, but they cannot be the core focus of the experience. The reason for the game to exist must be the wish to immerse the player inside a narrative; no other feature must take precedence over this. The reason for this is pretty self-evident. A game that intends to deliver the best possible storytelling must of course focus on this. Several of the problems outlined below directly stem from this element not being taken seriously enough. A key aspect to this element is that the story must be somewhat tangible. It must contain characters and settings that can be identified with and there must be some sort of drama. The game's narrative cannot be extremely abstract, too simplistic or lack any interesting, story-related, happenings. 2) Most of the time is spent playing Videogames are an interactive medium and therefore the bulk of the experience must involve some form of interaction. The core of the game should not be about reading or watching cutscenes, it should be about playing. This does not mean that there needs to be continual interaction; there is still room for downtime and it might even be crucial to not be playing constantly. The above sounds pretty basic, almost a fundamental part of game design, but it is not that obvious. A common "wisdom" in game design is that choice is king, which Sid Meier's quote "a game is a series of interesting choices" neatly encapsulates. However, I do not think this holds true at all for interactive storytelling. If choices were all that mattered, choose your own adventure books should be the ultimate interaction fiction - they are not. Most celebrated and narrative-focused videogames do not even have any story-related choices at all (The Last of Us is a recent example). Given this, is interaction really that important? It sure is, but not for making choices. My view is that the main point of interaction in storytelling is to create a sense of presence, the feeling of being inside the game's world. In order to achieve this, there needs to be a steady flow of active play. If the player remains inactive for longer periods, they will distance themselves from the experience. This is especially true during sections when players feel they ought to be in control. The game must always strive to maintain and strengthen the experience of "being there". 3) Interactions must make narrative sense In order to claim that the player is immersed in a narrative, their actions must be somehow connected to the important happenings. The gameplay must not be of irrelevant, or even marginal, value to the story. There are two major reasons for this. First, players must feel as though they are an active part of the story and not just an observer. If none of the important story moments include agency from the player, they become passive participants. If the gameplay is all about matching gems then it does not matter if players spend 99% of their time interacting; they are not part of any important happenings and their actions are thus irrelevant. Gameplay must be foundational to the narrative, not just a side activity while waiting for the next cutscene. Second, players must be able to understand their role from their actions. If the player is supposed to be a detective, then this must be evident from the gameplay. A game that requires cutscenes or similar to explain the player's part has failed to tell its story properly. 4) No repetitive actions The core engagement from many games come from mastering a system. The longer time players spend with the game, the better they become at it. In order for this process to work, the player's actions must be repeated over and over. But repetition is not something we want in a well-formed story. Instead, we want activities to only last as long as the pacing requires. The players are not playing to become good at some mechanics, they are playing to be part of an engrossing story. When an activity has played out its role, a game that wants to do proper storytelling must move on. Another problem with repetition is that it breaks down the player's imagination. Other media rely on the audience's mind to fill out the blanks for a lot of the story's occurrences. Movies and novels are vague enough to support these kinds of personal interpretations. But if the same actions are repeated over and over, the room for imagination becomes a lot slimmer. Players lose much of the ability to fill gaps and instead get a mechanical view of the narrative. This does not mean that the core mechanics must constantly change, it just means that there must be variation on how they are used. Both Limbo and Braid are great examples of this. The basic gameplay can be learned in a minute, but the games still provide constant variation throughout the experience. 5) No major progression blocks In order to keep players inside a narrative, their focus must constantly be on the story happenings. This does not rule out challenges, but it needs to be made sure that an obstacle never consumes all focus. It must be remembered that the players are playing in order to experience a story. If they get stuck at some point, focus fades away from the story, and is instead put on simply progressing. In turn, this leads to the unraveling of the game's underlying mechanics and for players to try and optimize systems. Both of these are problems that can seriously degrade the narrative experience. There are three common culprits for this: complex or obscure puzzles, mastery-demanding sections and maze-like environments. All of these are common in games and make it really easy for players to get stuck. Either by not being sure what to do next, or by not having the skills required to continue. Puzzles, mazes and skill-based challenges are not banned, but it is imperative to make sure that they do not hamper the experience. If some section is pulling players away from the story, it needs to go. Games that do this These five elements all sound pretty obvious. When writing the above I often felt I was pointing out things that were already widespread knowledge. But despite this, very few games incorporate all of the above. This is quite astonishing when you think about it. The elements by themselves are quite common, but the combination of all is incredibly rare. The best case for games of pure storytelling seems to be visual novels. But these all fail at element 2; they simply are not very interactive in nature and the player is mostly just a reader. They often also fail at element 3 as they do not give the player much actions related to the story (most are simply played out in a passive manner). Action games like Last of Us and Bioshock infinite all fail on elements 4 and 5 (repetition and progression blocks). For larger portions of the game they often do not meet the requirements of element 3 (story related actions) either. It is also frequently the case that much of the story content is delivered in long cutscenes, which means that some do not even manage to fulfill element 2 (that most of the game is played). RPGs do not fare much better as they often contain very repetitive elements. They often also have way too much downtime because of lengthy cutscenes and dialogue. Games like Heavy Rain and The Walking Dead come close to feeling like an interactive narrative, but fall flat at element 2. These games are basically just films with interactions slapped on to them. While interaction plays an integral part in the experience it cannot be said to be a driving force. Also, apart from a few instances the gameplay is all about reacting, it does not have have the sort of deliberate planning that other games do. This removes a lot of the engagement that otherwise comes naturally from videogames. So what games do fulfill all of these elements? As the requirements of each element are not super specific, fulfillment depends on how one chooses to evaluate. The one that I find that comes closest is Thirty Flights of Loving, but it is slightly problematic because the narrative is so strange and fragmentary. Still, it is by far the game that comes closest to incorporating all elements. Another close one is To The Moon, but it relies way too much on dialog and cutscenes to meet the requirements. Gone Home is also pretty close to fulfilling the elements. However, your actions have little relevance to the core narrative and much of the game is spent reading rather than playing. Whether one chooses to see these games as fulfilling the requirements or not, I think they show the path forward. If we want to improve interactive storytelling, these are the sort of places to draw inspiration from. Also, I think it is quite telling that all of these games have gotten both critical and (as far as I know) commercial success. There is clearly a demand and appreciation for these sort of experiences. Final Thoughts It should be obvious, but I might as well say it: these elements say nothing of the quality of a game. One that meets none of the requirements can still be excellent, but it cannot claim to have fully playable, interactive storytelling as its main concern. Likewise, a game that fulfills all can still be crap. These elements just outline the foundation of a certain kind of experience. An experience that I think is almost non-existent in videogames today. I hope that these five simple rules will be helpful for people to evaluate and structure their projects. The sort of videogames that can come out of this thinking is an open question as there is very little done so far. But the games that are close to having all these elements hint at a very wide range of experiences indeed. I have no doubts that this path will be very fruitful to explore. Notes Another important aspects of interaction that I left out is the ability to plan. I mention it a bit when discussing Walking Dead and Heavy Rain, but it is a worth digging into a little bit deeper. What we want from good gameplay interaction is not just that the player presses a lot of buttons. We want these actions to have some meaning for the future state of the game. When making an input players should be simulating in their minds how they see it turning out. Even if it just happens on a very short time span (eg "need to turn now to get a shot at the incoming asteroid") it makes all the difference as now the player has adapted the input in way that never happens in a purely reactionary game. The question of what is deemed repetitive is quite interesting to discuss. For instance, a game like Dear Esther only has the player walking or looking, which does not offer much variety. But since the scenery is constantly changing, few would call the game repetitive. Some games can also offer really complex and varied range of actions, but if the player is tasked to perform these constantly in similar situations, they quickly get repetitive. I think is fair to say that repetition is mostly an asset problem. Making a non-repetitive game using limited asset counts is probably not possible. This also means that a proper storytelling game is bound to be asset heavy. Here are some other games that I feel are close to fulfilling all elements: The Path, Journey, Everyday the Same Dream, Dinner Date, Imortall and Kentucky Route Zero. Whether they succeed or not is a bit up to interpretation, as all are a bit borderline. Still all of these are well worth one's attention. This also concludes the list of all games I can think of that have, or at least are close to having, all five of these elements. Links http://frictionalgames.blogspot.se/2012/08/the-self-presence-and-storytelling.html Here is some more information on how repetition and challenge destroy the imaginative parts of games and make them seem more mechanical. http://blog.ihobo.com/2013/08/the-interactivity-of-non-interactive-media.html This is a nice overview on how many storytelling games give the player no meaningful choices at all. http://frictionalgames.blogspot.se/2013/07/thoughts-on-last-of-us.html The Last of Us is the big storytelling game of 2013. Here is a collection of thoughts on what can be learned from it. http://en.wikipedia.org/wiki/Visual_novel Visual Novels are not to be confused with Interactive Fiction, which is another name for text adventure games. Thirty Flights of Loving This game is played from start to finish and has a very interesting usages of scenes and cuts. To The Moon This is basically an rpg but with all of the fighting taken out. It is interesting how much emotion that can be gotten from simple pixel graphics. Gone Home This game is actually a bit similar to To The Moon in that it takes an established genre and cuts away anything not to do with telling a story. A narrative emerge by simply exploring an environment. This article was originally published on the Frictional Games blog and is republished with kind permission from the original author Thomas Grip.