I was making a dual gun fps up until a few days ago - the complicated controls messed with the lightning fast gameplay i wanted, so i changed it.
Ever since I set eyes on a dual stick controller I had this game in mind. I mean, this goes way back to the first Playstation analog joystick controller. It's just that at the time, there were so many things that weren't in place. (but more on that later)
Whenever I obtain a new controller - be it a drawing tablet, a multitouch screen, a set of analog footpedals, a 3Dconnexion space navigator, a MIDI fader board, a flightstick, a head-tracker, an eye-movement tracker -- I feel there's an experience to be enabled by that controller.
There's a reason that we don't drive cars with a mouse-and-keyboard interface or a multitouch screen. If we did, we'd get into a lot more accidents! Also, you wouldn't try to fly an airplane with a wiimote, would you?
I feel that this is a bit of a problem -- that sometimes devs see a new controller like a kinect and are in such a hurry to make a game for it that they forget what kind of experiences that the controller offers, enables, suggests and discourages!
I keep testing, testing, testing my controller setup for Akimbo, not just to get used to it, but I'm acutely aware of problems that arise when I get myself into a panic situation. I use the controls for a long period of time to see if there's fatigue building up, and I also keep myself aware of unpressable combinations.
But to bring the conversation back to 'things that weren't in place at the time...'
Game Maker Studio only recently added in native XBOX controller support. Then there's the XBOX controller and its pressure sensitive triggers (that the PS2 Controller has always had, it even has pressure sensitive face buttons!). Then there's all these third-party companies that offer marketing and storefronting for indie devs.
It kind of worked out that I was sidetracked from making games for over a decade by the VFX and digital comics industry -- If I were trying to make games in the last 10 years I would have probably have met great frustration and have lost my passion by now. About now I feel like I've amassed a great deal of skills that are just looking for an application and that I'm returning to my long forgotten love of game development.
Wow. I love you your game. It looks amazing.
Making something look good comes down to a huge combination of different factors. One of them is an analytical and scientific mindset.
For instance, when I designed the flamethrower weapon, I designed it against all the other games that implemented flamethrowers that I had played in the past, and designed it along what I had learned from video footage of actual flamethrowers posted on the internet (Thanks YouTube!).
Most times I see a flamethrower in a game, enemies are treated as if they are highly flammable pieces of kindling that ignite at the touch of a flame and take damage over time until the amount of 'flames' on them runs out.
In my game, I treat the flamethrower as a flaming gasoline thrower. Flamethrowers often have a liquid ammo tank and a tank of propellant gas. The propellant gas is introduced into the top of the liquid ammo tank and forces the liquid ammo downwards through the gun. The trigger simply acts as a valve to let the liquid out.
So I use the trigger pressure of the controller to specify the rate and speed at which the burning liquid is ejected and the ammunition is consumed.
I treat also enemies as if they aren't flammable. It's the burning liquid that is flammable and sticky. It sticks to anything it contacts and it burns it until it is completely evaporated.
The game has to track individual drops of burning liquid for collision and for lifespan. The droplet entities emit non-dynamic particles that are purely cosmetic. I use a 3-colour ramp of blue, bright warm yellow and orange mapped to particle lifespans. There's randomization of particle size. There's breakup and spreading of the stream as it cascades through the air.
I think I'd like to revisit the 'heat buildup' system for the flamethrower and instead, treat it as 'propellant cooldown'. If you've ever used an aerosol duster to clean your computer, you'd know that as you shoot it, the can gets chilly enough to make frost and the pressure of the duster gas that is shot out gets really anemic and weak.
This is because at high pressures, the propellant stays as a liquid. As you squeeze the trigger, the valve is opened and the pressure is released - and the propellant begins to boil - turning from liquid to gas and suddenly taking up a much larger volume of space.
Let's say, hypothetically, that a cubic centimetre of liquid propellant would take up 500 cubic centimetres of gas. That means that the heat contained within a single cubic centimetre of liquid propellant would suddenly be spread out to an area 500 times the original. That means the temperature(or intensity of heat) would of a single cubic centimetre of recently expanded gaseous propellant would be 1/500th of the compressed liquid propellant.
So it would get really, really cold.
But cold things contract, right? So the chilling would have a secondary effect on the expanded gas, causing it to contract and to reduce the overall expansion of that gas, reducing the pressure and reducing the rate of boiling.
So if you fire the flamethrower too rapidly, your
propellant undergoes chilling and pressure drop and the firey liquid doesn't get thrown as far.That took up almost half a page to explain and this is the simplified version! It's a lot of factors, factors and more factors that I implement into the game to get this sort of look. One of my old (and favourite) art mentors called me obsessive, which I took as high praise. :D You have to have a deep understanding of things, and to do that, you have to want to deeply understand things.
Looks good so far. How many types of enemies are you planning to add, and what kind of varied attacks will they have?
I'd like to come up with a lot of different robot enemies for arcade mode. So I came up with several lists of traits for things like movement methods, offensive and defensive payloads. This means that every time I want to come up with a different robot, I can pick a few traits from each list and come up with a robot, and then decide on its role in combat and then design an AI that suits the tools that it has at its disposal.
This looks really smooth. I can't get a sense from the video of how it's controlled, though.
I'll record another picture-in-picture video showing the game controller soon.
How is the arcade mode going to operate? Score attack? Survival?
I think I'll combine time into the score so the longer you survive, the more points you get. Also, killing things gets you points. Score level will be used to adjust the difficulty factor, so the faster you kill things, the faster your score rises, the faster the difficulty ramps up, which means more enemies to kill, more difficult enemies to kill, each providing more and more points which means a higher score and greater difficulty -- it's a feedback loop!
So a person who takes their time and kills things slowly will face a slow difficulty ramp. A person who destroys enemies like a madman will face a steep difficulty ramp. Games can be made to respond the challenge that players present, just as players can respond to the challenges that games present. It's how I'd like my action games to remain engaging no matter how good you get at them.
***
I felt that before I could start making the environment/backgrounds nicer, that I would have to improve the way in which I was handling tile transitions from one material to another.
I decided to go with a layered system where one material sits atop another. In this case, it's just four layers - Grass, Soil, Sand and Rock.
Grass can be found overlapping soil layers. With my system, you'd never find grass overlapping rock or sand layers. There would always be an intermediary material.
Also, my old system used about 20 tiles just to deal with the transition from sand to rock. By simply rotating tiles, I can cut the number of tiles for a transition down to 6, and with the tiling pattern shown in the above sketch, I can easily create an extensible tilesheet.
