Background

It's been a few days since I put my latest alpha of my entry for the Tower Defence challenge on itch.io and my project page:

https://lawnjelly.itch.io/ramsbottom

I think I've covered the requirements for the challenge, and made the game a bit above just the requirements so it is a bit more fun to play and has some longevity.

The reason I entered this time is because I'd been watching the previous challenges with a little envy, and had been waiting for one that seemed simple enough (I think the last one I looked at had multiplayer and I knew that could be a bit of a bag of worms). My usual low level c++ / opengl approach would probably be overkill for a small / low timescale game, so I decided it would be a good opportunity for me to try out Unity engine, which a lot of people are using currently.

What went right

1. Using Unity

• Rapid development, well suited for this type of small game.

2. Attempting to get as much of the challenge completed asap, then leaving further time for more features / polish.

• I finished much of the base functionality in the first week, then spent time on and off in the next few weeks just making it better.
• There are lots of advantages to getting something 'finished' up front, and this is a development model I am trying to move towards.
• You can 'call time' at any time, and still have a functional product. Unforeseen events always seem to appear and limit the time you can spend on a project. This approach guarantees that even in this situation you will still have a 'product' rather than a half-done version of your 'glorious vision'.

3. Using the asset store, not building all the models myself, and using sites such as freesound for the sound, and creative commons music.

• For small learning games such as this it didn't make sense for me to make the assets. I know it takes me 2/3 of the time to make artwork etc, and while I am improving at it, I am better at (and enjoy) programming more than making artwork.

4. Finding some good tutorials to learn Unity (then throwing out their approaches!).

• There are some great tutorials out there (brackys for instance), and these are good for learning unity specific stuff, but in some cases I could instantly see better ways of doing things. I put this down to many tutorials being pitched at total beginners, who are happy to get anything on the screen. But e.g. using Unity editor to lay out levels just seemed ridiculous and limiting.

What went wrong

1. C# .

• I hate it, absolute abomination of a language. I spent more time than should ever be necessary screaming at the damn thing, it makes visual basic look like Shakespeare. I could write a whole blog post just on the things about it that make me seethe, but yeah, if I could avoid ever having to use it again, that would be great.

2. Monodevelop

• Yeah, see point 1. Pretty bad. I might have to see if I can get another editor working if I use Unity again. I hear VS code may be worth a go (I'm on Linux). Monodevelop seemed really keen to reformat my code in stupid ways I couldn't turn off, and kept trying to autocomplete words incorrectly (that I also couldn't turn off).

3. Lack of debugging support.

• This may have been due to my setup, it might not be straightforward to get debugging working on Linux (I'm assuming with Unity it is possible to do step by step debugging?). This meant huge problems debugging anything but the simplest code (I had to resort to lots of Debug.Log statements).

4. Unity editor.

• I'm not really a drag and drop sort of guy. I tried to avoid having half the game 'code' being a particular setup in the drag and drop editor. I'm not even sure how to backup that stuff, I'm sure if I'd have had a crash I could have lost the lot. Come to think of it, did I have to backup all the assets too? With all that .meta stuff? I don't know. At least with code you can zip it up small and keep lots of backups. There should be an option in the menu to save your entire project in a compressed form without all the bloated assets etc, just the stuff that is a pain to lose.

5. Unity build times.

• I had massive problems with excessive build times taking hours when changing platform particularly, it kept baking lightmaps (or maybe something with shaders?) when as far as I knew I had tried to turn them off. Eventually more by luck than judgement, I found that deleting some skydome assets I had imported and deleting (rather than turning off) an extra light finally cured the problem. Far too little debugging info is given out by the build tool logs, to enable you to know WHY your builds are taking hours. Googling reveals I was not the only one with this problem. Don't just tell me 'baking lightmaps', tell me which light is causing this, which objects etc etc.

Conclusion

Overall I found the challenge very worthwhile. There are several of us working on it, and bouncing ideas around and spurring each other on works very well. Also a little hint of friendly competition is good too!

I managed to get fair basic grounding in Unity, and have a better idea of whether it would be worthwhile using in any future projects.. I may use it for a couple more small games, or evaluate some more current engines (Unreal, or perhaps something more code orientated).

Doing such small projects is also great for experiencing and practising the whole development cycle including release and marketing. This can give a much better perspective on how much time you should invest in different stages, and improve your ability to schedule / finish larger projects. It is something I would recommend to beginners through to advanced developers.