Every now and then there comes a time in a project when it would be nice to be able to write a unit test for a new or already existing feature. The reason could be that the feature is quite complex and we like to make sure to get the basics bug-free before going on creating all the stuff around it. Or you have an existing feature that doesn’t really work the way it should work and it is pretty tedious to find the bug in the running game.
Indie Gameleon is over, so it’s time to get a bit more technically again.
Programming resources are rare in most projects, so it’s important to work as effective as possible. The most time wasting things are compiling and, if you are developing for another platform than PC/Mac, deploying the game to your device to test it there. This post is about saving time by deploying as little times as possible.
It’s over! The first edition of Indie Gameleon took place from Friday, 11th September till Tuesday, 15th September. And it was just super! Super laborious to organize, but also super interesting and exciting for everyone who attended the event.
The next two posts on my blog are not particularly technical, but are a big part of my Indie developer life anyway. It’s about organizing events to connect developers which, in my opinion, is the base for new ideas, projects and games.
After the last posts about our component-based entity system framework called Slash I was regularly ask why one should use a component-based framework although Unity itself is already component-based.
While it is nice that Unity itself isn’t build in an object oriented way and might be even good enough for small projects or prototypes, you should really separate your game logic completely from the Unity engine in bigger projects.
There is no better way to raise your productivity than using good tools during your development. This way you can concentrate on developing the things that make your game special instead of reinventing the wheel for a lot of already solved development problems.
I’d like to give you a list of the most important tools, middleware and assets I have used in my past projects. See if one catches your eyes and check if it saves you as much time as it saved me 🙂
I already wrote some posts about data binding and our Unity asset Data Bind for Unity which gives you a clean way to separate your logic from the presentation of your data. The last parts were mostly about the logic side though, so let’s have a look how to combine those two.
Right now we’ve got a player character in our game who can shoot some bullets out of his weapon. Both the player and the bullets were defined in the LevelSystem, defining their components and settings hard-coded.
This is surely not what we want for a bigger game where a game designer should be able to adjust the settings without the help of a programmer and where we don’t want to recompile the game each time we change the values.
There are some things in a project that you should do as early as possible as they will save you a lot of time in the long run. The most important time saver might be setting up an automatic build server.
Even in small and smallest teams you’ll have the need of creating a build of your game every now and then. Here are some occurrences:
This is part III of a series where I’d like to show with the help of a practical example how to start a small game with a component-based entity framework. Hope it gives you some ideas how to structure your own games.
This one covers the reloading of the weapon, a feature that I left out on part II. Furthermore I’d like to have a look at a helpful utility class called CompoundEntities.