5 posts tagged “teams”

I'm going to take a break from the Audio-Visual tutorials and talk a little bit about game development, specifically the teams that make it up. While game development can be a dawning task, I have come up with a few helpful hints on putting together a team that should help keep you on track.

1. Artists - Sketching
   You don't need much if you're just starting out, but it's always good to be able to sketch up a concept, if not at least have someone on the team who can. Sketching can be anywhere detailed as it needs to be. Concepts shouldn't take very long to sketch depending on it's scope. A concept artist should be able to take what the game designer(s) create(s) and sketch that into a visual. Often times a sketch artist will need to go into more detail by using actual rendering tools like Photoshop or something similar.
   
   
2. Artists - Modeling
   If you are going to be working with 3D games it is a necessity to have someone on the team with enough experience in 3d modeling. This artist should be able to take what the sketch artist has come up with into a realistic 3d visual. Unless there is a texture artist available, texturing will often be performed by this artist as well.
   
   
3. Artists - Texturing/Shading
   When resources are available, a game development team may also include texture artists. In this role, the person should be able to combine the efforts of the sketch artists with the modelers in order to create the final visual in the title. Texturing itself is usually done in layers depending on the amount of detail necessary. It is not uncommon for these artists to also perform shading techniques on top of their normal tasks.
   
   
4. Artists/Musicians - Sound
   Sound, because no game is complete without the necessary audio-visual aspects. This artist should be in charge of providing all the necessary sound effects, music and fonts needed for a given game title. This role may be played by a developer but it is usually filled by ones with musical and artistic skills.
   
   
5. Designers - Game Design
   For the most part game design is a collaborative effort, but it is best to have someone who concludes the final design on game concepts. The game designer should be able to explain what to include as well as exclude from a game title. Often times this designer will perform consulting on visual aspects of the gameplay as well as general environmental factors that make up the game.
   
   
6. Developers - Game Development
   The core of the team who's role is to put the pieces of the puzzle together. This role can vary in many scenarios depending on the requirements of the game. The job may include writing networking code, artificial intelligence, camera angling, character movement and interaction among other tasks that the game may require. Be sure to understand the necessities of the game and the availability of tools before choosing this role and the skills.

While it's not entirely necessary to have the above people on your team, you or the people on your team may fill one of the above roles at some point in your game development cycle. As you progress, it will be necessary to also have testers on the team, but I've always approached this issue with test-driven development.

Aside from roles on a game team, there are a few things to keep in mind about creating a game. The first is the concepts included or excluded in a game. When in doubt, prototype your concepts as quickly as possible. Quick designs or sketches for a prototype shouldn't take more than an hour or two and if it does then it needs to be simplified. Building on concepts isn't necessary bad though; the larger and more complex a concept gets, ideally, the more prototypes you should already have. By then end of your game designing phase you should be able to present each aspect of the game with prototypes.

That's all for now :)

Leadership is -

"the ability of an individual to influence, motivate, and enable others to contribute towards the effectiveness and success of the organizations of which they are members."
- R.J. House

"Leadership does not involve changing the mindset of the group, but the cultivation of an environment that brings out the best (inspires) the individuals in that group..."
- Arthur F. Carmazzi

Over time I have written quite a few posts on project dynamics, software development, methodologies and even tutorials on code. I have tried to evolve the concept of working in teams from a simple schedule put together with a series of methodologies that may help the team in one way or another. I think it's important to understand the major difference between a manager and a leader.

• Managers administer
• Leaders innovate
• Managers ask how and when
• Leaders ask what and why
• Managers focus on systems
• Leaders focus on people
• Managers do things right
• Leaders do the right things
• Managers maintain
• Leaders develop
• Managers rely on control
• Leaders inspire trust
• Managers have a short-term perspective
• Leaders have a longer term perspective
• Managers accept the status-quo
• Leaders challenge the status-quo
• Managers have an eye on the bottom line
• Leaders have an eye on the horizon
• Managers emulate the classic good soldier
• Leaders are their own person
• Managers copy
• Leaders show originality

It's also a good point to understand that within teams, with leaders, we can have two different types of leadership paths. One of them is called transformational leadership. (idealized influence - charisma, inspirational motivation, individualized consideration, intellectual stimulation). Transformational leaders develop a vision, sell it, find the way forward and usually leading the charge.

On the other hand there are transactional leaders (contingent rewards, management by exception). It's important to note that there are certainly times where you have to be able to change from either transformational to transactional with people. Some members of the team simply 'get it' and thus you can approach them with a sense of transformation and evolution within the vision. However, with other members you must approach with transaction, steps, processes that require the members to complete things in line. Even if it's not about approaching the members with the perspectives it's really about the balance in timing when it comes to the types of leadership within a team.

Generally speaking, software is complex, I mean really complex. It can be so compounded in complexity that even the developers themselves can't even begin to imagine the extensibility, the portability, the usability of their software. But wait, is this what true genuine software is all about? Basing our features off of every intricate detail we can think of, utilizing everything around us in an attempt to develop the most broad, platform-independent software solution on the face of the planet. I think not. True software, built with a vision and a persona can be like painting a picture, all the little details and patterns are just apart of technique.

Imagine yourself as Michaelangelo, in the Sistine Chapel, painting one of the most intricate paintings every to be made. How is art created? Where does it start? What form does it take, and what do you need to create it? Not one of these questions can be answered because to painters, it simply doesn't matter. To a painter, art takes a natural form of emotion, expressing the deepest pieces of an elaborate puzzle brought forth by a master creator.

We can shape our emotions and dreams into a form in which we call a vision. The vision itself is relative to where you are in the process. It takes time, it grows into something better, something newer and more extravagant with more emotion. The vision is really just a small piece of a large picture to which we may only see at the end of the tunnel.. or at least when we've stopped. In painting, drawing or any form of art really you simply search for a picture, something to create, something that represents a series of emotions and personifications. If the art was formed to represent those emotions and persona's, for a great deal of the time, we can call it beautiful. It's simply a matter of time to detail every aspect of our masterpiece to give further depth to the emotion within the art.

In most software we do have an emotional attachment of sorts. It's everywhere really. Using Ubuntu over XP maybe a principle based on a goal or a set of rules that you may follow by. Or rather, Vox is great for me because it never seems like I'm trying to manage my blog in some alternate universe, I'm always there with my blog; editing and posting away. It's quite nice.

On the other hand software has a huge tendency to put the wrong emotions into people. The triggering of anger and frustration, hesitation and stupidity can be quite disheartening to users and usually ends up with the application un-installed and unused. We can find truth in our ability to create quality, art-form software however.

1. Persona
• Define a person, no an actual person that lives, breathes and moves around in your world. And your software is what runs a very key part of his/her life. This persona is what allows you to focus on the reactions and attachments held with your software. You can take a step back and actually see the big picture.
• Design for them, the interactions, the emotions and all the responses from the program. Imagine them reacting to your software after seeing something they hadn't yet caught before.
• Persona sparks a team with creativity and imagination, it works fantastic!
  
2. Imagine, and just paint it
• Software is an evolution of details, patterns and components. It takes both time, creativity and efforts. Building an extensible framework before understanding who uses the program is a major flaw in planning.
• Don't worry to much about the 'technical' details of creating your software. Developers will always want their software portable, used in a web browser or modular with new frameworks for best performance.
• Users will not, have not and have not cared about these things and should not be your area of focus. Just code it with a model in mind, sketch your designs, and practice technique.
• Coding software, although can be more complex, is actually one in the same when it comes to painting. Except in painting, you are required to have patience, diligence and the ability to morph and grow your picture into a masterpiece.

Masterpiece software takes time, patience and diligence. The ability to grow your software into something great will take more than a few hacks at portability and extensibility, focus on the bigger picture, the emotion, and the code will almost naturally flow. You'll naturally refactor and optimize your code when you get it right, it's like adding the few details to the fingers on a painting or the pupils of an eye, or a mold of a magnificent sculpture.

Let's face it, our industry has its problems in the completion of quality software products. Deadlines have been missed, projects have been thrown away, people have been fired, hired with a bundle of project developments that have either been redesigned or re-engineered to meet project expectations; keyword being expectations. With all the issues of software and its complexity has anyone thought to ensure the quality of our teams? There are plenty of people who have; in fact, any project manager will select a group of qualified people to complete a project. However, basic skill sets and aptitudes are far different then the understanding of how each attributes to the team's collaboration and cooperation. There are several approaches to figuring this out however:

1. Assessments
• Have each member of the supposed team to take a test that addresses a person's thought process and emotional stator when functioning both alone and in a team environment.
• There are plenty of assessments that can be used to determine where a person stands in a team setting.
• Color Code - developed in the 1980s by Taylor Hartman, Ph.D. Both the Color Code and the Character Code (the two famous Hartman personality tests) have become the preferred method of self-awareness discovery for numerous colleges and universities, researchers, Fortune 500 businesses, professionals, small business owners, parents, married couples, students and more.
• Once you can identify where a person stands before the project is months in development, you can effectively account for the dynamics of communication in a team setting.
2. Identify Capabilities vs Personal Goals
• Commonly in a team setting you will have people who want to work on certain parts of a product while people who have the skills necessary will work on other things. The problem usually originates from a perceived plan for the project or the lack thereof. This is why when you approach any project there should already be a general guideline to the goals and vision of the product at hand. Unless, of course, the team is brainstorming what exactly that vision really is.
• Brainstorming works really well in team settings. The type of collaboration it takes to brainstorm is really quite powerful and enriching to a team. This, of course, does mean that everyone should try to participate in the brainstorm, making sure that ideas are not left unheard or analyzed.
• Know what you want and what you can to do in the team!
• To many times I have seen people go into a team and generally say that they don't care what they work on. You should already know what you're good at and what you aren't good at. What you are willing to take on and what you're not. This will be mostly based on how you see the plan in line with your abilities and aptitude to complete your part.
  
• For instance: I'm fairly aware of structure of C++, however I have never coded an entire piece in C++. Weighing this against the schedule and the abilities of others, I may choose to devote more time here or more time elsewhere depending on what needs to get done and who can already get it done.
  
• I could work with someone else if I'm certain that I know what this portion is about.
  Think Architects and Specialists
  

Once a vision is formulated, there should a plan for building the components that make up the product itself. This plan should allow the team to form a variance of collaboration and cooperation to complete each piece.

• Collaboration: To work together, especially in a joint intellectual effort.
• Cooperation:   To work in parallel, so that work can be divided and put together in a joint effort.
  
  Note: plans need to have milestones in scheduling. Schedules are a necessity, even if loosely created, it gives a general means of product devotion from the team. Whether the team works slow or fast, there can be a bar set to which the team can evaluate their progress against..

Remember that these are guidelines that you can follow and keep in mind in the process of development. It's a way of assessing and evaluating a team according to the members that are involved. However, this does not cover timing and communication between people. The stages of team development are indeed a big part of a project's success. I'll will cover this in my next post.

SCS, or Simply Complex Software, is a way of describing a program that is complex in a really direct kind of way. The level of complexity depends on the depth of the application and to what extents it may reach. There are essentially two types of software that inherently make it complex: 1. the software is complex by the nature of what it must accomplish, simulate and acquire to present data to the user and 2. the interaction is complex by the nature of bad design.

It's easy to say, this software should be simple to use, intuitive, interactive... you can throw all the words at your requirements as long as you have time to. The principle lyes in the goals of the team in developing the software. Simplicity for development or simplicity for user interaction. Questions that may arise in the cycle of interaction design include:

• Is this something a user can move and resize?
• Does this relate to a goal that the user is trying to accomplish?

Questions that involve persistence and existence levels should be the main points to consolidate. Persistence meaning for how long, existence meaning where. Interaction with software has of course grown over the years where we can effectively ask these questions so our users aren't constrained with the natural complexities that make up software. There are base interpretations to building software that make it apparent that certain tasks should not have to be done by the user. The very reason behind this is because, in code, we are perfectly capable of handling the extra steps necessary to complete the goal. This should be a general train of thought when approaching interaction design.

Users aren't meant to understand network protocols, binary data, hexadecimal commands, error codes, error messages, and even going to the extent of the strenuous tasks that make up our computing lives. File management is something that can be kept in mind for automation, so long as it follows user intentions. Even something as simple as a file path is useless to a user, it involves directory structure and is usually arbitrary.

Moving on to the reasoning why most software is neither simple to use or complex in its depth. I address this because most developers ask far too much of a specific feature. A PM will introduce a feature, documented no less, the team will continue to discuss interaction, to which varies insurmountably, and finally the team gets to developing. Vision, idea, documentation is far away from what code can produce. There are normally two bumps in development that may deter the original vision, either the vision is overkill and too much and the team accepts it regardless or the vision is still complex and the team undermines it by their abilities and/or development time. Point stated, team dynamics destroy what could be simply complex software.

And a note from Kathy Sierra's blog:

I think we'll have to take a moment to start understanding team dynamics next...