I have been making some pretty good progress since the last time I posted. In my last update, I was promising to talk more about the design of the rest of the game (besides weapons and enemies), and now I have such designs fleshed out, and implemented in the game! The cool thing is that I actually have way more implemented already than I'll be able to talk about in this update. There is quite a bit to cover, so I will split this into several updates.
Level Design
At first, I did not know whether I wanted the level to be hand-made and have a system where players choose their arenas, or players just pick a bunch of parameters and have a level generated for them. Going rogue-like seemed more interesting to me, so as of now, the levels in my game are procedurally generated.
Making that one decision now made my further brainstorming session more focused, as I was trying to come up with interesting ways to both generate the level, and then make the randomly generated pieces relevant to the rest of the game.
The first step to generating a level is figuring out how large the entire play-space is going to be. In the final game, the player will have a few options they can tweak that will determine how the level looks like. Right now all they have to work with is level size, and whether or not it will be narrow. Since I don't have any menus implemented, I have to change this right in the code. Once the general level size is determined, walls are placed at the extreme edges to prevent the player from escaping. This may or may not be final, as I may figure out or think of better ways of keeping the player contained inside the level.
Once the initial play-space has been created, we have our blank canvas for random generation. The play space initially was rather large, even for small maps, so I thought that spawning enemies randomly throughout the level will be kind of clumsy. After all, the player would, more or less, just randomly wander around in a huge space trying to look for something to shoot. I would imagine this to be quite boring. There would be the fact that you don't really know where the enemies would be coming from, which would make it a little tense and exciting, but it also has a potential to be frustrating. This is backed up by my own experiences in Geometry Wars 2, where enemies spawn randomly (and sometimes right on top of you) and is incredibly frustrating, especially if you have lots of points racked up, as it feels like a cheap shot. Geometry Wars could get away with this though, because their arena was rather small, and you always knew what was going on at all times. I cannot say the same for my game.
Since I wanted to slow the pace of the game down, and add in strategic elements, I need to give the player information to process that is rather reliable. This information is what they need in order to make meaningful decisions about what they are going to do, and why it makes sense. So now that I ruled out randomly spawning enemies, the next logical step is to make objects that spawn them. Given the art style of my enemies, Hives came up straight away as ideal objects that could become hubs/centers of enemy activity.
This idea of Hives fulfills many, many purposes in terms of both game design, and level design.
The Hive: Congregation of enemies.
Spawning enemies at Hives gives the overall encounters of player vs enemy more structure and gives the player that reliable information I talked about earlier. When a player sees an enemy, it sets up a certain number of expectations. The player can expect the enemy to lead them toward an enemy base for a more intense encounter. Furthermore, the player can also expect not to have to deal with enemies when they are not prepared. Since most enemies would congregate around their Hive, this gives the player their own domain, and therefore also gives the enemies their own domain as well. The player can then choose to enter a heavy encounter at their own will, rather than at the game's will. This is important, as the player has more agency over the factors that will ultimately end in their success or failure. Specifically, the player has the decision to flee if they feel like the encounter is not going their way. This gives them the opportunity to experiment with different tactics in the same stretch of playing time, rather than having to fail and start again. This makes the entire experience more forgiving in contrast to Geometry Wars, where you are constantly under assault from enemies until you can no longer keep up. The agency created by these decisions will hopefully empower the player, rather than making them feel unskilled.
The Hive: Conduit for Rewards
One question I had a difficult time answering is how do I give the player rewards? I created all of these awesome and cool weapons to use, and modifiers to go with them, but how do I give them to the player in a meaningful way?
I didn't want goodies to drop randomly from enemies, as this kind of randomness is not the good kind, where the game is withholding rewards from the player for arbitrary reasons. While this method works well enough in other shoot-em-ups, I feel like there could be a better answer for my game. Going back to what I said about reliable information, I want this game to be more tactical, and strategic. I want players to actually make logical choices, and in order for players to make meaningful choices, they have to have information. Random drops are not reliable, and therefore do not encourage the player to think beyond the short-term. These random drops would also encourage players to 'farm' enemies that would keep re-spawning to get the reward they want/need, and that is not fun, especially considering that the reward they need may not necessarily be the one that is dropped.
I thought about making enemies drop experience points, or something similar so that the player could unlock more weapons as they become more 'experienced' at destroying their foes, but this inherently has implications that I do not like. Firstly, it implies that each reward is in a linear progression in relation to other rewards. This means that whatever I unlock has to be better or more useful than what I unlocked previously. If this is not true then the progression would feel meaningless, and players would quickly lose interest. The design of the weapons and other rewards are not meant to be juxtaposed linearly. One weapon is not necessarily 'better' than another, it just provides the player with a different way to achieve the same goal. That being said, some weapons excel or fall short depending on the enemy you're fighting. So the difference here is not of scale, it is of kind.
So how do Hives solve this problem? The answer should be fairly obvious by now, as in, tie rewards to the destruction of Hives. Once the player squares off against the defenders and gets a foothold, they would then have a chance at destroying the Hive. If they are successful with the encounter, they get a reward for their troubles. This fulfills my desire to have reliable information to the player. They would know exactly what benefit the Hive offers (it would be some sort of visual display), and know exactly what they need to do to get the reward. The player's journey for the reward also thrusts them into the meat of the gameplay. This will hopefully make the entire experience fun, as reward is also now tied to challenge.
The Hive: Game Progression
Tying rewards to Hives also has a surprising positive side-effect that ties everything together. When rewards are associated with the Hives, it gives the game a more structured end-goal. This goal is conquest. Before, I did not really know or understand what my end game was going to be. Do you just run out of lives? Is there some sort of timer? Is high-score really the only way I would measure success in the game? All these solutions for an end goal did not satisfy me, until I found this one.
Since the Hives offer players rewards, I would expect players to try to gain all of them. I'll have to test this to see if its actually true once the game is playable, but for now I am running with this assumption. This is, I feel, a natural end-goal for the player to strive for. However, I did realize that once the player has gotten accustomed to the process of destroying hives, the gameplay might become more repetitive as the challenge will stagnate.
With this information in mind, I plan to add one 'super enemy' which is essentially a boss for the entire level. It only spawns once a majority of the Hives have been captured, and once it is destroyed, the game is over. This doesn't require players to tediously hunt down every single Hive, as they may have missed a few that had spawned in the corner of the map somewhere. Or the player may have felt that the benefit offered by a particular Hive just wasn't worth the effort This isn't an issue in smaller maps, but would get incredibly frustrating on the larger ones. So this being said, once a majority of the Hives have been destroyed, the player now has a clear end-goal which offers a new challenge, and refreshes the gameplay.
Next Time
In my next post, I'll talk about how the Hives actually work within the game in more detail, and explain the process the player needs to go through in order to destroy and capture Hives. Depending on how long it will take me to explain how the system works, I may also dive a little bit into enemy design. My initial ideas for enemies are no longer applicable because I changed so many things. I now have to re-design my enemies so that they fit with the rest of the game mechanics that I have implemented.
Friday, October 11, 2013
Friday, September 13, 2013
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.
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 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.
Monday, August 19, 2013
Update 1
Project at a Glance
I've been trying to keep myself organized using Trello, a project management software/website. Trello uses 'cards' and columns to keep projects organized. Cards are supposed to represents the various tasks that need to be done to keep the project moving, and columns help categorize the cards. Although this software is supposed to be used for team projects, with the whole point focusing on communicating project status information to other team members, I am still using this even if I am the only one on the team. Laying out tasks in this way helps me keep the bigger picture in mind, and hopefully prevents me from increasing the scope. Besides, maybe I will convince someone to help me out with the game, and if they accept, I can quickly get them up to speed using this site. Constantly shifting tasks toward the 'done' pile also feels nice, and sort of validates my accomplishments, however small. This gives me more motivation to keep hacking away at the game code, as I see tangible progress of what I've accomplished.
The above picture is kind of an 'at-a-glance' screenshot of where my project is right now. I have made 6 separate columns to organize my tasks into. The columns are ordered so that tasks in the leftmost column are essentially 0% complete, and as they keep on moving to the right, they eventually get 100% done. Right now, there are a lot of tasks in the leftmost column, for obvious reasons. I like to list tasks there that eventually need to be done to get an idea of what kind of scope I'm dealing with. This column also reminds me what I need to get done in order to have a complete game, in case I get sidetracked into implementing some obscure feature for weeks on end.
Each task is also labeled using colour to identify what type of task it is. Right now, tasks tagged with blue are programming tasks, and are the most important (as you can see, a lot of blue tasks have already been started on). Art, UI and Design have Red, Yellow and Orange respectively. Some tasks can overlap in terms of type, and therefore can have multiple colours.
Art Style and Direction
As I've mentioned in my last post, I wanted to convey what I want my game to look like in terms of visual appeal. I've been thinking about the art style for this game almost since the beginning of May. I want to avoid the 8-bit pixelated look that a lot of indie games have. With games like Fez, Spelunky, Bit Trip Runner, Super Crate Box and even Minecraft utilizing a retro-pixelated look, this kind of art style seems almost cliche. I understand that it is a visually appealing, and charming look. I also understand that this style is not as time-demanding of the artist as many other styles, and thus offers an opportunity for the dev to focus on gameplay. However, I want to try something that could have a chance to be more unique in terms of visual appeal.
I started thinking about other games that I have enjoyed in the past that had a unique visual style. One game quickly popped into my mind: N+. That was a game I spent many nights on, and despite its very, very simple style, it looks very smooth and sleek. No need to be pixelated here.
The style is very simple, meaning do-able by one person, and visually clean and appealing. I especially like the 'silhouetted' look of both the main character and the world he/she is in. Although, this poses a problem. One of the things Geometry Wars 2 got very right is its expert use of colour/lighting to co-ordinate the player. The neon-like shapes were very bright against the background, and stood out to me at all times, even when things got hectic. But the neon style was more than just for contrast, the over-abudance of particle effects, glowing edges and warping was something amazing to behold. I want to merge the 'silhouetted' style similar to N+ with the neon glowing edges of Geometry Wars.
Luckily for me, another game I played last summer, Outland, does something similar. Their characters are mostly a black silhouette, but they have glowing tron-like edges all around their bodies to emphasize their features. I really like this art style as it creates a very stylistic look and also merges the concepts I talked about above.
I think I can actually pull something like this off. Since I'm not doing a platformer, and therefore don't have to create all sorts of tiles for the world and many other extra details, I can probably get away with having this type of art style in my game. Coupled with the fact that I don't actually have to worry about making realistic textures, I think that this is definitely do-able for me. I still want to create 3D models for my characters as in Outland, but I want to avoid creating humanoid characters. These characters usually take much longer to model, and if I am going to be creating humanoid characters, they have to be rigged and animated. Otherwise they'll just be in one pose the entire game, and that won't make any sense. I want to avoid this in the interest of time, as this will require a pretty hefty investment on my part.
So what kind of characters am I going to have in my game? For reasons that are completely random, I decided that my main enemies in the game are going to be wasps, bees, hornets and other flying insects. Perhaps I was inspired by the current season, as there are many of these flying about in the summer. Regardless, I think this is an interesting theme that ties all the enemies together. In Geometry Wars, it was geometric shapes, in my game, it is going to be ferocious flying insects. Coupled with a silhouetted, tron-like art style, I think this game has the potential to look pretty amazing. I'm hoping I can at least mock-up an example enemy for my next post. This also lets me not worry about animating/rigging the characters, as the only parts that move are the wings, which can be just a simple 'wing buzzing' particle system. Even if I do plan on moving parts of an enemy (like their legs, or antennae) putting in effort to rig an insect will most likely be much less than that of a person. This way I don't have to worry about proper spine rigging, obsessing over painting weights correctly (especially in places like armpits, hips, elbows and knees) and many other nuances that come with rigging a humanoid character. Worst case scenario, I can just model each part separately and move it around in a script.
In terms of the player, I imagined them to be a flying plant of sorts. I don't have a concrete image in my head at the moment, and I'm going to have to flesh it out. The player will follow the same art style though, although they will be more detailed than the enemies.
Progress
I've finished 7 out of the 8 weapons that I need, and re-structured some of my weapon/projectile code to be more robust and generic. Before I was needlessly repeating lots of code in each weapon, and realized that some weapons have a similar functionality underneath the hood. I've made a separate launcher class that inherits from the base weapon class, and with both that and other improvements, I have substantially decreased the amount of time and effort it takes me to implement a weapon.
Below are 7 descriptions of the weapons I have coded so far. I was originally going to upload screenshots, but since there are no visuals yet, it would just be a bunch of spheres and cubes. With that being said, I think they would just confuse more than clarify.
Spine Shooter
This weapon is pretty standard as far as top-down shooting games are concerned. It shoots spines out at a relatively moderate pace (10/sec). The shots are fairly quick and a couple of hits from this weapon would destroy a relatively weak, unarmoured enemy. You could actually see this weapon in action from the screenshot I uploaded in the last post. The alternate fire for this weapon shoots out more spines with a faster rate of fire. This weapon is good for eating away at multiple enemies' health, and for crowd control of weaker enemies.
Spore Shooter
The spore shooter launches a tiny ball that grows in size tremendously after being shot. Once the ball is of a sufficient size, the increased drag from the size will halt movement of the projectile. Once it has grown to full size (takes roughly 0.6 of a second) it can be detonated with an alternate fire at no energy cost. However, this ball is very fragile, and most interactions with anything will destroy it. This is a good weapon for setting up traps, and luring your enemies to an explosive demise.
Laser Beam
As the name suggests, this weapon is a laser beam and for the most part, it is self explanatory. The beam is extremely precise, as there is no travel time and it will hit anything you point it at. However, its major disadvantage is that it has to build up to its full power to do any real damage. The beam starts out very small, and every time you hit a target, it will grow in size. Once up to full size, it devastates its target. The beam can be overloaded with an alternate fire, which will cause an explosion at the current impact point of the beam. The explosion's radius and damage depend on how large the beam is. This weapon is excellent at dealing damage to a single large, well armoured enemy.
Wingblades
This weapon spawns a bunch of blades in a small area in front of the player's shooting direction. These blades will continually slice enemies for a small amount of damage, and also push them back with each slice. This weapon's alternate fire will slice everything in a medium proximity of the player. This is great for 'snow plowing' enemies, and use it as a form of up-close crowd control.
Hive Spawner
This weapon does not work like traditional weapons, rather, the player shoots with the alternate fire. The alternate fire releases a small projectile that can be steered around. All shots fired are steered by the player's shooting direction, so the chosen location for releasing the shot is key. Multiple shots fired at different positions can create a moving 'wall' of projectiles, essentially acting as a moving minefield. Great for getting behind the front line of enemies and flank their weaker enemies from further away or attack around corners.
Spike Shot
This weapon behaves similarly to the spine shooter, but it acts more like a sniper weapon. This weapon fires 1 long projectile that is incredibly fast. This projectile can over-penetrate and hit multiple enemies in one shot. It also has a chance of sticking into an enemy rather than bouncing off when completely deflected by armour. Pressing alternate fire will detonate the projectile, but instead of an explosion, it launches several spines out in all directions. However fire rate is extremely slow, so using it in situations where enemies are in a 'single line' formation is preferred.
Snare Shot
The snare shot is meant to entrap enemies by creating a barrier between the player and the enemies. The snare shot launches webs of semi-rigid material that slows down and damages anyone that tries to pass through. The weapon's alternate fire increases the mass of all current webs so that they are much harder to pass through. This weapon is great for setting up a trap so that you can get a better shot with other weapons.
And with that, I think I've explained 7 out of the 8 weapons I plan on having in the game. Next post will most likely contain the final weapon, and more about the modifiers and how they work.
I've been trying to keep myself organized using Trello, a project management software/website. Trello uses 'cards' and columns to keep projects organized. Cards are supposed to represents the various tasks that need to be done to keep the project moving, and columns help categorize the cards. Although this software is supposed to be used for team projects, with the whole point focusing on communicating project status information to other team members, I am still using this even if I am the only one on the team. Laying out tasks in this way helps me keep the bigger picture in mind, and hopefully prevents me from increasing the scope. Besides, maybe I will convince someone to help me out with the game, and if they accept, I can quickly get them up to speed using this site. Constantly shifting tasks toward the 'done' pile also feels nice, and sort of validates my accomplishments, however small. This gives me more motivation to keep hacking away at the game code, as I see tangible progress of what I've accomplished.
The above picture is kind of an 'at-a-glance' screenshot of where my project is right now. I have made 6 separate columns to organize my tasks into. The columns are ordered so that tasks in the leftmost column are essentially 0% complete, and as they keep on moving to the right, they eventually get 100% done. Right now, there are a lot of tasks in the leftmost column, for obvious reasons. I like to list tasks there that eventually need to be done to get an idea of what kind of scope I'm dealing with. This column also reminds me what I need to get done in order to have a complete game, in case I get sidetracked into implementing some obscure feature for weeks on end.
Each task is also labeled using colour to identify what type of task it is. Right now, tasks tagged with blue are programming tasks, and are the most important (as you can see, a lot of blue tasks have already been started on). Art, UI and Design have Red, Yellow and Orange respectively. Some tasks can overlap in terms of type, and therefore can have multiple colours.
Art Style and Direction
As I've mentioned in my last post, I wanted to convey what I want my game to look like in terms of visual appeal. I've been thinking about the art style for this game almost since the beginning of May. I want to avoid the 8-bit pixelated look that a lot of indie games have. With games like Fez, Spelunky, Bit Trip Runner, Super Crate Box and even Minecraft utilizing a retro-pixelated look, this kind of art style seems almost cliche. I understand that it is a visually appealing, and charming look. I also understand that this style is not as time-demanding of the artist as many other styles, and thus offers an opportunity for the dev to focus on gameplay. However, I want to try something that could have a chance to be more unique in terms of visual appeal.
I started thinking about other games that I have enjoyed in the past that had a unique visual style. One game quickly popped into my mind: N+. That was a game I spent many nights on, and despite its very, very simple style, it looks very smooth and sleek. No need to be pixelated here.
The style is very simple, meaning do-able by one person, and visually clean and appealing. I especially like the 'silhouetted' look of both the main character and the world he/she is in. Although, this poses a problem. One of the things Geometry Wars 2 got very right is its expert use of colour/lighting to co-ordinate the player. The neon-like shapes were very bright against the background, and stood out to me at all times, even when things got hectic. But the neon style was more than just for contrast, the over-abudance of particle effects, glowing edges and warping was something amazing to behold. I want to merge the 'silhouetted' style similar to N+ with the neon glowing edges of Geometry Wars.
Luckily for me, another game I played last summer, Outland, does something similar. Their characters are mostly a black silhouette, but they have glowing tron-like edges all around their bodies to emphasize their features. I really like this art style as it creates a very stylistic look and also merges the concepts I talked about above.
I think I can actually pull something like this off. Since I'm not doing a platformer, and therefore don't have to create all sorts of tiles for the world and many other extra details, I can probably get away with having this type of art style in my game. Coupled with the fact that I don't actually have to worry about making realistic textures, I think that this is definitely do-able for me. I still want to create 3D models for my characters as in Outland, but I want to avoid creating humanoid characters. These characters usually take much longer to model, and if I am going to be creating humanoid characters, they have to be rigged and animated. Otherwise they'll just be in one pose the entire game, and that won't make any sense. I want to avoid this in the interest of time, as this will require a pretty hefty investment on my part.
So what kind of characters am I going to have in my game? For reasons that are completely random, I decided that my main enemies in the game are going to be wasps, bees, hornets and other flying insects. Perhaps I was inspired by the current season, as there are many of these flying about in the summer. Regardless, I think this is an interesting theme that ties all the enemies together. In Geometry Wars, it was geometric shapes, in my game, it is going to be ferocious flying insects. Coupled with a silhouetted, tron-like art style, I think this game has the potential to look pretty amazing. I'm hoping I can at least mock-up an example enemy for my next post. This also lets me not worry about animating/rigging the characters, as the only parts that move are the wings, which can be just a simple 'wing buzzing' particle system. Even if I do plan on moving parts of an enemy (like their legs, or antennae) putting in effort to rig an insect will most likely be much less than that of a person. This way I don't have to worry about proper spine rigging, obsessing over painting weights correctly (especially in places like armpits, hips, elbows and knees) and many other nuances that come with rigging a humanoid character. Worst case scenario, I can just model each part separately and move it around in a script.
In terms of the player, I imagined them to be a flying plant of sorts. I don't have a concrete image in my head at the moment, and I'm going to have to flesh it out. The player will follow the same art style though, although they will be more detailed than the enemies.
Progress
I've finished 7 out of the 8 weapons that I need, and re-structured some of my weapon/projectile code to be more robust and generic. Before I was needlessly repeating lots of code in each weapon, and realized that some weapons have a similar functionality underneath the hood. I've made a separate launcher class that inherits from the base weapon class, and with both that and other improvements, I have substantially decreased the amount of time and effort it takes me to implement a weapon.
Below are 7 descriptions of the weapons I have coded so far. I was originally going to upload screenshots, but since there are no visuals yet, it would just be a bunch of spheres and cubes. With that being said, I think they would just confuse more than clarify.
Spine Shooter
This weapon is pretty standard as far as top-down shooting games are concerned. It shoots spines out at a relatively moderate pace (10/sec). The shots are fairly quick and a couple of hits from this weapon would destroy a relatively weak, unarmoured enemy. You could actually see this weapon in action from the screenshot I uploaded in the last post. The alternate fire for this weapon shoots out more spines with a faster rate of fire. This weapon is good for eating away at multiple enemies' health, and for crowd control of weaker enemies.
Spore Shooter
The spore shooter launches a tiny ball that grows in size tremendously after being shot. Once the ball is of a sufficient size, the increased drag from the size will halt movement of the projectile. Once it has grown to full size (takes roughly 0.6 of a second) it can be detonated with an alternate fire at no energy cost. However, this ball is very fragile, and most interactions with anything will destroy it. This is a good weapon for setting up traps, and luring your enemies to an explosive demise.
Laser Beam
As the name suggests, this weapon is a laser beam and for the most part, it is self explanatory. The beam is extremely precise, as there is no travel time and it will hit anything you point it at. However, its major disadvantage is that it has to build up to its full power to do any real damage. The beam starts out very small, and every time you hit a target, it will grow in size. Once up to full size, it devastates its target. The beam can be overloaded with an alternate fire, which will cause an explosion at the current impact point of the beam. The explosion's radius and damage depend on how large the beam is. This weapon is excellent at dealing damage to a single large, well armoured enemy.
Wingblades
This weapon spawns a bunch of blades in a small area in front of the player's shooting direction. These blades will continually slice enemies for a small amount of damage, and also push them back with each slice. This weapon's alternate fire will slice everything in a medium proximity of the player. This is great for 'snow plowing' enemies, and use it as a form of up-close crowd control.
Hive Spawner
This weapon does not work like traditional weapons, rather, the player shoots with the alternate fire. The alternate fire releases a small projectile that can be steered around. All shots fired are steered by the player's shooting direction, so the chosen location for releasing the shot is key. Multiple shots fired at different positions can create a moving 'wall' of projectiles, essentially acting as a moving minefield. Great for getting behind the front line of enemies and flank their weaker enemies from further away or attack around corners.
Spike Shot
This weapon behaves similarly to the spine shooter, but it acts more like a sniper weapon. This weapon fires 1 long projectile that is incredibly fast. This projectile can over-penetrate and hit multiple enemies in one shot. It also has a chance of sticking into an enemy rather than bouncing off when completely deflected by armour. Pressing alternate fire will detonate the projectile, but instead of an explosion, it launches several spines out in all directions. However fire rate is extremely slow, so using it in situations where enemies are in a 'single line' formation is preferred.
Snare Shot
The snare shot is meant to entrap enemies by creating a barrier between the player and the enemies. The snare shot launches webs of semi-rigid material that slows down and damages anyone that tries to pass through. The weapon's alternate fire increases the mass of all current webs so that they are much harder to pass through. This weapon is great for setting up a trap so that you can get a better shot with other weapons.
And with that, I think I've explained 7 out of the 8 weapons I plan on having in the game. Next post will most likely contain the final weapon, and more about the modifiers and how they work.
Saturday, August 3, 2013
About the project
Intro
This is a personal project of mine that I hope to build in the next few months. This blog will act as my personal archive for documentation on the game, but if it gains some followers, that would be awesome too! If anyone finds this blog and/or my idea at least semi-interesting, feel free to leave a comment.
The core concept of the game takes its foundations as a dual-analog shooter. This is where players use one thumb-stick to move, and the other thumb-stick to fire their weapon at various incoming enemies/obstacles. It is a very simple concept, and something I found do-able under a limited (read: no) budget, a one man development 'team', and a relatively short development time. The codename for the project takes after Sony's original dualshock controller for the PS1. This controller was amongst the first of its kind to have 2 analog sticks, and arguably, was one of the first to do it right. I find this a fitting name for a project about a dual-analog shooter, paying homage to a controller that makes this type of game possible.
Inspirations
My main inspiration for the project has been the XBLA title Geometry Wars 2. It is a very addictive, colourful game that is an absolute blast to play. The concept for the game is very simple: shoot colourful shapes, and avoid touching them at all costs. But this simple concept goes a long way. Each different shape behaves in its own unique way, and expert use of colour coordination reinforces the unique aspect of each different enemy. But don't just take my word for it, watch some gameplay below:
An honorable mention should be the game 'I MAED A GAM3 W1TH ZOMBIES 1N IT!!!1'. This game shares mechanics similar to Geometry Wars, but offers powerups, different weapons, zombies and many other things along the way. I admit, I only played the trial version of the game, so I haven't experienced some of the powerups/weapons firsthand. However, seeing the gameplay is enough to asses that the game has a little bit more depth in terms of interactivity than Geometry Wars. Gameplay video below:
Despite my praise towards Geometry Wars, I feel like there were a few things they could have improved on. One of the biggest things was that the action got too much to handle too fast. While I understand that the game was supposed to be 'tough' and reminiscent of the old-school impossible challenge of traditional arcade games, I still feel like the game should have stayed in a less intense state before really making things impossible. It comes to a point where there is so much stuff happening on the screen that it obscures your vision, and therefore, you don't even know where you are on the screen. This, in turn, causes you to simply die immediately, as there is no health to act as a buffer against your mistakes. I feel like forcing the player to die like this to end the game just evokes feelings of frustration and hopelessness towards improving your skills. I feel like Geometry Wars also could have benefited from having powerups and different weapons, similar to the honorable mention game (I guess this is my abbreviation to the long silly title). Even though there are a great variety of enemies, the way you could dispatch them didn't change, and eventually got a little boring/frustrating at times. The default weapon was sometimes not enough, as there were just too many enemies from too many sides.
I'm taking these criticisms to heart when making my game. I feel like slowing down the pace and also having a slower rate-of change towards intensity would give players more time to get themselves together. I'm going to make the pace ramp up much slower, and more incrementally, rather than exponentially (as Geometry Wars seems to do). This extra time would allow players to learn more mechanics rather than just moving and shooting. Now that some learning space has been created for players, this allows me to experiment with a few simple, extra mechanics that can add depth to a dual-analog shooter.
Game Mechanics
One main thing that is different from both Geometry Wars and the 'honorable mention' is that I want to introduce health and armour into the game. This allows the player some room to breathe by making mistakes not as punishing, but this also goes the same for enemies. Enemies won't be insta-killed by most weapons, so the player will have to work harder for their kills. Armour works differently for enemies and players. Enemies will have a value from 0-100, indicating their armour level. When enemies that have armour are damaged by any source, the armour has a chance to deflect all damage depending on the level. So if an enemy has 40 armour, it has a 40% chance to deflect all damage. If the damage does go through, it is reduced by the armour level's amount. For example, if an enemy has 40 armour and was damaged, it reduces that damage by 40%. I'm debating on letting armour deteriorate when it completely deflects damage, but that is something I'm going to have to experiment with after I have my first play test. As for the player, they don't have armour that ranges from 1-100, rather, they can summon up a barrier in their chosen direction by holding a button. This barrier automatically deflects any projectile or enemy away from the player, albeit being relatively small, so aiming is required to block enemies/projectiles.
Another resource I'm adding is an energy meter that the player has to keep track of. This energy meter is used up by special mechanics (coming up in the next section) that the player can execute. Energy re-charges itself quickly after a short delay so the player can quickly use it again. Energy consumption is determined by whatever ability the player has chosen, as they all have different energy requirements.
Special Abilities
Boost - By holding down a button/trigger, the player can get extra speed for a short time. Depletes energy very quickly.
Block - The player can block enemies from a specific direction by simultaneously holding the direction they want to block with the shooting thumb-stick, and holding down the block button. Depletes energy at a moderate pace
Alternate Fire - By pressing a button, the player can execute the alternate fire for a weapon. Energy consumption varies by weapon.
Grapple/Vine shot - The player can shoot a special shot in their direction of movement. I haven't quite figured out what this will do yet, but I know I want to have some sort of 'always-available' mechanic to the player, just in case they find that their current weapons are not up to the task. Energy consumption is low.
Weapons
A player can have two weapons in their 'inventory' at any time. The player has 2 slots for weapons, and can switch between them at any time. I don't know how these weapons will come into the hands of the player yet. I'm probably going to flesh this out more when I get to creating the enemies and levels.
Modifiers
I want to have certain abilities the player can pick up and use that modify the behavior of the player's current weapon. The player will have 2 slots for modifiers and can switch between them at will. For example, if the player has a laser beam in their current weapon slot, and also has a 'Fire' modifier, then their laser beam will set enemies on fire. They can then switch to their other modifier, let's say 'Force', and their beam will now push enemies away and also doing more damage.
I have a complete list of weapons and modifiers I want to add to the game, but that will be saved for another post.
My Current Progress
The engine I'm using is the free version of Unity. I already have experience in this engine when I built Magic Duel, and a bunch of other assignments, games for class, and other personal projects. I'm also using Adobe Photoshop CS2, as it's free and available to download on their site (which is awesome news for me).
Anyways, what I have implemented so far has all been code. No art assets or any sort of visuals, so any screenshots are going to be just cubes shooting at other cubes. Now that I have the disclaimer out of the way, voila:
This is a personal project of mine that I hope to build in the next few months. This blog will act as my personal archive for documentation on the game, but if it gains some followers, that would be awesome too! If anyone finds this blog and/or my idea at least semi-interesting, feel free to leave a comment.
The core concept of the game takes its foundations as a dual-analog shooter. This is where players use one thumb-stick to move, and the other thumb-stick to fire their weapon at various incoming enemies/obstacles. It is a very simple concept, and something I found do-able under a limited (read: no) budget, a one man development 'team', and a relatively short development time. The codename for the project takes after Sony's original dualshock controller for the PS1. This controller was amongst the first of its kind to have 2 analog sticks, and arguably, was one of the first to do it right. I find this a fitting name for a project about a dual-analog shooter, paying homage to a controller that makes this type of game possible.
Inspirations
My main inspiration for the project has been the XBLA title Geometry Wars 2. It is a very addictive, colourful game that is an absolute blast to play. The concept for the game is very simple: shoot colourful shapes, and avoid touching them at all costs. But this simple concept goes a long way. Each different shape behaves in its own unique way, and expert use of colour coordination reinforces the unique aspect of each different enemy. But don't just take my word for it, watch some gameplay below:
Video not made by me.
Video link: http://www.youtube.com/watch?v=zdL-l10XJ68
An honorable mention should be the game 'I MAED A GAM3 W1TH ZOMBIES 1N IT!!!1'. This game shares mechanics similar to Geometry Wars, but offers powerups, different weapons, zombies and many other things along the way. I admit, I only played the trial version of the game, so I haven't experienced some of the powerups/weapons firsthand. However, seeing the gameplay is enough to asses that the game has a little bit more depth in terms of interactivity than Geometry Wars. Gameplay video below:
Again, video not made by me
Video link: http://www.youtube.com/watch?v=v5T6qenbdUc
Despite my praise towards Geometry Wars, I feel like there were a few things they could have improved on. One of the biggest things was that the action got too much to handle too fast. While I understand that the game was supposed to be 'tough' and reminiscent of the old-school impossible challenge of traditional arcade games, I still feel like the game should have stayed in a less intense state before really making things impossible. It comes to a point where there is so much stuff happening on the screen that it obscures your vision, and therefore, you don't even know where you are on the screen. This, in turn, causes you to simply die immediately, as there is no health to act as a buffer against your mistakes. I feel like forcing the player to die like this to end the game just evokes feelings of frustration and hopelessness towards improving your skills. I feel like Geometry Wars also could have benefited from having powerups and different weapons, similar to the honorable mention game (I guess this is my abbreviation to the long silly title). Even though there are a great variety of enemies, the way you could dispatch them didn't change, and eventually got a little boring/frustrating at times. The default weapon was sometimes not enough, as there were just too many enemies from too many sides.
I'm taking these criticisms to heart when making my game. I feel like slowing down the pace and also having a slower rate-of change towards intensity would give players more time to get themselves together. I'm going to make the pace ramp up much slower, and more incrementally, rather than exponentially (as Geometry Wars seems to do). This extra time would allow players to learn more mechanics rather than just moving and shooting. Now that some learning space has been created for players, this allows me to experiment with a few simple, extra mechanics that can add depth to a dual-analog shooter.
Game Mechanics
One main thing that is different from both Geometry Wars and the 'honorable mention' is that I want to introduce health and armour into the game. This allows the player some room to breathe by making mistakes not as punishing, but this also goes the same for enemies. Enemies won't be insta-killed by most weapons, so the player will have to work harder for their kills. Armour works differently for enemies and players. Enemies will have a value from 0-100, indicating their armour level. When enemies that have armour are damaged by any source, the armour has a chance to deflect all damage depending on the level. So if an enemy has 40 armour, it has a 40% chance to deflect all damage. If the damage does go through, it is reduced by the armour level's amount. For example, if an enemy has 40 armour and was damaged, it reduces that damage by 40%. I'm debating on letting armour deteriorate when it completely deflects damage, but that is something I'm going to have to experiment with after I have my first play test. As for the player, they don't have armour that ranges from 1-100, rather, they can summon up a barrier in their chosen direction by holding a button. This barrier automatically deflects any projectile or enemy away from the player, albeit being relatively small, so aiming is required to block enemies/projectiles.
Another resource I'm adding is an energy meter that the player has to keep track of. This energy meter is used up by special mechanics (coming up in the next section) that the player can execute. Energy re-charges itself quickly after a short delay so the player can quickly use it again. Energy consumption is determined by whatever ability the player has chosen, as they all have different energy requirements.
Special Abilities
Boost - By holding down a button/trigger, the player can get extra speed for a short time. Depletes energy very quickly.
Block - The player can block enemies from a specific direction by simultaneously holding the direction they want to block with the shooting thumb-stick, and holding down the block button. Depletes energy at a moderate pace
Alternate Fire - By pressing a button, the player can execute the alternate fire for a weapon. Energy consumption varies by weapon.
Grapple/Vine shot - The player can shoot a special shot in their direction of movement. I haven't quite figured out what this will do yet, but I know I want to have some sort of 'always-available' mechanic to the player, just in case they find that their current weapons are not up to the task. Energy consumption is low.
Weapons
A player can have two weapons in their 'inventory' at any time. The player has 2 slots for weapons, and can switch between them at any time. I don't know how these weapons will come into the hands of the player yet. I'm probably going to flesh this out more when I get to creating the enemies and levels.
Modifiers
I want to have certain abilities the player can pick up and use that modify the behavior of the player's current weapon. The player will have 2 slots for modifiers and can switch between them at will. For example, if the player has a laser beam in their current weapon slot, and also has a 'Fire' modifier, then their laser beam will set enemies on fire. They can then switch to their other modifier, let's say 'Force', and their beam will now push enemies away and also doing more damage.
I have a complete list of weapons and modifiers I want to add to the game, but that will be saved for another post.
My Current Progress
The engine I'm using is the free version of Unity. I already have experience in this engine when I built Magic Duel, and a bunch of other assignments, games for class, and other personal projects. I'm also using Adobe Photoshop CS2, as it's free and available to download on their site (which is awesome news for me).
Anyways, what I have implemented so far has all been code. No art assets or any sort of visuals, so any screenshots are going to be just cubes shooting at other cubes. Now that I have the disclaimer out of the way, voila:
 |
| May not look impressive, but every game starts out like this |
In case you can't tell what that screenshot is about, the player is the blue cube, and the enemies are the red cubes. The cyan rectangles are shots fired by the player. With each successful hit, the shot 'sticks' into its target, as if it penetrated its armour. If the shot has been completely deflected, it bounces off the enemy.
I actually have quite a few things implemented so far. All of the things regarding player movement and special mechanics are implemented. This means you can move around, shoot in any direction you want, boost, block etc. The weapon system and the ability to switch between weapons have been implemented. I have 3 weapons done already, they are functional and do the appropriate amount of damage to enemies and have alternate fires coded as well. The ability to switch between modifiers has been implemented, although I don't actually have any modifiers coded yet. A base enemy class has been made, and the ability to push around/damage enemies is already coded, with the proper armour mechanics.
That being said, I still have a long way to go. I am personally excited to start making particle systems for both the player, weapons and enemies. Considering I did a pretty awesome job making particle effects in Magic Duel, I think this is going to be the next level for me.
Controls
Below is the control scheme for both the 360 controller, and PC. These controls have already been implemented into the game.
Xbox 360 Controller
Left Stick - move
Right Stick - shoot
Left Trigger - boost
Right Trigger - block (need to be also shooting)
Left Bumper - grapple/vine shot
Right Bumper - weapon alternate fire
A - weapon slot 1
X - weapon slot 2
B - modifier slot 1
Y - modifier slot 2
I tried to group actions together by sides. So left side of the controller relates everything to movement. Both boost and grapple/vine shot (this uses movement as a direction of fire) are on the left side. The right side relates everything to the shooting action. Blocking uses the shooting direction to spawn a barrier, and alternate fire is self explanatory.
Mouse & Keyboard
W - move up
S - move down
A - move left
D - move right
Q - switch weapons
E - switch modifiers
F or Middle Mouse Button - Alternate fire
Left Mouse Button - shoot (direction is chosen based on mouse position)
Right Mouse Button - block (direction is chosen based on mouse position)
Left Shift - Boost
Space - grapple/vine shot
Conclusion
Anyways, if anybody was actually reading this, thank you for sticking around for this long! I hope to post updates regularly and eventually release the game at some point. In my next post, I'll be talking about what kind of artistic direction I want to take with this game, and some project management stuff that I'm trying to do to keep myself organized. I'll periodically upload photos of the 'project-at-a-glance' from the software I'm using.
Thanks for reading.
Subscribe to:
Posts (Atom)