Update 2

So its been a while since I've updated this blog, almost a month. Throughout this time, I have made progress on the game, I just had little time to actually blog about it. Although the progress is less than what I would have liked, I still managed to do something in the relatively hectic past few weeks. I've had to move from my place near the university back to my parents' place, attend a few good-bye parties, working another job and accept a new contract which will fund me (yay!) for the next few months. With that over, on to the important bits.

Progress

 With 7 of 8 weapons finished last week, the final weapon took me much longer to complete than anticipated. It wasn't any technical issues or anything, but rather I just couldn't, for the longest time, come up with a good final design that fit with the other 7 weapons. The name for the weapon coincidentally matches an item from XCOM: Enemy Uknown, as I've recently found out. Not trying to steal names, I swear! Anyways, the design is below:

Arc Thrower - This weapon shoots out two projectiles that are tethered to each other by an electric arc. For the first second or so, the shots are extremely close together and move relatively slow. They quickly separate to a larger distance, and begin to move much faster. Most projectiles inherit the velocity of the player (and thus become harder to aim with), but these projectiles go straight on target once they have expanded. The area between the projectiles is harmful to enemies, and these 2 projectiles can pass through any enemy. This is similar to the 'over-penetration' from the spike shot, but in this case, there is no limit to the amount of enemies the shot can go through. The alternate fire primes the next shot to be overcharged. When an overcharged shot hits an enemy, it sticks to the enemy and discharges electricity that damages any targets nearby for a short while.

With all weapons now functional, I was free to start working on modifiers. As a refresher, modifiers are what's in the other 2 inventory slots, besides weapons. Modifiers apply status effects on enemies that offer tactical advantages to the player.

Sharpness - Any incoming shots are guaranteed to go through armour, but at 60% reduced damage. This is great for setting up for other modifiers. Great for enemies that have high armour values but low health values. Useless against enemies with no armour.

Force - The player's shots move much faster, any explosions caused have much more force and projectiles often push enemies around. This makes it easier to aim with most weapons. Incoming damage is increased by 10%.

Fire - If successfully hit, fire causes the enemy's armour to slowly melt. Armour melts much faster with each successive hit. Great for targets that have both high armour and health values. However, it is useless against enemies that have no armour.

Poison - If successfully hit, poison will slowly drain an enemy's health over time. Poison damage will always ignore armour, but the shot has to successfully go through armour first to deliver the dose. Health goes down much faster with each successful hit with poison, however, poison damage will never lower the enemy's health below 1. This means the player needs to finish off poisoned enemies. This is great for enemies that have lots of health, but relatively little armour.

Venom (not finished yet) - If successfully hit, venom will slow enemies down, therefore making them much easier to hit, and preventing them from catching up to the player. As with poison, a shot needs to go through armour to inject an enemy with venom. The more venom applied, the slower the enemy goes. The stacking effect is much less than that of poison or fire however. Less useful against big, slow, lumbering enemies, but extremely helpful against fast and nimble opponents.

Stun (not finished yet) - If successfully hit, stun will prevent enemies from attacking. The enemies can still move around, but cannot utilize any weapons they have for the duration of the effect. Useful against enemies who attack rapidly, or against crowds of melee opponents.

As I was trying to finish the last two modifiers, I realized that they cannot be implemented until some code is done in the enemy classes first. This set off a chain of realizations. I tried to implement some basic code in the enemy class, but did not want to jump the gun and start coding without thinking about the structure of it all. But as I was trying to figure things out, I noticed that I was going around in circles, confused, about how to actually go through with it. The reality was that it was not a programming problem, but rather a design problem. I've never actually thought about the higher concept for the game. I was focusing too much on the interactions the player will have moment-to-moment. But when trying to structure AI code, it needs to serve some sort of higher purpose. Since you're programming the enemies' behaviour, and therefore shaping the experience the player will have, you need to have a solid understanding of what you actually need your enemies to accomplish in the long-run. How do they move around the level? What is their purpose? What are their goals? Do those goals change? Are they supposed to always be on the offensive? Do they give perks/benefits to their comrades? Questions like these forced me to evaluate the high concept for the game, something that didn't really exist beyond "hey, you fight some synthetic wasp-like things".

Lesson learned I guess: when making a game with a very small team (for me, a one-man team, but a friend of mine might be helping me out with the project sometime soon), design everything first. It is tempting to go gung-ho and 'just start programming' in the hopes to get results as quickly as possible. This seems especially tempting with a project that has a small scope because each feature seems so do-able. But with my experience in past projects, this is an invitation for disaster. Programming without prior knowledge of what the end-product is going to be will result in sloppy code, and nobody wants sloppy code, especially the programmer. Always have a plan, and it will be much easier on the programming side of it, got it! This in turn, will have me going back to the drawing board to do some serious design work. This means in my next update, I'll probably talk about the game mechanics in more detail, and how they all come together to create a holistic experience.


Art Style and Direction

In my last post, I was talking about the art style that I wanted for this game. The games that I mentioned were N+ and Outland, with an emphasis on silhouette and glowing edges. I also mentioned that I was going to try to draw some concept art for the game, to drive the point home and nail an art style. Well, below is what I came up with:

I think this picture adequately illustrates what I want the majority of my enemies to look like. A single colour that belongs to a particular group (say orange for wasps, yellow for bees, red for hornets, etc) which makes the enemy identifiable. I think it also captures the 'silhouetted' look I was talking about in my last post, with a pretty display of glowing edges, like in Outland.

I was about to not do a concept art piece for this post, but decided against that in the last few days. The piece overall took me about 1.5 days to complete, which sort of positively surprised me. I thought the concept would take much longer, hence my reluctance to include it in the post.

This art piece also made me really think if I need to go 3D. As of right now, I still do, but the various layers in Photoshop could easily be exported as a separate image, and then animated in Unity to create some believable animation. This supports a 2D approach, but I guess this will be a back-up plan in case something drastically wrong happens for plan A. The reason I want to go 3D is that, in my opinion, it will help immerse the player, and make the characters seem more 'alive'. Having a 3D model will give me much more accurate lighting than 2D. Especially with dynamic lights that can appear to be in explosions, projectiles, other enemies and so on. I feel like this will amplify the look of the game, and make the explosions, particle systems and so on more visually rewarding.

Conclusion

And that's a wrap. I'm not sure how often I can update this blog or work on the game once I sign my contract for a job I'm getting soon. With 40 hours a week, its not too bad, considering some game dev people pull off 80 hour work weeks. Although this will slow down my progress with the game. I was hoping to get some cool gameplay done before the Montreal International Game Summit (MIGS) so I could maybe show it off there. But with the conference being the week of November 11th, I'm being a little skeptical of my ability to both work 40 hours a week and deliver an awesome demo before then. Oh well, at least I'm happy the job will keep me funded, especially since I'm going to pay close to $800 for the trip to MIGS, and I have some pretty outstanding student loans... It's also nice to have at least some sort of financial security.

Well anyways, thanks for reading, mystery person who actually reads my blogs.