Animation People


Animation in Nigeria is not a scarce commodity but 3D animation is still scarce locally. There are not so many 3D animators within the Nigerian space doing good justice to the art. As is our tradition on Techpoint we are featuring some amazing 3D animators working out of Nigeria telling the African stories with 3D software applications. To us they are achievers inspiring the next generation.

Eri Umusu

Eri currently works at Afrinolly as a CG Artist. Eri has been engaged in different tasks from VFX productions to animated content, motion graphics and so on. Eri is undoubtedly one of Nigeria’s best when it comes to 3D modelling, animation and visual effects.


A self taught artist, he had his directorial debut with “The Sim” (in the video clip below), currently one of the most popular 3D animation in Nigeria. He is an active contributor within the Nigerian 3D community, giving trainings and lectures on computer animation. Eri hopes to be a Japanese samurai one day.

Uche Anisiuba

Uche is a Mass Communication graduate of Anambra State University with a Marketing communication Major. His journey into 3D animation started in 2011 while in school, with a dream of becoming the best 3D animator in Nigeria. Starting out with Adobe Photoshop, Uche also learnt Adobe After Effects and Adobe Illustrator as a basis for learning 3D.


His 3D journey started just after NYSC as he was recruited by Orange Vfx Studios after taking one of their crash courses. After working at Orange Vfx for about a year and half he decided to get into a bit of game developement and was recruited by Gamsole where he worked for about six months. Thirsty for knowledge Anisiuba Uche has also taken courses atIanimate and is currently a co-founder at Quadron Studios.

 Tayo Fasunon

Tayo started his art drawing Teenage Mutant Ninja Turtles comics on the back sheet of his math exercise book. Ironically, he went on to study mathematics at Obafemi Awolowo University, after which he caught again the call of the wild and resumed his dream to tell globally relevant stories from a Nigerian perspective.


Today, he draws inspiration from influences as diverse as Wole Soyinka and John Lasseter, as he continues on the journey to find and refine his artistic voice. He collaborated on the hilarious viral video “Gbedu!” also known as “Ovie and Wale” to prove that Africa is the next big thing in un-mined stories. He’s convinced that Africa must take control of its own narrative, and that fantasy is the best way to do it. Together with Uche Anisiuba and Tochukwu Nwankwere, he recently co-founded Quadron Studios, and now they’re set to do just that.

 Richard Oboh

Richard is the Creative Director at OrangeVFX Studios and currently studying business administration and management at University of South Wales. He studied Chemical Engineering from the University of Port harcourt and hails from Edo State, Nigeria.


Richard has worked on 3D animated television commercials and short story “Ovie and Wale” (in the video clip below) which went viral both online and offline. Richard has created marketing campaigns for a number of companies designing and producing animated TV commercials, eye-catching signature cartoon characters for product marketing design. Richard designed and animated the defensive driving training video for the Lagos State Driving Institute and Oando Plc. He is the lead trainer at Orange VFX Studios and has overseen numerous professional trainings on using Autodesk Maya, After Effects and Premiere Pro for design and creation of 3D animation videos and images.

What do you think of these guys? Do you know any other awesome Nigerian 3D animators? Let us know in the comment

Top Tips 0n Planning a programming project

Becoming a programmer isn’t just about learning the syntax and the concepts of a programming language: it’s about figuring out how to use that knowledge to make programs. You’ve made a bunch of programs in this course, in the challenges and projects, but now you should come up with ideas for new programs – ideas that you’re personally really excited about – and try to turn those into actual programs.

You probably won’t know everything you need for your program when you start it, and that’s totally okay — you’ll be motivated to learn those new things because of how much you want to make your program real. Programmers are constantly learning new things for new projects, and that’s part of why we love it so much.

Let’s step through the process of planning a programming project:

1. What do you want to make?

When I first started programming, I found myself constantly thinking of new programs to make and writing those down in a list. I was addicted to the power of creation, and there was so much my brain wanted to make. If you’re like that, then you probably already have an idea of what you want to make, and perhaps you have your own list.

If you don’t already have an idea, then here are some questions to help your brainstorming:

  • What’s your favorite game – arcade game, board game, sports game? Could you make a simplified, digital version of that? Could you mix it up a bit, like give it a different theme or main characters?
  • What are your other favorite academic fields? If you love art, could you make an art-making program? If you love history, how about an interactive timeline? If you love science, how about a scientific simulation?
  • What’s your favorite movie or TV show? Could you make a digital version of a scene or character from it? Maybe make a game based on it?
  • What’s a real-life gadget that you love? Could you make a simulation of it?

Once you’ve picked an idea, you should write a description of it. For example, if I decided to make a clone of “Breakout”, because that’s my favorite retro arcade game, I might write:

Breakout: a game where you control a paddle at the bottom of the screen, and you use it to hit a ball upwards and at angles to break bricks. The goal is to break all the bricks, and not let the ball through the ground too many times.

You’ll flesh that description out later, but for now, that gives you a good enough idea to keep going in the planning process.

2. What technology will you use?

In this step, you need to consider which technologies (languages/libraries/environments) you’re familiar with or able to learn easily, and which of them are the most well suited for the job. For many of you, that list may be one item long, “1. JS+ProcessingJS”, and that makes your decision easy.

The environment doesn’t work for other things like multi-player games, mobile apps, data-crunching applications. If you know other languages/environments (like JS+HTML, Python, SCRATCH, Swift, etc) and you’re thinking of building something that doesn’t make as much sense with ProcessingJS, then consider which of those technologies would be best suited for your program. If you want to build those things but don’t know other technologies, you might want to come up with a new program idea. You can learn a new technology for a new project, but especially if you’re just getting started in programming, it’s a good idea to get really good at your first language first.

If I decided to make a game like Breakout, I’d pick JS+ProcessingJS, since I already know that technology and it also works great for 2D games like that.

3. What features will it include?

This is where we get into the real planning, and where (I think) it gets fun. Your goal in this step is to figure out what you’re actually making- what will it look like, what features it will include, what features it *won’t* include.

The first thing you can do is make “mock-ups”  – sketches that look like the thing you’re making, but without details like coloring or exact sizing. You can make mock-ups on paper, or with online programs:

To give you an idea of what mock-ups look like, I’ve included mock-ups below of my Breakout clone. I sketched each scene separately and drew arrows between them to show how one scene leads to another. Those arrows will help me understand what logic I need in my program to go between program states.

Sketched mock-ups of a Breakout clone

Now you can use those mock-ups to help you make a feature list, where you think of every feature in your program, and make it into a list.

For my Breakout clone, this could be my feature list, broken down by scene:

Game scene
  • User-controlled paddle
  • Multiple colored bricks
  • Angled ball movement
  • Collision detection
  • Life display
  • Score display
  • Sound effects
Main Scene
  • Play button
  • Help button
Help Scene
  • Text
  • Back button
Win Scene
  • Headline
  • Fireworks animation
Lose Scene
  • Text
  • Restart button

4. But what features must it include?

If we all had infinite time to make all the programs in our heads, then they’d all include every feature in our list. But we don’t, so in this step, you have to decide which features are the most important, and which features you’ll do only if we have time. This will also help you figure out which order to implement features in, from most to least important.

To help you figure out the importance of each feature, ask yourself these questions:

  • If I shared this with a friend, which features would I want to make sure were working?
  • Which features am I the most excited about building?
  • Which features are the most unique to my program?
  • Which features will I learn the most from implementing?
  • Are there any features that seem too far beyond my current skill level?

Then, go through your feature list from the last step, and either order the list or add a rank to each feature.

For my Breakout clone feature list, I’ve put “P1”, “P2”, and “P3” next to the features, signifying top priority (P1), middle priority (P2), and lowest priority (P3). I decided to prioritize the unique game mechanics over general game features like scenes, because I find that the most exciting about this project:

Game scene
  • (P1) User-controlled paddle
  • (P1) Multiple colored bricks
  • (P1) Angled ball movement
  • (P1) Collision detection
  • (P2) Life display
  • (P2) Score display
  • (P3) Sound effects
Main Scene
  • (P2) Play button
  • (P3) Help button
Help Scene
  • (P3) Text
  • (P3) Back button
Win Scene
  • (P2) Headline
  • (P3) Fireworks animation
Lose Scene
  • (P2) Text
  • (P3) Restart button

As a general tip for those of you making games, here are features that I’d recommend de-prioritizing: menus, multiple levels, 3D graphics. Focus on what’s unique and fun about your game, then add those extras.

You can also turn your prioritized list into project versions, so you can easily see what you need to implement in each versions, and you can always stop after a particular version and be happy with what you’ve made.

Here’s what the versions would look like for my Breakout clone:

  • User-controlled paddle
  • Multiple colored bricks
  • Angled ball movement
  • Collision detection
  • Life display
  • Score display
  • Start scene w/play button
  • Win scene w/headline
  • Sound effects
  • Help button
  • Fireworks
  • Lose scene w/Restart button

5. How will you implement it?

You now have an idea of what features you’ll be building first in your program – but if you start now, you’ll be staring at a completely blank program with no code written, and that can be intimidating. Which variables should you write first? Which functions?

One way you can figure that out is to think about the “high level architecture” of your program – breaking it into categories like “objects”, “logic”, “user interaction”, “user data”, and “scenes” – and then think about how you might implement them, like as object-oriented object types, functions, or variables.

For example, here’s an architecture for my Breakout clone:

  • Brick (.isHit())
  • Paddle (.move())
  • Ball (.move())
  • Start
  • Game
  • End
  • Ball-brick collision (function, use bounding box)
  • Paddle-ball angling (function, invert angle)
User interaction
  • Keyboard-paddle movement (keyPressed)
  • Buttons for scene changes (mouseClicked)
User data
  • Ball deaths (array)
  • Ball hits (array)

Once you’ve thought about the high-level architecture, it should become more clear what you can start coding first.

You might decide to write your whole program in pseudo-code first, which we talk about later in this tutorial. Basically, it’d mean writing the whole program in plain English text inside a comment, and then slowly turning that into actual code.

6. What’s your timeline?

How much time do you have to make this program? How many weeks, and how much time each day? What features will you write each week? Your goal in this step is to figure out a timeline for your project – which is particularly important if you have a deadline, but also useful so you start to understand how much time it takes you to write a program.

Here’s a timeline for my Breakout clone, assuming 2-4 hours of work each week:

  • Week 1: Design and pseudo-code
  • Week 2: Rough visuals
  • Week 3: Ball moving/collision mechanics
  • Week 4: Scoring mechanics
  • Week 5: Scenes (Start/Win/Lose)
  • Week 6: Polish, Manual tests (QA), Prep for demo

Figuring out timelines for programming projects is hard. Some things that seem easy take way longer than you expect (like some weird bug that you spend hours debugging), some things that seem hard take  less time than you expect. As a general rule, assume it will take you longer than you think, and adjust as you go along.


Thanks to khanacademy.org

Tips for Indie Game Developers

1. Do not fall for survivorship bias.

For those who may not know, survivorship bias is the tendency to consider only successful cases when analyzing market data, behavior, etc. It even influences warfare.

How does that apply to game development then? Well, when I started, I remember being really optimistic and enthusiastic about building an iPhone game. I was reading article after article of developers that were making good money out of the App Store and I thought maybe I could get some bucks myself. I didn’t stop to think things through and it did not go well.

“Resistance outwits the amateur with the oldest trick in the book: it uses his own enthusiasm against him.” – Steven Pressfield, The War of Art

Take your time. Think of the obstacles ahead. Talk to people and ask for advice. Analyze every option. Then take some more time. Only after that make a choice and never look back.

To know more about survivorship bias I strongly recommend reading this.

2. Do not start with a complex idea.

I see a lot of guys that want to start out doing things like an FPS. They seriously want to start doing that. They have only the basic skills, but that’s what they want to do.

When these guys sit down to actually do the job, they are easily defeated. That’s because they don’t realize the amount of energy you need to put into a project and they have even less idea of their own professional capabilities.

I am not saying your first game cannot be an FPS, but you have to consider all the things ahead. If you choose an FPS, it will take really long before it is finished and it will be on the market alongside Call of Duty. Isn’t it better to start with a smaller project to get under the radar of the press and fellow developers earlier?

For me, the smaller the better. But, no matter the size of the project, I like to read this piece by Tommy Refenes every once in a while. You have to divide your project in parts, tackle those parts individually and every now and them step back and enjoy the progress you made.

3. Do not make a simple idea complex.

Do not overcomplicate things. This happened with Little Red Running Hood. If you start thinking about adding stuff, stop and evaluate if those things are really going to improve player experience and if they sit well with the core mechanics.

I found that the two next items on the list are important agents on avoiding adding useless stuff to a game you’ve been working on for months. You can also read more about this here.

4. Do not skip the prototype phase of development.

So, how do you keep from adding useless things to your game? You do this kind of thing on a prototype. That’s why it is important not to skip prototyping, specially when you’re really eager to start making something. It’s an opportunity to let your big creative brain run on overdrive.

By making a prototype, you can find out if the mechanics created really work by their own. You can also get folks to play your idea and get decent feedback to improve it. Yes, you will probably need to improve it.

Discover if your game, in its simplest form, is fun before investing months of your time developing it.

5. Do not forget to make a GDD or write your ideas down somehow.

Ideas have this weird behavior. Sometimes they run away and are lost forever. Other times they mutate… it can be to something better – which is cool -, but they can also transform into something nastier than their original version. Writing them down is a way to avoid such messy scenario.

When working with teams there is also this strange thing that happens sometimes. You can try to explain your idea to me and I can choose what to listen or twist it somehow. Or maybe your explanation isn’t clear enough. When the time comes to actually implement it, it won’t turn out as you expected. Hopefully, a well documented idea can solve this situation.

A GDD also makes things easier when there is need to bring someone new to the team, specially if the person is working remotely. It gives a full perspective on the game.

6. Do not underestimate the power of good planning.

Deadlines are awesome. Most of the things done on this planet have only been accomplished because of them. Without them, we feel too comfortable and a comfortable creative mind starts wandering. Before you realize, you’re taking double the time to complete simple tasks.

Other positive aspect of good project planning is that you are able to focus on one thing at a time. You don’t have to worry about those awful bugs, because you will have the proper time to deal with them later.

Some people might think that’s only for larger teams or projects. That’s OK. In the end, if you sit down every day and do the work you need to do, it all falls into place. Me? I like a good old fashioned deadline.

7. Do not leave marketing to the last months of development.

Legend has it that when Brazilian cartoonist Maurício de Sousa started drawing, his father told him that there was no problem with that, as long as he learned how to sell his creation too. Thankfully, he listened.

Here is something I see most of indie game developers around me doing: they focus exclusively on the technical aspect of making a game, without even thinking about how to get it in front of larger audiences. Not even to play test the things they make. They worry about it much later, when the project is near the finish line. Alexander Bruce has some great insights on how that can lead to obscurity.

Hopefully, as the industry matures, beginner indie developers will become more aware of that and will start getting word out earlier and saving bigger budgets for marketing.

8. Do not play test only by the end of the project and/or only with friends.

Like stated before: it is best to have large groups of people playing your game as soon as possible. You followed the advice provided here and built a prototype? Show them to strangers on the street. Go to events with the latest build of the game and get as much feedback as possible. After that, make some adjustments and go to the next festival.

9. Do not start on the mobile market.

This one is the one I get most of people disagreeing with me. It’s the first item on this list making young developers see everything optimistically. The real truth is: the good things on mobile are far less numerous than the bad things going on on the platform.

Seriously, if you are starting, with no fans, no press awareness and no big money to invest on marketing, forget the mobile market. This is something I learned the hard way. I saw months of hard work fall into the limbo of the App Store. Obscurity is a bitch.

Even if you forget the discoverability of games on the mobile market being all messed up, I really don’t think you should start there. There are easier and faster ways to make and distribute games. Part of the reason we didn’t play tested Little Red Running Hood accordingly was the fact that it was hard for us to send the app to people outside of our friend circles.

I realize there are two sides for that discussion and that there are down sides to any market, but I will remain encouraging people to start reading more about the problems of mobile and all the stories of other developers who fell for the mermaid’s song.

10. Do not forget the budget for attending events and festivals.

Hands down, this is the best way to show your game to other people and starting networking with other developers and press. These are creative minds that gather on the same place at the same time because they love games. That’s inspirational. At least I heard. I was stupid enough to consider only submitting my game to these festivals, but never thought of showing up in person. When I realized the benefits of attending these events, I had no money to do so.

11. Do not ignore the fact that you are part of an industry.

Starting out on any industry is hard. It is even harder if you are blind to all the topics and people that are relevant in the business. Luckily, this is the easiest tip on the list to follow. Just check this list Rami Ismail wrote with some interesting twitter accounts on the gaming world (don’t forget to follow @tha_rami himself). Don’t have a twitter account? Fix that now, it’s free!

12. Do not wait for a diploma to start making things.

You are not studying to be a doctor, lawyer or engineer. Maybe if you were you would have realized something most of my colleagues at university don’t.

You want to work in a certain field? Start thinking of your career early.

Stop throwing that unfinished project away at the end of the semester. Stop doing things for grades. Stop doing things for love, too. Do it for your career. Love your career itself. Become a professional and finish things!

13. Do not hide those things.

I know for a fact that there are a lot of people around me doing things related to game development. However, I know very few of those people and even less of their games. Why is that?

If you are working on a game and you hide it from people, you are being selfish. You are keeping them from having fun. You are also overconfident. Before spending more time working on the awesome idea you had, how about you let us play it and them we can give you feedback?

I am currently trying to organize meetings with developers to get something going. If you are a local indie working on a game, please get in touch. It isn’t hard to find me. If you made it this far on the post you are truly persistent, therefore I would like, not only to play your games, but also to personally high five you.

Bonus for Brazilian developers:

This consist of only one tip, but it can make all the difference for people with tight budgets. Maybe it applies to other countries too, but for now I only know how this works in Brazil.

14. Do not open a company.

You are just starting out. You don’t need to pay taxes, you don’t need to have an accountant and you don’t need fancy paperwork (and believe me, there is a lot of paperwork).

Focus on building something first. Make some games, get some word out and try to find your voice. Partner up with different people and get informed about their experiences. There are many other ways to start out other than opening a company right away.

Actually, those who encouraged me to start a business were the ones who were interested on doing the accounting for us. Coincidence? I think not.

The damage wasn’t that much, but the money we put into the company could’ve been used to show our game on events. International ones.

Now, I only see a point on going through all the paperwork to register a business here if you are aiming to get a deal with an investor, join government programs or sign a contract with Sony or Microsoft. You have to really trust your gut to go for those things as a beginner. But, if you decide to do it nonetheless, let me know how it turns out.


Even if you don’t take any of my advice, you are probably here because you are interested on game development. So, I wish you keep making great games. Maybe someday I’ll get to play them.