Coming back

[This devlog has been in my drafts since 2020, I'm publishing it now because why not. I did not end up doing what I discussed in this post because I got a job, which was the goal after all]

This game was my first independent project in Unity and C#. Over the last two months I've been studying a lot, having participated in 3 game jams and having read/watched everything I could find about unity features, C# programming, and game development in general.

A quick shoutout to Jason Weimann on youtube, he has amazing guides and discussions about applying programming best practices to Unity development.

I'm coming back to this game because I think it had a lot of promise, and scope for expansion, while being a bit of a mess behind the scenes. I also think it will be fun to try and implement what I've learned, and why not try to tidy up my portfolio as I do so.

Where is it Heading

I think the premise of clearing fixed word grids is great, it's a nice step up from a simple wordsearch. What I need to add to this game is a good level generation system, that can generate levels from a subset of words to create themed levels. This will basically provide a hint to each grid, if you can spot the theme, and will make generating groups of themed levels very easy.

The other reason for making this improved level generation system is that it could be used by the players to create and share their own levels. I think this could be a really fun feature, and challenge for me to implement, so want to try it out.

Lastly there are obvious improvements to visuals and sound, as well as feedback, that I will be trying out. These will probably have the biggest effect on the game in all honestly, but I will tackle them after. This is primarily an exercise in programming after all.

Looking Back

Step one is to tidy up the code to make it first of all presentable, and second of all to help me build on it in the future.

So the glaring problems with my code are:

1) Giant classes performing too many jobs (Single responsibility principle)

2) Little data encapsulation, most variables are public

3) Interdependecies. Most classes and objects are linked to many others, creating a spiderweb of dependencies.

The starting code is the initial commit in this repository: https://github.com/jarcangeli/Wordcrush-scripts

Solutions

- It should be pretty simple to break up the large classes into smaller chunks based on their roles. In fact doing so will make it clear what does and doesn't need to be public, helping point 2.

- The dependencies right now can be fixed in two ways. The first one is implementing singletons where appropriate, which will remove the need to find objects or assign them to components in the inspector. That's still a dependency however, so the second change will be to create some custom events based on player inputs, that each of the classes can listen for. That way if I decide to remove the CheckTray from the level, nothing will break, as it won't be registered to any events or be required by other classes.

- Level generation is going to need a pretty hefty rework of my level generation method. This enormous method handles every part of level generation at once, but after breaking it up I will be able to use the pieces to create a level generation screen for players (and me) to use.

Last Thoughts

Currently there are no implementations, or plans to implement, any abstract classes, interfaces, scriptable objects, delegates etc. Now that isn't really a problem, it's a simple game that may not require such tools. However I will be keeping an eye out for such opportunities, because there could be places where they could help. 

I imagine if I decided to have multiple types of tiles with different animations etc there would be an opportunity to implement some abstraction. Alternatively an interface could be used by several components that all need to define their own response to a player driven event, this could be an alternative to or coupled with the custom events I was planning on implementing.