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

    The Gaming Industry and Agile methodologies

    Production and Management

    jb-dev
    • 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 :

    Quote

    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


    There are no comments to display.



    Create an account or sign in to comment

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

    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

  • Advertisement
  • Advertisement
  • Latest Featured Articles

  • Featured Blogs

  • Advertisement
  • Popular Now

  • Similar Content

    • By babaliaris
      So I've heard that rendering front-to-back can increase performance due to the z buffer. I understand how this works but what happens to blending? In order for blending to work you need to render from back-to-front. Moreover:
      For blending, the technique I know and use, is that in every frame I calculate the distances of all the objects from the camera, then order the objects in descending order from larger distance to smallest and then render first, the objects which are farther from the camera.
      This has two disadvantages, first the calculation of the distances and the ordering take some time and secondly I can't use front-back rendering. The first disadvantage can be optimized with a tree queue quite well but still I need to go through all the objects in order to generate that tree (nlogn total time).
      Is there a way to mix this blend technique with front-end rendering? or am I stuck except if my scene does not use transparent objects at all? 
    • By incogni7o
      I'm not sure how to phrase this and where I should post this, I need some feedback. I get no input being stuck in my head for too long and I don't wish to waste my time on a mere thought. I had an idea and thought that it would make sense expressing it in the form of a game. I am not really a beginner but new to game development..
      I do know C++, Python, C# and C but I never made a game before other than the simple tutorial games everyone has to make. I figured my idea was too complex at this point in time and decided to carefully craft out another project that would slowly force me to progress in skill, alongside the development process. I tend to do all my development on Notepad++/gVim and MinGW. Visual studio is great just a little too complicated for me. I'll be taking computer science in Uni so I expect Ill have to get comfortable with it soon.
      The current game i have in mind is a 2d top down pixel game. No procedural generation, no complex inventory management, no complex fighting mechanics.
      Now I personally don't want to use a game engine for i find it to be unnecessary with regards to the nature of the game and its simplicity, also game engines tend to be rather bloated with featured I do not currently require. I would prefer using the most optimal tool even if it means forgoing speed. Don't get me wrong, I don't have ideological views toward game engines or operating systems etc Its just a tool to me and I would very much prefer using a hammer to knock in the nails, the tool most suited for the job. I don't like waste or excess. As such for a simple 2d game such as mine, I've been looking at frameworks instead of game engines. SDL(Not really a game framework), SFML(which seems a little more up my alley), raylib(I'm a little doubtful about in the long run), Allegro (could not find many tutorials) and monogame/fna(limits me to Windows mainly, which isn't really an issue as of yet).. However I noticed that for most game developers who tend to use these frameworks, the general pattern seems to point towards them building an inhouse engine for their game, then building their game when they think it's ready.
      Unity makes it easy, but Its not.. Its just not the right tool and I'll end up being dependent on the engine rather than the code.
      I don't know enough to make an engine, and I personally am much more interested in building my game than the engine. I do find engine development interesting, but It would take up a lot of time, and this is where my question lies.. Would it be possible to make a full blown 2d rpg-ish game with a game framework, without building a game engine and just focusing on game code?
      .. By that, I'm assuming a game engine is a separate piece of software/framework. I would really like some advice and feedback/thoughts on what I said and my question..
    • 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!
       
      Conclusion:
      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
      Hi,
      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!
       
       
×

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!