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.
