Behind the scenes #2: Making the Rules

Hello!

Today we present a first mini-blog in a range of upcoming blogs to show you the second episode in the How it’s made video series: Making the Rules. Our colleague Rens is making these videos and we hope that they help give you more of an idea and insight into how we work and also show you a little of the work itself!

So what is this video about? It actually goes more in-depth on a previous topic where we discussed how we come up with features and prototype them before actually adding them to the game. To do this we make use of a feature matrix (remember it from a few blogs back? Image below the video). Using this matrix we can recombine existing features and combine them into new topics for mechanics or puzzle designs. We can also use this matrix to test out new idea proposals to see if they actually match with the existing content, of course you don’t want a new feature that completely breaks the balance of the game!

AI Vendetta Dev Video #2: Making the Rules

As you’ll see in the video, we usually start of brainstorming together to generate ideas. Our designer then further develops these in a concept and at the same time also validates them with the existing game content using the feature matrix (image below), among other tools. After the concept has been developed and an official design is made, the idea is then prototyped in a safe testing environment where it can be tested in various situations. Finally, when it has been completed and approved by all parties involved it can be polished and added to the game.

[ FEATURE MATRIX ]

This concludes our mini-blog. We hope you enjoyed the video and if you’d like to play the game for yourself, you can do so by clicking on the following LINK. Remember that the web demo is playable in Internet Explorer, Firefox, Safari and Opera after installing the Unity web plugin. Feel free to let us know your thoughts on the video and the game! We’d also love to stay in touch if you have any questions or suggestions, especially with our fellow developers from all around the world!

See you all next time!

~Thom de Moor, CatByte Games

If you are interested in following our progress, follow us on Blogger, Facebook, Twitter, YouTube and Google+ as well as our individual members on Google+, Twitter and Indie Gamer.

How do they do it? - Programming

Hello!

Here is another dev blog in the How It's Made series! Today we are going to talk a little about Project Management as well as a little bit more in depth about programming the game AI Vendetta. We will also give you some useful tips that are not just applicable for programmers but for designers and project managers as well! This part may feel a little bit like a lecture but bear with us and you might get some useful tips out of it for your own projects! But don’t worry, we won’t go into too much detail when it comes down to the programming part!

Before we start however, I’d like to announce that a new and improved version of the AI Vendetta demo went live recently. It contains many fixes, tweaks and visual changes which we think you’ll like! And of course, we’d also love to hear what you think about it!

Remember that the game is playable in the following browsers: Internet Explorer, Firefox, Safari and Opera. The web demo will not run using Google Chrome unfortunately.

So what is this dev blog all about!?

You might just be wondering that! Well since programming is a very large subject we are going to talk a little bit about what we learned in past projects and how we are applying that to AI Vendetta. As we mentioned in previous posts, Iteration is key to development and iteration is also what drives us and me as a programmer to develop smart and flexible solutions for AI Vendetta. This allows the game to grow without increasing the complexity of the code. In the long run that allows me to better change existing features as well as add new ones. Which saves me time, a lot of bugs and other worries as well!

On the other hand, this also costs you more time to set up and stands in the way of prototyping an idea right away when you just start a project. So why do this? Well that brings me back to several valuable lessons I once learned from my teacher, mr. Dino Dini, as he explained the dynamics of a project. This is something that is really relevant to development and not just for programmers but everyone involved.

Basically, whenever you are working on a project, you are dealing with Unknowns in one way or the other. And Unknowns cause Risks for your project that can be pretty harmful, and unfortunately, you are almost guaranteed to run into them! So how can you mitigate these so that when they occur, you can at the very least minimize the damage? The key to this is to maintain Flexibility.

I know Flexibility is a very abstract term and you can apply it in many forms, some more desirable than the other. The way to maintain Flexibility in programming is through architecture, structure and abstractions (and staying away from programming (anti-)patterns, for which I can advise a few good books).

But how can you maintain Flexibility as a project manager? Well the truth to that is… it is very hard! Especially if you have limited experience. But there are some tips we can give you and likely scenarios you’ll encounter in game development.

1.    The first rule is, stay on top of your project! In game development all sorts of things will happen, so staying connected with your team and the current state is really important. We often try to do a weekly meeting so we can discuss what we did that week, how well it went and what our plans are for the next week (and the near future). This really helps so you can monitor issues before they arise and support each other with any difficulties you encounter.

2.    The second thing is to document your work. Usually when starting a project or a component of your project you’ll start off with developing a high level concept (Abstract idea). Next you process this concept into the actual design or steps that you are going to take in order to achieve that concept (Concrete). At that moment you are already breaking down your project into manageable steps, so that is a great start! As you do this, you can start identifying issues and unknowns in the concept. As a designer you are usually already doing this by creating Concept- and Design documents for your projects, so hats off to you!

As a programmer, you may want to consider writing technical documents; these are essentially the design documents for your code. And I know this is probably not the most fun thing you can think off, and to be completely honest, I don’t do this every time either! But this has certainly helped us in validating an idea or approach. Besides it also helps convey what you are trying to do to your colleagues.

A good example of this was when we decided to completely redesign how the Playable character in our game works on a technical level. As we were working longer on the game, the functionality of the player started to increase and with that the complexity of the internal workings as well! At one point we really wanted to refactor the way this system worked so we could compartmentalize all the mechanics of the player whilst also increasing the flexibility of the system. Because this was such a large procedure we decided to work it out on paper first. …A few drafts and changes later we were able to implement it smoothly into the game.

    

3.    As a third piece of advice, keep in mind the Scope of your project. The scope is directly related to unknowns in your project. As you work on your project, the scope always tends to increase as you may want to push features that are deemed necessary for your project to work that were not thought of initially, but projects also tend to “feature creep”.

Of course you still want to deliver the best product you possibly can, but sometimes you have to be a little bit hard on your team for the sake of the project. Projects going out of scope and out of budget are a few of the main reasons why a project may fail. Finding a good balance will keep your team happy and your project healthy!

4.    And the fourth and final piece of advice. As a project manager, especially with small teams, try to stay on the same level as your team. People often look at each other for advice and responsibility. So always maintain a problem solving state of mind and work together to avoid issues and solve problems as they occur.

5.    Bonus advice: make lists, I love making lists so you get an idea of where you are and what is still left to do. What we tend to do is make use of bug reporting tools to create a list of not only bugs but also features that we want to implement, for example when preparing a new demo. Because of the list everyone can stay up to date with the current status and personally, I love it when everything gets crossed off from the list :D

    

So where is that programming talk I was waiting for!?

Well, as I mentioned, programming is a BIG subject, but I hope that some of the things discussed above in some way help you with your project. It is probably all very straightforward but creating games is a big and complex process and I really admire everyone who sits through that process!

But before we start rounding off this blog, here are some technical specs about the game!

As you may know, AI Vendetta is being built in Unity3D. To do this we make use of C# as both Rens and I have a C++ background, so C# was the closest thing to our comfort zone. And as you may come to discover as well, C# is a really great programming (and scripting) language!

What I personally really like about Unity is that it is a very great and easy tool to learn, whilst still providing lots of support and possibilities for advanced users. Another great thing about Unity (and many other modern game engines) is that they are also really accessible for designers and artists. In the past I was used to creating tools and editors myself, but Unity has made it really easy to expose data to an interface. So while the programming team creates the game, they can expose the tweakable data to designers and artists so that they can set up and tweak the game and its components.

But here is a short list of what we especially like in C# in particular:

1.    Memory Management. In C++ this is a really hard thing to get right, you probably need to write a memory pool and you have to keep track of everything that you “new”, you also “delete”. In C#, at least short term, this becomes a bit easier with the Garbage Collector; however, you still want to keep an eye on your memory footprint of course ;)

2.    Reflection. This is an amazing feature of both C# and JavaScript, it allows you to instantiate an object, just knowing the its type, you can even convert a string name into a type and then instantiate it (useful for example in serialization).

3.    Pointers, or rather the lack of them. When working in a language such as C++ you really need to keep track of the scope in which your objects are declared. And then there is a difference in memory (it can static-, stack- and heap memory), but in C# you really don’t have to keep track of that. And the really nice thing is, every object or variable is maintained as a reference, so you can freely share and pass them along in your code.

4.    The final thing I personally like about C# is that inheritance and virtual functions are a bit easier to declare and manage. In C++ I would usually create Macros to make things a little bit easier, actually approximating how C# exposes base objects and functions.

So yeah, C# is definitely easier than C++ and there are some very cool features in C# which don’t exist in C++. So why do people still use C++?

Well, there are very good reasons to do so. C++ gives you a lot more control over your application, but it also allows you to make very in-depth optimizations. You could even go as far as partially writing your application in Assembly if you like. But not only do you have more control, C++ is simply faster because C# in Unity is a scripting language and it is being interpreted. Whereas C++ is directly compiled into instructions that your computer can execute, making it inherently faster. However, with the speed that current computers run at, C# with Unity is still an excellent choice for creating games! And not to forget the multiplatform support Unity offers.

But I can go on about this for a long while...

    

What can you expect from us in the next Blog?

Well, for our next blog we would really like to discuss some of the results from the play tests and perhaps introduce some new features as well that are currently in development.

There is also a new “How it’s made” video coming up in the next few weeks, so stay tuned!

We would also love to hear what you think about the project so far and if you haven’t yet, give the demo a go let us know what you think! If there are any questions or comments that you have, or maybe a subject you would like to hear more in-depth about, please let us know in the comment section below! Of course you can also contact us through various other media (Check out the Contact tab on the top of this page).

And perhaps you are working on a game of yourself as well? We’d always love to share experiences and help others if we can, so stay in touch!

That’s all folks! Be sure to try out the demo and let us know what you think.

Thank you very much for reading and we hope to see you all again next time!

~Thom de Moor, CatByte Games

If you are interested in following our progress, follow us on Blogger, Facebook, Twitter, YouTube and Google+ as well as our individual members on Google+, Twitter and Indie Gamer.

How do they do it? - Level Design

Hello! And welcome back!

First of all, another (slightly belated) happy new year to all! We hope you all had a nice holiday and perhaps made some good new year's resolutions?

Last time we blogged, we introduced the first playable demo of the game to you. It's been a whole month since then and we have been keeping busy. Right now we are working on a whole new set of levels and mechanics for the game! We also updated the webpage slightly, so for those who haven’t yet played the game, be sure to check it out here.

(The web demo works in Internet Explorer, Firefox, Safari and Opera, you may need to install the Unity Webplayer plugin first in order to play the game)

So, let’s move on to the topic of the day!

Today we would like to continue on our “how it’s made” blog from last week, and with that also introduce a short video series on how we are producing the game. The video series will show you some of the methods we use in the production process, but also exclusive in-game content! Although we intend to make this informative, we’ll try to keep it on the lighter side. ;)

Acquiring the Matrix!

Any game typically takes shape starting with a design. This can just be a cool or fun idea that you have, but usually in game development you want to write it down and refine it into what is called a concept document. These are the barebones of your game and allow you to pitch your game idea to others either to sell it or acquire (human) resources. Next to that, the concept document is a means for verifying your idea before you take it further into development.

Although this part is sometimes skipped by developers, please make sure that at some point you verify your ideas, otherwise you might end up with a game that is absolutely amazing, but only tailored to what you like. You may find that there is no audience to play your game, which would be a waste of all your hard work! That being said, it is important to always try and make games that you yourself would want to play if you are in control of the design because at the end of the day, you are the one who has to defend your game and show everybody how great it is! Finding a balance between what you would like and what others would like to play is therefore essential.

Luckily for us, we already made a prototype as proof of concept for the game as a school project. This allowed us to create a basic design, pitch it to teachers (with game industry experience!), and build a basic prototype. We’ve come a long way ever since and have now completely rebuilt the core game (in a new engine) and lots more!

As we’ve mentioned in our last blog, iteration is key in game development and it is best to do that right from the beginning. Even when you are uncomfortable with pitching your ideas to others, start with showing it to your friends and family. But keep in mind the target audience you are trying to reach.

So, as you saw in the header above, using a matrix (not The Matrix) can be quite useful to developing both new game ideas as well as the actual development of a game. So what is this Matrix thingy? Well, one day, a colleague of mine explained this to me and I immediately fell in love with the idea. Basically, you start with a two dimensional grid (matrix). On both axes, write down all ideas or mechanics you can think of for your new game (or the existing mechanics of the game you are creating). The diagonal line in the middle where the same ideas match is usually not used, but you never know! So what you do next is you lay down each mechanic next to another and see if that would lead to a promising new mechanic or game idea. You can also use this for level design; that is where we are using it for at this very moment! It makes sure you don’t forget about your mechanics, and it allows you to recombine them and create whole new mechanics and game experiences.

Here is a screenshot of what the matrix would look like:

You can do this on paper but you can also use office applications such as Excel to visualize it.

Example Matrix

 Simplified Matrix as we used it for our game.

As you can see, not all combinations lead to (useful) outcomes.

Level Designs, how do they do it?

As we’ve already mentioned, we like to use this matrix method for coming up with level designs. However, to come up with these levels, we first split up the game into several sections. Each section consists of about 5 levels and introduces one or two new mechanics. So for each section of the game, we already know which mechanics we are going to use. We then add these mechanics to a matrix and use that to design (small) individual puzzles. With all these puzzles and the general storyline of the game we decide on a level layout and implement the puzzle designs into it. Eventually, this leaves us with a level design.

You can design these levels on your computer using a drawing application, but you can also use Excel if you are building a tile-based game as we are doing with AI Vendetta. However, we personally prefer to do this on paper, because it, in the long run, is quicker for us and allows us to write comments and explanations as we go. (Although you can of course also achieve this with a lot of computer applications.) Or... you can even build your own level design tool if you have the time!

As we’ve mentioned before, we are working on a short video series on how the game is made. Today we can introduce to you the first video of this series, created by our very own Rens van der Meijs!

What can you expect from us in the next Blog?

And with that we are running towards the end of this Blog. We hope it may be of use to all of you who are interested in the games industry or are (starting with) developing games of your own! If you have any comments or questions, please let us know! We are always interested in helping others out or giving advice!

Again, if you haven’t already, you can play the game using this link. We are always happy with any feedback you may have and will do our best to implement it into the game! We may be posting updates to the playable demo as well, although we will probably not feature the actual levels and story that will end up in the final game – as to not spoil it for anyone!

If you are interested however, we may be able to set you up for closed testing once we are well on our way in the Beta phase of the project.

That’s all for now, thank you for reading! In our next blog we will continue on how the game is made and let you in on other tips, tricks and methods that we use. We hope you enjoyed this blog and we would love to see you all again for our next blog!

~Thom de Moor, CatByte Games

P.S. If you are interested in following our progress, follow us on Blogger, Facebook, YouTube, Twitter and Google+ as well as our individual members on Google+, Twitter and Indie Gamer.