Monthly Archives: January 2014

Creating Textures from Stock Photos

Creating textures for a model can either be ridiculously easy or devastatingly difficult, depending on the complexity of the model, the UV mapping of the model and the available textures. For this project I was really interested in creating our own texture assets. This means photographing or painting the textures ourselves. And since I’m not much of a 2D artist, I went down the photography road.

We had to establish the visual design of the game and a general idea of which models would be present in-game in order to decide which textures would be needed. After we had a list of various game objects and an idea of the architecture and different types of buildings in the game environments, I could proceed to jot down a list of textures that would be necessary. Then I simply took half a day of walking around town photographing the materials on my list. For example: brick wall, asphalt, ventilation system, window, door etc.

The camera I’ve been using is a Nikon D3100, a pretty standard  DSLR camera with a basic 55mm lens. This is one of the photographies I collected. It’s a simple grid I found on the window of a storage room door.

So now we’ve got the stock photo. What next?

Camera lenses are concave, like the human eye. Thus, straight lines will be bent in the photography if the photo was taken up close, as you can see on the image above. It’s kind of bulging. In order to make a decent texture out of it, we will need to process it quite a bit in an image editing program. In this case I’m using Photoshop which has something called Lens Correction (found under the Filters tab) which fixes this issue, and even has predefined settings for my specific camera.

Here’s the result after using Lens Correction. You can probably spot the difference.

Fixing the white balance

I took this image on a cloudy day and even though I tried to fix the white balance in the camera, but the image still came out quite pale and bluesy. To fix this I’m doing the steps explained in this tutorial basically using an adjustment layer for Levels and eye dropping the dark and bright portions of the image.


Creating a repeating texture

In the case of this particular texture, lens correction might not be absolutely necessary but I still use it just in case. The reason it might not be necessary is that I will now cut out a small portion of the image and create a repeating pattern to make it into a usable texture.  I then remove the spaces between the grid loops and add a green background color just to give you the idea.

This particular texture is supposed to be the mesh of a fence. So I will have to shrink it a bit horizontally to make the holes in the mesh uniform. After this I simply use the Filter > Offset function to make the texture seamless. This tutorial describes the basics of the technique but it’s really up to you to fix the details depending on the complexity of the image. I used a combination of the Brush Healing tool and the eraser which fixed this texture up nicely.

Here’s the final texture map.

And here is the texture applied on a 3D fence in Autodesk Maya.

Again, it’s not always the same for every texture. This particular one was very easy to create. You always find some wrinkles to iron out in ways you have to invent in the moment., but I hope this post provided some insight on how we create some of our textures.

– Kim

A visit from the teachers


Last friday our teachers swung by to pay us a visit and check up on our project. Actually, we invited them. We had prepared a demo of the project in it’s current state and thought it was time to show off our work. Of course, the game in it’s current state is a pre-alpha and not very heavy on the graphics side. The main point was to demo the group behaviour of the rioters and how two groups interact when crossing eachother’s path, layed out on a very simple map.

We got the feeling we made a good impression. Our programming teacher, Stefan, was mainly concerned with the delay time of the potential fields of rioters in the game. The potential fields are like invisible magnetic fields that makes rioters cling together in a group or move away from police units and other threats. These are updated in realtime with a delay of 14ms as of now. This is an optimization issue that we will deal with in time.

We also received a bunch of questions and suggestions from our project managing teacher, Torbjörn. As always he was very interested in and inquisitive about our organisation within the group. He raised the important issue that we should focus on locking down ideas and implementations as soon as we’re able to, and linger as little as possible on multiple choices of technical baselines (for example: choosing between two types of animation techniques).

We have quite a lot of zones containing ideas and work tasks for the game – our wiki, scrum board, idea board, user stories, agreements contained within specific group responsibilities and individual visions of the game. Even though we already have a rather tight work flow, Torbjörn wanted us to streamline it further and narrow everything down. It’s quite refreshing to get input like that and I think he pushed us in the right direction.

We received the question of how we’re going to make the rioters look varied and unique, which is always an issue in games containing large groups of individuals. We don’t want rioters looking like clones. Our solution for this is to have a base set of different human models, textures and accessories (for rioters to wear or hold on to), which we will tint with various colors to create variation in their visuals.

In general the teachers seemed to be happy with our progress, and we’re happy too. We’re on track and organized. Basic gameplay interaction is due for implementation in the weeks to come on the programming side, and on the art side we’re going to start creating content such as level design, level concept art, 3D models of entities in the game and mocapping. We’ve come far, but there’s still a long way to go.

– Kim (Technical Artist)

Agile development

There was never a choice whether to exercise agile methods for our project as it is dictated by the course the game is being developed for. Having that said, we probably would have used it given the choice. Agile development is a good fit for many projects and especially for game projects, in my opinion. The core idea is adaptation: the project is developed using iterations where the path towards a finished product can change direction as new requirements and requests are being catered to. This is well suited for game development as it allows us to easily add features, adapt to results from playtesting and quickly change goal if the game idea needs to be altered.

Our method

The process is mainly Scrum. First we create user stories for our project. A user story is typically written from the perspective of a player or developer, or another role significant for the project. It is a feature or technique that a person in that role would want to see in the game. We have divided our project into the smaller parts called sprints and decided on each sprint spanning two weeks. Each sprint has a goal with associated user stories and should work towards the very rough monthly milestones we have set up for the project to make sure we make enough progress to reach our final goal. This goal is decided upon during the sprint planning meeting at the beginning of a sprint. Then, the sprint’s goal is further broken up into smaller tasks (called Product Backlog Items or PBIs) which are estimated and put on our Scrum board for everybody to see. Our team has a velocity, which states how much work we can do each sprint and the total estimations for the tasks should not exceed this velocity.

To find out the velocity, we start by figuring out the unit for the velocity. Scrum suggests this is done by choosing a very basic task, giving that task an estimation (usually one unit) and then compare all future units to this one. That is, a task that takes twice as long as the basic task with an estimation of one unit takes two units – you get the drift. Then, we estimate how many basic tasks we could do as a group in the allotted time and that is the team’s velocity. As this is all very approximative, more so the less experience you have working with this method or working as a group, the velocity needs to be adjusted after a sprint. A good time to do this is during the retrospective, a more realistic value can be chosen as part of the evaluation. More on the retrospective below.

We also have the daily Scrum: a timeboxed, 15-minute meeting at the start of every work day where each team member accounts for what task(s) they worked on the previous day, what they are going to continue work on and what possible problems he or she may encounter during the day. This is a very good way of making sure all team members have an appreciation of what everyone else is doing and what state the project is. It also helps discovering and solving problems quicker. At the end of each sprint we have a retrospective meeting, as the Scrum process suggests, where we evaluate the sprint: what has worked well and should be continued, what did not work and should be changed and what new approaches do we want to try.

Lastly, we have an appointed Scrum master that for learning purposes is cycling through the team members interested in the assignment. Currently, I am the Scrum master and as such, my duties include facilitating meetings and solving problems that may slow team members down.

If we find bugs, these are put on the Scrum board immediately and discussed during the next daily Scrum to determine whether they are pressing and need to be resolved promptly, or if they can wait to the next sprint, as well as who takes care of it. This is in line with the Scrum policy that tasks are not finished until they are complete and bug free (as far as is possible to determine).

Apart from what we take with us from these agile processes, we also have an idea board for adding any ideas whenever you think of them. These ideas are then considered at the sprint planning meeting and either discarded, left for the future by going back on the board or incorporated into the process in the form of a user story, PBI or addition to the Game Design Document (GDD).


We have had occasions where some team members have been stuck waiting for other team members to finish their tasks. This has left us less productive than we could have been although not inherently the fault of Scrum – some dependencies are inevitable, especially at the beginning of a project and some are due to our inexperience in planning and such problems will be avoided as we get better at planning.


Several advantages have been mentioned above and include the easy addition and removal of features, incorporate changes based on playtesting, all team members being up to speed with what everybody else is doing and the use of an iterative process. If we come up with new ideas we would really love to see in the game, they are easy to add and conversely – if we find that time is running out on us we get the chance to cut features. Same goes for the result of playtesting.

That all team members know what everybody else is doing is very important and minimises misunderstandings, double work and error resolving. The Daily Scrum also propel communication within the group as an extra bonus for a newly founded group.

The iterative process allows us to change the direction of our project if necessary, scrap features and techniques that do not work in the desired way and even rollback entire sprints. Thanks to the retrospective meetings at the end of a sprint, we continuously improve the work process to make it more effective and less error prone.

Further Reading

If you are interested in the Scrum process and want to know more, I recommend the book Agile Game Development with Scrum by Clinton Keith (ISBN: 978-0-321-61852-8)

Edit: Removed an erroneous description of our method where Kanban was mentioned.

Written by Kim Restad