January 23rd, 2012 No comments

If you haven’t heard about Codeacademy you should really check this out!

Codeacademy is the quick, easy and FREE online solution for those wanting to learn how to code.  It’s a brilliant resource for anyone who wants to start programming but has no previous experience.

The lessons are currently based around the javascript language however, if they get more developers, other languages may be added to the site in the future.

Javascript is a great language for beginners because it will teach you the basic rules (or syntax) that most programming languages also follow like IF…ELSE statements, FOR and WHILE loops.

The lessons within code academy are broken down into step by step, bite-size chunks and even provides you with hints along the way in case you get stuck.  The layout is easy to follow and each lesson slowly builds upon the previous skills learned.  Along with being clearly laid out and very easy to pick up Codeacademy is very accessible via PC.  With links to and the ability to log into Facebook via the site you can keep your followers updated with your progress.  There’s even an ingenious achievements system called achievement badges within the tutorials.  So for all those completionists out there you can show off your badges to your followers as well.

What can I do once I’ve mastered the Codeacademy lessons?

Javascript is quite a versatile language.  The main use of javascript is web development and with the further developments of the web  and scripting languages like HTML5 and CSS3, a knowledge of javascript will be a good stepping stone.  Another great use of javascript is for game development, particularly within the Unity engine.  Using javascript you will be able to create games not only for PC, browsers, Mac and WiiWare but the Unity engine has now expanded onto the platforms iOS, Android, PSN, Xbox Live and Flash (with version 3.5).

Code Year

Code Year is an initiative launched by the guys at Codeacademy.  For those who need structure, a plan and a bit of prodding in the right direction Code Year will help keep you on track and working through the Codeacademy tutorials at a steady pace.

All of the lessons have been arranged into relevant groups that are linked via subject.  And to make sure that you don’t forget, there are also helpful email reminders so you never miss a lesson.

Sign up now and start your year of coding now!

Categories: General


January 9th, 2012 No comments

The route to becoming a game designer can be either short or long. The short route, which has become more available in recent years, is to put a lot of time, energy (and perseverance into creating your own game and release a mobile or digital game using any number of the free high quality software like Unity, UDK or CryEngine.

The long route, which is the most common, is to work your way up through QA.

But being in QA is not as easy as many outside of the industry may think. Work in QA can be long and very hard. There are a lot of different testing methods that you need to be familiar with in order to perform your job well ensuring you help to release a high standard product. In order to help your future applications into QA I have tried to define the most common testing methods used within games QA so that it may help you to either prepare for your interview or prepare for a role within a QA team.

Destructive (Exploratory) Testing

If you get a role within QA, well done! You have made your way into the games industry. The hard work begins now. There are a number of different types of testing methods that you should be get acquainted with. Destructive or exploratory testing is one of them (the precise name of this method may differ from company to company). Essentially, this method is where you freely roam the project that you are testing to try and break it in as many ways as possible.

This phase usually occurs after all of the test cases for a stage of the project have been completed. The purpose of destructive testing is to catch bugs that players may come across when not following the intended path through the project. Players don’t always progress through games the way the designers intend them to. Some go out of their way to expose very interesting or critical bugs that may range from heavily affecting gameplay to being a minor graphical issue. At the end of this phase, the hope is that a large number of these bugs are caught and fixed before the project is shipped.

When performing destructive testing, although you may have the urge to run through the project randomly breaking everything and anything in your path, I don’t recommend it. Personally, I work best with structure, when I know exactly what I’m doing. So the best way that I have found is to try and work systematically and know what you’re trying to break first so that if it does fall over, you can easily remember the steps you took to break it. If you don’t have a particularly good memory I suggest the method above too. That or write down everything that you do!

Categories: General


December 26th, 2011 No comments

To all the readers of Take Initiative Merry Christmas.

I hope you all enjoy your holidays and see in the new year with lots of festivities.

Categories: General


December 14th, 2011 No comments

Matt Glanville has worked as a level designer on personal projects and AAA titles but recently, like many others, decided to work part-time on a project that he has wanted to develop for a long time.  Unfortunately, the route to developing such a project of passion has not been an easy journey.  After trying to fund his endeavour through Crowdfunding, he found that he had to return to working at an established studio to build up funds to continue his Luminesca project.

Talking to Matt, we discover the real challenges he has to overcome being an indie developer, balance working full-time during the day and part-time on his indie project and how funding can slow the development of a project.
Read more…

Categories: Game Design, Interviews, Unity


November 27th, 2011 No comments

Video and PC games have become a favourite recreational activity since the mid-80s.  Lately they have gained a wider audiences such as housewives, young girls and grandparents instead of the usual 18 – 25 year old male demographic.

As games have changed over the years to being played on home consoles and PCs to mobile devices the design for games has greatly changed to being played on a single fixed screen to fully emmersive 3D environments.

Single Fixed screens

The first generation of games were mainly designed within a single screen.

All the gameplay and action was restricted to one screen.  When the player progressed, new enemies and obstacles were either spawned into the same window or the entire window was replaced with a new level like in Space Invaders.

The character’s position was usually fixed  or had a minimal amount of movement (usually only moving either to the left or the right) so the player only had to focus on the enemies within the window and how to react to them or their next challenge.  This meant that the level of mystery for what was coming next was far lower.  Usually the designer increased the level’s difficulty by increasing the speed that enemies and obstacles approached, increased the difficulty of the individual enemies making them more of a challenge to overcome or decreased the amount of protection the player had to make them more vulnerable and susceptible to attack.

Read more…

Categories: Level Design