Arrow Game's Second Post

My focus is gradually switching to presentation of the game as I get more of the core gameplay mechanics in place. At this point I would say the game is close to the transition from alpha to beta stage, as the majority of features I'd planned for a MVP (Minimum Viable Product) are now in place and working. I've been told by a few close friends who routinely offer to test play the game that at this point it needs to begin getting development effort for the graphics. As such, I'll soon begin seeing if I can find a reliable artist to collab with.

Having worked on a few pet projects beforehand, I increasingly feel that the key to successful game development - or perhaps software development in general - is actually removing features. I've seen this sentiment echoed beforehand from a few sources, and in my experience it is perhaps the single best piece of advice I would give to developers, particularly those doing most, or all, of the code themselves. I'll likely write a short post with my thoughts on this in the future.

Level Select Screen

Achievements Screen

The focus on both the above menus is in the layout. I'm hoping that, with an artist on board, they can forget about how the programming will fit in with what they produce, and instead focus on creating the required visual elements as soon as they see the layout itself. Both screens use a similar paradigm to flip between each 'page', though I made them slightly different just for the experience.

I'm currently happy with the layout, as I feel it works on essentially all platforms that I'm interested at this point. I'm working on a Surface Pro 3, so I get to play the game with touch as I go along, and the larger buttons are definitely working.

The level select screen generates each button and assigns button commands at runtime. I had initially wanted to handcraft each 'page' of levels, but even after placing a single page it became obvious that, while simple, this was going to be very time consuming. Each group of 15 levels is a child element of gameobjects that are generated at runtime with layout components, and the arrows disable/enable the right parent object to display the correct levels.

The achievements screen instead uses a list of a class I handmade containing the relevant data structures to display what makes up an achievement. Internally there is a simple integer value that is increased/decreased by the arrows and, following that increase, enables/disables the achievements based on their position in the list.

Predictably, there's no performance benefits to either method at this level, but I would say the more easy to use/understand depends on the type of person you are. The method used in the level select screen allows you to see what's happening visually within the unity editor, but the code itself is mostly creating components, adding, and modifying them at runtime. The method used in the achievements screen is a little more abstract - being further removed from the component-based structure Unity employs - and instead focused a little more on the numbers. As a numbers person myself, I find the achievements screen is easier to get my head around, but only marginally.

Since the architecture for the majority of features is now in place, next up will be introducing more achievements, perks, and enemies. From experience this will be more of a design challenge than a programming one. However, I plan on adding a sort of 'pop up menu', to display little messages to the player. This will be used the first time they encounter new enemies to explain what they do, to tell them when they unlock achievements, etc. I feel that will be the most difficult part in the near future.

For anyone interested in numbers, there are, at this point, 18 separate scripts. They range from 50 lines to 500.