Author Archive
Oken: The story of a canceled indie game project.
Posted by Daniel Rodríguez in Projects on February 28th, 2010
Last year I had the pleasure of working on Oken, a game that was supposed to released this January. It is a classic sidescroller with a couple of interesting game mechanics that got canceled. A canceled indie game project, here is the story:
Lune and I decided that we needed to create games ASAP, indie games. We knew that we weren’t going to create the next GTA, but we wanted to create, to be able to show something we have done, something to be proud of. We started Oken out of an old idea back in my days at 3dmx. We had a project there called PreyInsight (please look here, all the art is Lune’s), we always liked the idea of creating a game of a tiger, so we redesigned the idea from scratch, created our main character and decided to create a game. We invited 3 of our students to join the team, Carlos for the art department (guided by Lune); Alan and Adrian for programming (guided by me) and the Dorian, our sound designer/composer.
The Oken team:
- Lune (http://lunecheetah.deviantart.com/)
- Alan Gaspar
- Adrian Gil
- Carlos Junior Ramirez
- Dorian Mastin (http://www.dorianmastin.com/)
- Daniel Rodríguez ( that’s me! )
We also had the help of Netic (Ernesto Ruiz Velasco, http://netic-ck.deviantart.com/) who created some 3d assets for the game. Great job!
All the assets I am sharing here were already shared on the Facebook page for the project. You cannot imagine the amount of artwork created by Lune and Carlos for this game (enemy concepts, 3d models, millions of textures, even powerpoint presentations), but I think it’s their choice if they want to publish them (and where). Of course this space will always be open for them.
Dorian created awesome music for this game too! Please listen to the Oken Menu Theme. He also created ambient sounds for the first level, among other great sound assets.
The game was being developed using the Unity3d game engine, a great software for game development. We decided to use it because it was cheap (now it’s free) and because we knew it very well. We created great code too, including a character state manager system and a camera interpolation system (yes, we will be sharing the code with the world very soon).
So, the interesting question is: Why is Oken canceled?
It is difficult to answer.
I’ve been thinking of this for a very long time now. I can only think of one think that wen’t wrong: Our people skills. Lune and I were trying to get things done, we wanted to create a great game. Nonetheless, I believe we were unable to provide all the support the team needed as we were full time workers and Oken was only a hobby project. The team slowly loosed it’s energy, it’s will, and it’s professional perspective. We let personal stuff get in the way and at the end, it was impossible for us to work on this game. We decided that our friendship was more important, so we paused the project. A couple of months later I wanted to start developing again, but the the team was way to busy on other stuff (great stuff, like the short film Junior is preparing).
This teach me a lot.
I now want to share how the game looked like in it’s final stage. We made 2 builds, the first one is a test level designed to test and tune Oken’s movements, the second it’s our first level (on a early stage, it needed a lot of tunning).
(Move with arrows, attack with “z” (early combat implementation))
Please note that the game was never optimized for the web and that it really is in a very early stage. Still, you can see that the movement of the character works great. Oken was supposed to have combos and the game mechanics included an “aura system”.
All of our work behind the game can be seen on the public Assembla site for Oken. As you can see, we created a lot of documentation for the game (we were going for the real thing!). The wiki contains detailed information about the game mechanics and there are some visual assets there too!
It is very sad that Oken didn’t really worked out as we expected, but, the story won’t end there. Every single member of the Oken team is working on new great stuff. While Lune has a lot of projects (too many to list them here), Carlos is working on that short film, Adrian and Alan are working on the adaptation of their game Amnesia to the Unity engine, I am working on another game for the web with a couple of friends (new team). The game is gonna be announced on this blog very soon.
I hope the story of this project is useful to someone else. We need to always remember that the technical issues of a project can always be solved, but what really destroys projects is the lack of communication and time. The people needs to feel great working on the project, they must be motivated, and it’s everybody’s job to keep it that way. Never forget about the people you are working with.
Introduction to Game Development tips by Walter Rotenberry
Posted by Daniel Rodríguez in Game development on February 15th, 2010
Last month Walter Rottenberry came to Guadalajara to teach us about the very basics of game development. As usual, let me share my notes:
AI:
- Tips from Steve Rabin in “Game Programming Gems 2″
- Use event driven behavior rather than polling
- Reduce redundant calculations
- Centralize cooperation with managers
- Run the AI less often
- Distribute the processing over several frames
- Employ AI LODs
- Solve only part of the problem
- Do the hard work offline
- Use emergent behavior to avoid scripting
- Amortize costs with continuous bookkeeping
- Rethink the problem
Game Theory:
- Prisoner dilemma
- Types of challenges
- Implicit vs explicit
- Perfect vs imperfect information
- Intrinsic vs extrinsic knowledge
- Pattern recognition
Level design:
Level designer responsibilities:
- Create terrain
- Create the rooms
- Add props
- Add triggers
- Look great
- Make it work
Technical limitations:
- The platform
- Affects how the level should be built (not the level itself)
Main factors:
- Memory
- Processing power and frame rate
- Level performance
- Polycount
- Lighting
- AI
- Media format
- Target and minimum specifications
GPUs take care of the eye candy in the game
Special effects consume a lot of processing power instead of RAM
Performance:
- Fast moving games require faster frame rate
- Level designer should be aware of strain on GPU and not frustrate for that
Polycount:
- What really matters is the number of polygons seen on the screen at any given moment
- Contributors
- Too many characters in a single space
- Special effects (smoke, falling leaves, fire, a black hole, etc)
- Emmitters need to be watched closely
- Use LODs (Level of detail)
- Characters: 3 LODs
- Objects: 2-3 LODs
- Environments: distances vary depending on level and game
Lighting:
- Lights and shadows both pulls on the GPU
- Dynamic lights are cool but expensive
- Traditionally had static lights
- Lights and shadows can be baked into textures
Game metrics:
- Happens after the player metrics are known
- Properties of the main character are the biggest factor
- Examples:
- Height and width
- Walk and run speed
- Jump distance
- Jump height
- Interaction distance (how far the player needs to be from an interactuable object to interact with it)
- Character metrics
- The visual size is different from the collision size
- Use collision volumes
- Make doors and corridors slightly bigger than realistic proportions
- Warning: Beware the game designer who gives you a ballpark figure for vital game data
- Get hard data before creating the level
- Level designer should decide the movement speed and jump metrics
Tips:
- FaceFX for facial animation
- Use cell diagrams (also called bubble diagrams) for gameplay
Thank you Walter. This was very useful.
TransformUtilities
Posted by Daniel Rodríguez in Game development, Programming on February 6th, 2010
This is how the tool looks like
Hello. I’ve been working on a set of four tools to aid in the Unity3d development. After using Unity for a while I encountered the classic problem of needing to copy the position of an object over and over. This led me to create the “Copy” tool. I’ve found a similar script on the Unify community, but I wanted to extend the tool. It is now possible to copy position, rotation and scale of any axis you want. Also, the values apply to all objects selected in the scene.
After that, and inspired by the tools I found on the Gamebryo Lightspeed editor, I created the Randomize and Add Noise tools. Those tools work almost the same, the randomize the position, rotation of scale of any object selected (or all objects selected). The difference is that while Randomize sets the absolute values for position, rotation or scale, Add noise adds a delta to the current value of the transform. This is useful for example to randomize the Y rotation of all the trees in your level, or to make a bunch of boxes look more natural by not being perfectly aligned.
Finally, after been learning Autodesk 3ds Max, I created the Align tool inspired by a tool in that software. It basically takes a source transform, just like the Copy tool, then uses it’s collider and the collider of the object (or objects) selected to align it. You can align for example, the minimum point of your selection with the maximum point of your source (what you are aligning to) to place an object over another. It let’s you align using the minimum point, maximum point, the center of the object or the pivot point on both the selection and the source. You can align on all 3 axis.
To use these tool, all you need to do is download the script file, and add it into a folder named Editor in your project’s Asset folder. Once compiled by Unity you find the new functionality in Window -> TransformUtilities, or simply press Ctrl+t (Cmd+t for Mac users)
Developed by Daniel Rodríguez (Seth Illgard) in January 2010
Hope you find them useful, and please let me know how can I improve theses tools.
Coroutines in Unity3d (C# version)
Posted by Daniel Rodríguez in Programming on January 23rd, 2010
Coroutines in C# work the same way that they do in Javascript (UnityScript), the only difference is that they require more typing (they have a slightly more complicated syntax). You should see the blog post on Javascript coroutines first.
Here, I present the differences:
Coroutines must have the IEnumerator return type:
IEnumerator MyCoroutine()
{
//This is a coroutine
}
To invoke a coroutine you must do it using the StartCoroutine method:
public class MyScript : MonoBehaviour
{
void Start()
{
StartCoroutine(MyCoroutine());
}
IEnumerator MyCoroutine()
{
//This is a coroutine
}
}
The yield statement becomes yield return in C# :
IEnumerator MyCoroutine()
{
DoSomething();
yield return 0; //Wait one frame, the 0 here is only because we need to return an IEnumerable
DoSomethingElse();
}
Remember that we need to return an IEnumerable, so the Javascript yield; becomes yield return 0; in C#
Also, since C# requires you to use the new operator to create objects, if you want to use WaitForSeconds you have to use it like this:
IEnumerator MyCoroutine()
{
DoSomething();
yield return new WaitForSeconds(2.0f); //Wait 2 seconds
DoSomethingElse();
}
Happy coroutining 
Coroutines in Unity3d (Javascript version)
Posted by Daniel Rodríguez in Programming on January 22nd, 2010
I’ve been working with Unity3d for some time now and I couldn’t really make good use of the coroutines because I was unable to truly understand them. After some time playing with them and making some experiments I realized their true power. I couldn’t believe what I was missing! So, a couple of fellow game devs asked me to explain the concept to them. I decided that a blog post was the perfect way to do it and, at the same time, share this with everyone.
Coroutines: Special type of functions(in the programming sense) that allows to stop it’s own execution until certain condition is met.
A coroutine looks like this (on javascript, the C# version is here):
function MyCoroutine()
{
DoSomething():
yield; //Mystery here
DoSomethingElse();
}
When you invoke this function (start the coroutine) it will behave just like any other normal function you have ever seen, until it reaches the yield instruction. The yield instruction explained: The yield instruction works like a return statement in the sense that it stops the execution of the function and returns control to the code that invoked that function. The main difference is that the yield instruction lets you delay the execution of the code that is after it (in the last example, the DoSomethingElse() statement).
function MyCoroutine()
{
DoSomething(): //Do this immediately
yield; //Return control to the caller
DoSomethingElse(); //This will be executed one frame later
}
void Start()
{
MyCoroutine();
}
What happens if you have more code after the MyCoroutine call? Let’s see an example with some prints:
function MyCoroutine()
{
print("This is printed second");
yield; //Return control to the Start function
print("This is printed one fourth, exactly one frame after the third");
}
void Start()
{
print("This is printed first");
MyCoroutine();
print("This is printed third");
}
You can control when do the code after the yield instruction will be executed. It depends on the parameter of the yield instruction, according to the following table
Nothing: It will wait one frame
Another coroutine invocation: It will wait until the invoked coroutine finishes execution
A WaitForSeconds object: It will wait certain amount of time
Confused? Here are the examples:
function MyCoroutine()
{
DoSomething(): //Do this immediately
yield WaitForSeconds(2); //Return control to the caller
DoSomethingElse(); //This will be executed 2 seconds after
}
void Start()
{
MyCoroutine();
}
function MyCoroutine()
{
DoSomething(): //Do this immediately
yield MyOtherCoroutine(); //Go and execute MyOtherCoroutine!
DoSomethingElse(); //This will be executed after MyOtherCoroutine finished execution
}
function MyOtherCoroutine()
{
DoStuff(): //Do this immediately
yield WaitForSeconds(2); //Return control to the caller (in this case the Start function)
DoMoreStuff(); //This will be executed 2 seconds after
//MyOtherCoroutine finishes execution here
}
void Start()
{
MyCoroutine();
}
As you can see, coroutines are very powerful and easy to use once you understand how they work. I will post some usage examples and the C# version of the scripts on this post soon.
Game development facts and tips
Posted by Daniel Rodríguez in Game development on November 19th, 2009
Last month I had the pleasure of finding a new friend in the gamedev community: Ian Masters, a senior game programmer at Sidhe Interactive, creators of the Speed Racer game for Nintendo Wii and Sony PlayStation 2.
While he was in town I managed to compile a list of game development facts and tips. Here they are:
Programming:
- Everybody creates their own internal technology to build games. They modify engines and create frameworks for internal use.
- The technical director is the responsable of selecting technology like the game engine.
- Developing a game engine from scratch could take years and it’s not recommended.
- The most used languages in game development are : C++, Lua and Python.
- It’s common to have a prototyping team.
- Use source control (SVN, mercurial, etc.)
- Have all your projects into a solution, prefer that to link against static libraries (including third party code).
- Have your engine’s source code in your source control system so you can modify it and the changes will propagate.
QA:
- Unit testing is very important (specially for math libraries and core functions).
- Regression testing is important too.
- QA team is different from playtesting. QA test QA, playtesters test fun.
- No QA guys in multidisciplinary teams.
Art:
- Conceptual art should be delivered as soon as possible before programming start (at least a month ahead).
- Work on iterations.
- Artists hate naming conventions.
- It’s not easy to convince the artists to follow naming conventions (normally you need a producer to talk to them).
- Having a lead artist who follows naming conventions is crucial.
- Try to integrate audio as soon as possible. Audio is not a luxury.
- Post effects are often decided between the post effects coder and the art director.
- Camera effects are often decided between the camera scripters and the designers.
- Have metrics with the export tools (poly counts, texture sizes, bone count, etc)
- Should present a visual target.
Design:
- They can’t account for everything.
- Design document should be as detailed as possible.
- Design document should be a live document.
- They define tunable properties.
- Normally use XML files for tunable properties (exported from spreadsheets for extra awesomeness).
- There are co-designers (scripters).
Production:
- Producer’s work is to assure work is being done and cycles are running smoothly.
- Wikis are awesome.
- You can manage a whole project documentation using exclusively a wiki.
- Procedures, knowledge and project management all fit into a wiki.
- Multidisciplinary teams are a great way to work.
- Have a list of features that need to be tested on the prototype.
Recommendations:
- Scrum is the way to go.
- Use Scrum properly.
- Scrum meetings in the mornings.
- Put scrum plans on the wiki.
- Create tickets on Trac or a similar tool.
- Keep things visible and transparent.
- Read a lot. Be proactive and an active learner and problem solver.
- Try to work as close as possible with artists, programmers and designers.
- You need a published title to get into the industry. To get that title you need to be in the industry. Indie titles are a good way to break into it.
- Prototype as soon as possible.
Hope that helps, and a big “Thank you” to Ian for his time with us. I learned a lot.
Introduction to Game Development and Unity3d
Posted by Daniel Rodríguez in Game development on November 19th, 2009
Today I was invited to the UVM University to give a workshop on game development using Unity3d. For that purpose I created a small presentation that you can find in pdf format here: Introduction to game development and Unity3d.
It is a very basic introduction, but I hope you like it.
Game design with Noah Falstein, part 4: Brainstorming and extra tips
Posted by Daniel Rodríguez in Game development on October 10th, 2009
Meta-observation:
- The best way to learn is by playing many games and learning from other designers
- Game designers must also learn to observe themselves on many levels as they play
- Some levels in playing/designing games: Mechanics, strategies, cheat/exploit, game design rules… but there are other ways to see it
Basic brainstorming:
- Be aware of, but not shackled by constrains
- Listen to what others say
- Challenge assumptions – your own and others
- Vary discussion of theme/story and gameplay mechanics (Important!)
- Try to cross-fertilize ideas even (specially) when it seems absurd
- You are finding new neural pathways
- Mixing wildly different ideas or themes can create useful tension
- Example: Art deco + bio-tech + Ayn Rand + 1960 + underwater = Bioshock
- Ideas, not egos: Critique concepts, not people
- Review constraints and question them too
- Good, not escential, to have a reason why
- Nothing is to odd or silly – low hit ratio
- It’s normal to wander – some!
- Best size around 5 +- 2
- Common ground, divergent opinions
- Avoid including managment directly (fear of firing, danger of deferring to boss)
- Consider flied trips, resources, toys
- Time pressure (optional)
- No judgments (optional, useful for dealing with people that has never done brainstorming)
- More than art as you gain experience
Great game elements (advanced techniques):
- Classic convexity structure (Start wth one node, then many, then one again)
- Appropiate inteface
- Negative feedback (Handicap)
- Self-tunning features
- Emergent complexity (Overlap various game mechanics)
- Great balance (tradeoffs again!)
Negative feedback examples:
- Exponential costs (experience, money, etc)
- Easier to aim after each failure or death
- Selling items give you less money that what you originally paid for it
- Stronger units are more restictive (specialized, only good against another specific unit, etc)
Game design with Noah Falstein, part 3: Natural funativity theory
Posted by Daniel Rodríguez in Game development on October 4th, 2009
Natural Funativity Theory:
Natural funativity theory is Noah’s own work. You can find the original gamasutra article here. What I present here are only my notes on the subject, my personal interpretation of the theory. Hope you find it useful.
What is fun?
- Dictionary: Enjoyment, a souce of amusement (that does not help)
- Consider underlying reasons
- “Funativity”: Thinking about fun in terms of a measurable cause and effect
- Inevitably this leads to “Why do we commonly share the experience of fun?”
Evolutanary roots:
- We must look to our distant past
- Young mamals play to learn basic survival skills
- Games are organized play
- Human entrataiment is more complicated
Entretaiment is Learning:
- Life is either work, rest or entretaiment
- Perhaps at first it was all work or rest
- Play (and fun) may be neotenal traits
- Fun is about practicing or learning new survival skillin a relatively safe setting
- People who didn’t experience were less likely to survive to become our ancestors
Natural Funativity Theory:
- Basic concept is that all fun derives from practicing survival and social skills
- Partly learning new skills, partly mastering and mantaining familiar ones
- Key skills relate to stone-age human life, but often in modern context
- Three cathegories: Physical, Social, Mental
Physical fun:
- Sports generally enhance our strength, stamina, coordination skills
- Exploration is fun, both of local area and knowledge of exotic places
- Physical aspect to gathering “stuff”
- Hand/eye coordination and tool use are often parts of fun activities, crafts
Social fun:
- Storytelling is a social activity, a way to lean important survival and social lessons from others, our first VR
- Gossip, bonding with friends aids survival
- Flirting, showing off, finding mates is a key component in social fun
- Language has become paramount
Mental fun:
- Pure abstract reasoning practice is fun
- Pattern matching and generaion
- Music, art, puzzles, all pattern based, both perception and creation
- Gathering has also a mental aspect: categorizing and identifyng patterns
Multipurpose fun:
- Many fun activities have physical, social and mental aspects in combination
- Games that mix these aspects tend to be very popular (e.g. Blizzard games)
- Incorporate ways to practice these skills to increase popularity of games
Noah also mentioned that Diablo 2 was a great in combining the 3 types of fun. You have great physical (hack and slash mechanics, click click click), great mental (inventory, item management, etc) and of course, great social fun (multiplayer is great!).
Seth out.
Game design with Noah Falstein, part 2: Fundamentals
Posted by Daniel Rodríguez in Game development on October 3rd, 2009
Ok, continuing with my notes on game design, here you have the fundamentals that Noah Falstein teach us:
Identify your constrains:
- Creative: expectations and goals
- Technical (including platform)
- Bussiness, marketing, sales, distribution
- People: skills and personalities
- Internal politics
- Serious games – add teaching/training and real world content constraints
Game design fundamentals:
- Creative plagiarization: Take only what is appropiate, make it your own
- Sid Meier’s rule: Fun for the player, not for computer or designer
- Albert Einstein: Make it as simple as possible, and no simpler
- Make it familiar, yet new
- Easy to learn, hard to master
- Easy, clean, deep
- Emphasize exploration and discovery
- Have a clear short, medium and long term goals
- Natural funativity: hunting and gathering
A great game:
- A series of interactive choises in the persuit of a series of well stablished and compelling goals
- Must be a series of choises or it’s too simple to be a game
- Must have a goal or it’s a software toy
- With Sim City and The Sims players may bring heir own goals
- Choises need to be meaningful
- If choises are dull could be that:
- Easy to code that way
- Lazy designer
- Meaningful choises are perceived by the player as having significant consequences
- May not have actual consequences
Goals:
- Clear goals: it’s not fun to flounder aimlessly
- Avoid “the protagonist with amnesia” cliché
- Compelling goals are goals that follow the concepts in natural funativity
- Surival is always a compellin goal
Flow:
- Combine intense learning with practical gameplay
- Start with a relatively low stress level
- Combine rapid difficulty increase with slower increase. That maximizes fun.
- High difficulty increase: Boss battles, climatic battles, quest resolutions
- Low difficulty increase: Bonus levels, new resource ad tresure-rich areas, series of easy minion enemies
- Overlap introduction of new skills, areas to explore, tools, enemies