Jump to content
  • Advertisement
  • 04/03/18 08:31 PM

    The Gaming Industry and Agile methodologies

    Production and Management

    • Posted By jb-dev

    As the gaming industry advances and evolves, new ideas can suddenly popup and change the way things goes in an instant.

    I've worked for 2 years in a Agile-centered startup. I've experienced first hand what agility can do to boost productivity and reduce development cost. It's a really simple and pleasant thing to work with agility, and maybe the gaming industry can benefit from it.

    The values

    Everybody that knows agility should be able to understand the core values of the Agile Manifesto.

    To put it simply, we should value:

    1. Individuals and interactions over process and tools;
      (i.e. work geographically close rather than remotely or value genuine conversations over Skype)
    2. Working software over comprehensive documentation;
      In our case, the game MUST be fun (or work correctly) before anything else
    3. Customer collaboration over contract negotiation;
      Basically, make the player more involved in the game's development
    4. Responding to change over following a plan.
      This is, of course, directly dependent of point 3

    Also, keep in mind that it's mostly an hypothesis. As the manifesto states :


    We are uncovering better ways of developing software by doing it and helping others do it

    Doing Agile vs. Being Agile

    During the past 2 years, our scrum master always warned us about the impostors, or the people that are "Doing Agility". Things like using a Kanban board or doing Daily Scrums wont make your team Agile. It's all about the values.

    These tools should be used to apply those values rather than using them just because it's a trend. 

    For exemple, some teams uses a Scrum backlog while locking it's content to everybody other that the project owner. This puts the project on rails, and can just be a waterfall process disguised as something agile.

    How can the gaming industry can benefit from it?

    As we keep seeing video games cost more and take a lot more time to develop, the customers grows more and more displeased: There are bugs-a-plenty on crucial mechanics, while relatively small and insignifiant functionalities are well polished and bug-free.

    Getting the game as fast as possible in the hands of beta players 

    The first thing to do is to involve the player as fast as possible in the game development's cycle. Doing that will significantly improve the player's sense of content and can make the game better. In the past, this kind of development wasn't practical, but, with the development of broadband, it's now possible.

    Early Access

    Nowadays, people talks about "Early Access". For those living under a rock, early access is a way of distributing a game in which the game itself isn't completed in a traditional sense. The customer then buys an somewhat incomplete game, of which many features will come later.

    This process is by far the best idea the industry never had.

    However, due to some mishandling of said practice, it's now regarded as a sing of cheapness and greed.

    If the ones doing it are agile impostors, then yes. There are times where games simply gets abandoned by their maintainer. These instances gives early access some bad name. 

    Early access should also be used in Agility in a form of customer collaboration. For example, one could ask a random early access player to participate in the planification of a sprint.

    If the team isn't confortable with the idea, then maybe a suggestion box can be plugged directly in the backlog...

    Prioritizing mechanics based on feedback

    Getting feedback form customers is an important thing in Agile Methodologies. The backlog can be prioritized based on player feedback and feature requests. 

    The same thing can be used on bugs. The more frequent it becomes, the more critical it becomes.

    Minimal efforts of development

    In most cases, the backlog should be prioritized based on business value rather that complexity. Being so, things that are developed first are important (or so the team thinks) to the game, while less important functions aren't implemented right away and have time to simmer down. Paired with early access, this becomes a quite powerful tool to test out hypothesis and experiment with mechanics.

    Due to the iterative process of some methodologies, functionalities are minimal and doesn't require a whole lot of effort to develop: after all, we have no idea if a mechanic is going to be loved or hated by a player until said players plays the game.

    Change prone games

    Another important argument is that Agility is generally speaking change tolerant. In our case, this means that if the beta players disliked or liked a newly implemented feature, then said feature should be remove and subsequent features should also be re-evaluated.

    The importance should always change based on discoveries made by the team or even the project owner. It is considered healthy for a backlog to change it's feature's priority. Otherwise, it's a bad omen...

    How about me?

    Agile is first and foremost a philosophy, or a way of life. Sure, it can easily be imposed to people, but it's in these situations that you get fake Agility. It should be a conviction more that a rule: a rule should be static and shouldn't change a lot. 

    Agility starts with the team. If one of it's member isn't committed, it will go sour really fast.

    I've seen so many times that Agility can be broken by a malicious person (a saboteur if you will). The best thing you can do to an Agile team is to be, yourself, agile.


    Agility should be an integral part of game development. With Agile, you can easily prioritize mechanics that are crucial for having a fun and interesting game.  

      Report Article

    User Feedback

    Create an account or sign in to leave a review

    You need to be a member in order to leave a review

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now

    There are no reviews to display.

  • Advertisement
  • Advertisement
  • Latest Featured Articles

  • Featured Blogs

  • Advertisement
  • Popular Now

  • Similar Content

    • By babaliaris
      There are two projects. One is called VampEngine (a Shared Library) and the other Application (A console application).
      The VampEngine contains a VampEngine::Core class. This function contains a void VampEngine::Core::MainLoop() method.
      There are also two extern C functions void *Vamp_Core_Constructor() and Vamp_Core_MainLoop(void *obj)
      Now, this is what happens:
      The client is calling void *Vamp_Core_Constructor() in order to create a VampEngine::Core which lives inside the Shared Library. And also casts this void object into a Core object.
      The void VampEngine::Core::MainLoop() is being implemented both in the Shared Library and in the client. The client's MainLoop() is just a wrapper for calling the extern c function Vamp_Core_MainLoop(void *obj)
      The code compiles and links in both Windows and Linux. When you run it on Windows, MainLoop() (shared library's implementation) is getting called, but on Linux, there is a recursive call in the client's MainLoop() implementation.
      The behavior in each Operating System can be shown below:

      You can check the project (It's small, I just started it ) On my GitHub Repo . Also, I have a Premake script if you want to check the code for yourself. You are most interested in the files:
      API.h  EntryPoint.h  Application.hpp  Core.cpp  Core.h  Core.hpp  Main.cpp
      This might explain the problem in a better way:
      The Core class has two implementations of the Core::MainLoop(). One is implemented inside the DLL and the other in the client. The client's implementation is just a wrapper which calls a c extern function (which lives in the dll) which actually calls the MainLoop() implemented inside the DLL. 

      Now in visual c++, because I'm only exporting that c extern function, Core::MainLoop() acts in a polymorphic way. The client calls his implementation of Core::MainLoop() which calls the extern function and eventually the Core::MainLoop() inside the dll runs.

      On linux, I believe by default all the symbols are getting exported. And this is the behavior I saw using a debugger:

      The client calls Core::MainLoop() , this calls the extern function, the extern function calls again Core::MainLoop() but instead of running the dll implementation it actually runs the the clients implementation. It's like the clients Core::MainLoop() is calling itself over and over again!
      I located the above behavior using gdb debugger on Linux. I just noticed the client's implementation was getting called in a recursive way instead of acting polymorphically ending up calling the implementation of the dll's MainLoop()
    • By Driv
      I am pretty new to gamedev and am toying around with my first game.
      I have my own crude 3D engine I've built using Monogame. I am trying to optimize my rendering pipeline. Here's my scenario:
      I have a number of 3D playing cards I want to render. The models have  front, back and side (single model made up of different mesh parts). The back is the same for a number of models being rendered. So are the sides. The front is mostly different. For my deck, I can see the front of the cards (and not the back), and for the enemy deck, I can only see only the back of his / her cards.
      The card model is made up of a single set of vertices and indexes with a different start index for the different mesh parts (front, back and sides). The textures are not atlased, which allows me to easily set the front and back textures accordingly. 
      To optimize rendering, I could do the following:
      1. Render each card separately (which would be made of of 3 draw calls per card viz. front, back and side). Since they all share the same vertex buffer, only the textures would differ. This reduces the vertex and index buffer switches.
      2. Sort by texture and render the different mesh parts separately viz. all card backs get rendered sequentially, followed by card fronts, sides etc. This will optimize texture switches, but the vertex and index buffers will keep switching since a single card has a single vertex buffer shared by 3 mesh parts viz. front, back and side.
      I am a bit confused about which is most optimal. I would think that rendering the card in one go would be best since the vertex and index buffers are shared, but all the reading I've done thus far indicates that you should avoid texture switches, so sorting the mesh parts by texture sounds like it's the way to go, but would result in more vertex and index buffer switching.
      Any advice would be appreciated!
    • By hyyou
      If a 3D shape (e.g. in Maya/Blender) is edited (e.g. extrude), the underlying UV often should be edited as well.
      The UV editing is useful - to make a triangle occupy enough texture pixel, and make texturing artist work easier.
      However, it is a tedious and very repetitive process.   
      Fortunately, Maya can automatically update UV and the underlying texture.
      (^ reference : https://knowledge.autodesk.com/support/maya/learn-explore/caas/CloudHelp/cloudhelp/2018/ENU/Maya-Modeling/files/GUID-6AB281B4-1653-4CC5-B4D4-A87516261F2E-htm.html  )
      But, what if the texture is created by Photoshop? 
      I don't think Maya will automatically hack into my ".psd" file.  Thus, my original Photoshop file will be deprecated/obsoleted.
      What is your workflow when editing a shape?  As an artist, do you feel tedious that UV and/or underlying image have to be edited as well?  How do you solve it? I am new to 3D modeling.
    • By Altadsa
      Finishing up my year internship as a Unity developer at the end of August. My boss and I were talking about keeping me on the project afterwards as a remote developer (though his company wouldn't be able to register me as an employee so it would be more like contract work). While he said he would need to talk to his boss about it (to sort out pay etc.). I was wondering how I would even go about setting it up from my end. I'll still be at University when I finish the internship in August, so it would be more like part-time work. The issue is that I normally live in the UK while the company is based in Switzerland so I have no idea how it works when it comes to taxes etc. Is it technically possible to work remotely this way, and if so, what would I need to find out in advance (in regards to taxes, working regulations and insurance)?
    • By RoKabium Games
      Our first interview! Click the link below and read what @IndieRanger had to write about us.

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!