I'm back!

Sorry for being out for so long, the original point of the devlog on an unadvertised game itch page was to practice the routine of putting up a log of what I'm doing each week so that when it was time I actually needed the consistent online presence in order to maintain interest in the game it'd be second nature and practiced I would be ready. That's a run on sentence and a half.

Point is, this devlog is a practice for when people actually follow it, and failing to keep up with it was part of the plan so I can fix it for the future. Here is part 1 of fixing it, and hopefully the last time I'll miss posts for no reason.

MULTIPLAYER

The last time I posted, I posted something about getting saves working. At that point, I came across the thought that if I wanted to do multiplayer, it had to be done very early on in development or I had to deal with the possibility that it'd be nearly impossible to add it onto a more finished product. I decided to spend a weekend working on multiplayer tutorials in Unity to see if it was plausible. The conclusion to this experiment was that it was indeed possible to make multiplayer in a reasonable amount of time with the resources I had. So, immediately after learning this, I got to work.

Initially, I used UNet, Unity's built in multiplayer API. It was fairly straightforward, though I had to learn how multiplayer program flow and communication worked, so I was able to come up with a really basic testing prototype fairly quickly. Unfortunately, UNet came with a bunch of issues, such as inconsistencies across multiple networks and  lots of odd glitches here and there in communication. However, the deal breaker was that there was a bandwidth hard cap on the service that would not increase even if I subscribed to the service. Because of this, I made the switch to use Photon as my networking API.

Photon is excellent and I cannot recommend it enough. The API was much more documented, their sample project had way more in depth samples for usages of their different functionalities (I used the movement prediction sample a lot), and best of all, no hard bandwidth cap, though there was a cap to the number of messages per second, but that was easily worked around. The better movement prediction algorithms led to a smoother looking game that used less bandwidth, and the lack of a bandwidth cap meant that the game could be played nonstop with no disconnects.

GAMEPLAY DESIGN

This multiplayer development process took about a month, so this puts me at about the middle of September. It was around this time that despite the victory in multiplayer development, I had slowed down a bit in my work pace, and took a moment to back up and evaluate where I was in the project and how it was doing. At this point, I realized more consciously that I wasn't happy with the prototype in terms of gameplay. 

At first, I believed it was entirely because there was a lack of interesting direction in the map system. While the player was directed towards many different item rooms at once, if all item rooms generated a random item, the decision towards which item room to go to becomes the same decision, since effectively the reward you gain for any item room is the same. I looked at Terraria for inspiration with its expansive crafting recipe format of direction and decided I needed two things to better direct the player in my game. First, I needed buffs to be consistent in locations. Just as item drops are specific to certain biomes in Terraria, I needed buffs on item drops to be specific to certain branches in my game. Second, I needed npcs to give the player guidance as to which branches have what buffs, to act as something of a less powerful Terraria guide. The npcs would fit nicely into my prior design of npcs for usage of crafting functions, as now they could take buffs as currency for crafting, and would direct the player to the buffs it needs on the map.

Halfway through development of these npcs, I came across the realization that the gameplay itself was not the game that I wanted. I was so driven to incorporate ARPG ideas with twin stick shooter ideas that I didn't entirely notice that the mindless mob killing of ARPGs kind of took away from the base gameplay of twin stick shooters, which draws more from bullet hells or shmups than mob killing gameplay. When I looked at Nuclear Throne, the inspiration for mixing mob killing and twin stick shootering, I found that at its core the game is still a twin stick shooter, with greater focus on bullet hell than in mob killing, and that each enemy needed to be a threatening identity of some sort. I incorporated this philosophy and now I think the game is coming together much better. 

ART

Throughout this redesign process, I was also looking for artists. I have found a concept artist and an animator, and just recently met with them both through voice chat. They both have been friendly, easy to talk to, and incredibly patient with me and how new I am to this process. Their portfolios are also excellent and really showcase how talented they are. I'm excited to start working on putting their talent into the game. 

Benjamin Specklin - Concept Artist - Portfolio: http://benjaminspecklin.wixsite.com/portfolio

Nomis Animation - Animator - Portfolio: http://www.nomisanimation.com/

WHAT TO EXPECT

The next update will be focused on reworking the base mechanics of the game. Enemies will be far fewer but will also shoot far more frequently and have more health. Items will be rewarded much more frequently, but the common items will not have conditionals. There will be more variety in buffs and item attacks. Due to how I screwed up work priority this past month, the update will not have entirely functioning multiplayer or crafting npcs, but this work will mean when they are implemented it will be much faster development than if I were starting from scratch. 

This log has been massive, but I think it's necessary since it covers development over nearly two months. The future logs will only cover a week so will be shorter.