Making my first game – Part 1: Conceptualizing
After a year of diligent self-learning I felt more confident around Unity and became relaxed when writing my own code. I always tried to perform coding challenges in tutorials. Very often I managed to write working code which matched the specifications set by the tutors. At the same time the code was quite different from what the tutors wrote themselves. Not to say it was better, but it was fun to compare my solutions to those of more experienced coders.
Conceptualizing my game
I have just finished a tutorial for a simple 2D tower defense game (parts of which I have written differently than the tutor). While placing tiles for the game map I had a thought. “Could I write a solution that would randomize background graphics, so that tiles wouldn’t have to be placed by hand?”. Coincidentally, I had recently watched some tutorials on drawing 2D tilesets. I quickly sketched some walls and floors, created a TestProject in Unity, and started to form a general idea:
- The target game for my test solution would be a side-scrolling 2D platformer. So I would need to make some rooms connected to other rooms. I did not plan any vertical movement, only a horizontal sequence of several different rooms.
- To draw random backgrounds I would need to create prefabs of rooms.
- The rooms were not intended to be totally random. Some form of artistic control would have to remain. Walls closer to ceiling would be in shadow, walls closer to the floor would be more worn out, maybe covered in some moss or humidity.
From concept to first steps
To fulfill this specification, I have drawn four types of tiles for the walls. Top walls (shadowed), central walls (standard, most frequent), bottom walls (touching the floor, worn out), floors.
The next part was to randomize the stuff. I made a prefab for a room, to this prefab I attached objects that would serve as containers for each type of wall. Each container would have a script attached with an array of possible tiles. The script would randomly select one tile at runtime. And this was basically it.* Below you will find the sprite sheet with the tiles and the Unity package with the ready solution. You can use the sprite sheet any way you want (the license file is attached in the zip).
You can download the asset pack containing the walls in the download section or using this link.
The solution is really simple, but is it efficient? Maybe someone with a deeper knowledge of the inner workings of Unity can analyse this to show the influence on system resources? Anyway, writing this post already took me more time than writing the code. While this may not be the most optimal solution, the fact that I did it by myself and very quickly made me confident, that I could make something more out of this test project. But this is a story for another post.
*When I look at it now, I wonder if this solution is really hardware efficient. It is really not noticeable at a first glance within the Unity Profiler. The game is quite small and always runs at very high FPS with no drops.