Sunday, 22 May 2016

How do they do it? - Programming


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.

No comments:

Post a Comment