Runaway Tank! 2 - Dev Log

[BrooksBishop]

With Aeternum pretty much in the bag, I've been kicking around a few ideas for what to do next. Among the concepts on that list is of course, another shmup, and over the past couple weeks, I think I've gotten to the point where I wouldn't mind showing off a tiny little bit.

I give you: Runaway Tank! 2 --> http://youtu.be/Keajv80zwjE

Aeternum was made very much to be a test bed for a bullet/particle engine, so its design was to have a very minimal scoring system, and to focus more on the bullets themselves for gameplay than anything else. With everything I learned from that experience under my belt, RT2 is instead going to be very much a more Raizing and Yagaya inspired game, though hopefully something I can add my own twists on.

The video is really, really, really early. It's a lot of me throwing together some quick sprite ideas and a junky background to watch scroll and some test bullets. Any or all of it could change long before it's done.

What you can expect:
* Five stages full of tanks and planes and boats and other mecha, all shooting at you.
* Do I even need to mention bullets?
* Lots of secrets. By which I mean lots of little hidden score boosts and other fun bonuses for people who care to find them. And not so much hidden game play altering devices.
* Secrets does mean triggered extra bosses though!
* A medal chain scoring system.
* More rad music by Jesse. This time instead of chip-pop we're thinking more of some epic 80s rock/jpop FM synth tunes. BTW, check out his latest album! http://streetcleaner.bandcamp.com/album/street-cleaner
* PC release for sure. We'll see what happens with the Xbox360/XboxOne, although I'm pretty pissed at how Microsoft treats indies still. I do have a Sony dev account...
* Game runs in a native resolution of 720x960, so it's designed to be played vertical on an HDTV, but should also look pretty damn sweet full screen on an old 4:3 CRT rotated. Will have support for horizontal play too.

I can't say for sure if this is definitely the next thing I'll be doing. But it's very much been on my mind the last few weeks. We'll see where the inspiration takes me!

[mice]

Yes! Will be awesomeness! Looking forward to it.

Reminds me of my attempt at a tank shmup, had helpers too:
http://www.youtube.com/watch?v=p2apoISRKS4

[n0rtygames]

Yagaya

Typing late at night is bad mmkay?

Looks good. Please do keep us informed! Is that a ketsui-esque lockon system I spy? I fear we are making very similar games...

[BrooksBishop]

Is that a ketsui-esque lockon system I spy? I fear we are making very similar games...

Only in as much as I finally implemented an "aim at nearest enemy" algorithm. My bullet engine had the capacity for it before, but Aeternum didn't need it so I didn't write it until now. I mostly just wanted to write it so it was available.
Option behavior is another thing I haven't decided at all yet. I'll probably dial it back and do a formation cycle instead of a lock on though.

In general, I get the feeling my game won't be quite as "serious" as yours.

[Cagar]

Is this going to be more of a casual entertainment type of game more than a game for bullet hell scoring maniacs?

[BrooksBishop]

Is this going to be more of a casual entertainment type of game more than a game for bullet hell scoring maniacs?

Like I said, Aeternum was me making a more casual game.
Runaway Tank! 2 is most definitely going to be something for the scoremongers!

[BrooksBishop]

So it's been quite a while since I posted anything about this project. I was actually working on another project, and at the same time migrating my work from C#/DirectX to C++/OpenGL.

But lately I've been thinking about this again, and porting my bullet script and general shmup engine to my C++ framework and thought I would share some of the progress here.
If you follow me on twitter none of this should be new, so if you want more regular updates: https://twitter.com/BrooksBishop !
Some of these are also vines which can't be embedded here so you'll have to click over. Sorry!


Started by constructing the bullet object itself. In my system, bullets are just containers for state data. That is, all the data that describes how a bullet looks and moves at a given point in time.
You can see as well it holds a pointer to a "BulletDefinition" which is all the data for a specific type of bullet that doesn't change. Like which graphic to use, it's radius (size), initial speed and direction, etc.
Finally a bullet holds a tiny stack of script state data, which it holds so it can properly execute scripts.

https://vine.co/v/Ou9iFO755gx
The first step after is to make the bullet manager update all the active bullets every frame giving them motion.
Followed by the first scripts I implemented: Loop, Wait and Fire
Here a single bullet simply loops over a pair of Wait and Fire commands to shoot the red bullets as it travels.


My old scripting engine used a scratch built expression parser to take expression strings (such as "(2*pi)/(rank*16+16)") and turn them into numbers at run time based on available variables.
This time, I'm trying out writing the expressions directly in code using std::function objects. In this case, I am supplying lambda enclosures, defining behavior inline. Although it also means I can use member or static functions to create a sort of library of bullet functionality.

https://vine.co/v/Oz7pTpDY7jT
So the above is a basic script which fires bullets with speed defined as an ellipse.


I wanted to see how many bullets I could push and maintain 60 FPS.
The answer as you can see here is something more than 15,000 scripted bullets. So I think a game designed to have significantly less than around 500 max should be perfectly fine!

Finally, here's a few more tests I did with some basic scripting that I thought were neat looking:

https://twitter.com/BrooksBishop/status ... 4415808514
https://twitter.com/BrooksBishop/status ... 7833559040
https://twitter.com/BrooksBishop/status ... 3488789504
https://twitter.com/BrooksBishop/status ... 9023856640
https://twitter.com/BrooksBishop/status ... 9729878016

[S20-TBL]

Watched the video, good stuff going on in there with the Ketsui style shots and the Raizing medals (I was half wondering if that placeholder road was a procedurally generated spline ).

I actually see some heavy potential for Mercs-style gameplay in there too, if you're willing to go in that direction.

EDIT: D'oh, how could I forget Shock Troopers and Jackal. That overhead tank just screams top down run-n-gun at me.

[Lord Satori]

Too easy to dodge. Needs at least twice as many bullets.

[BrooksBishop]

I've been doing quite a lot of engine programming lately. Specifically I've been working hard on making replays a part of the game from the very beginning. And since this is a definitely planned to be a cross-platform game (Win/Mac/Linux) I'm attempting to see if I can build fully cross-platform replay files as well.

Besides that, here's some progress on visuals:
Exploding tanks: https://twitter.com/BrooksBishop/status ... 2831346688
Gushing fire hydrant: https://twitter.com/BrooksBishop/status ... 8147480576
More exploding tank: https://twitter.com/BrooksBishop/status ... 0476684288

[BrooksBishop]

I've been working on building an actual stage lately, and putting together all the pieces of things I've built.
Here's a snip of how my pixel style is looking so far (the anti-aliased edges will be pixeled over, they're just guides):


But in more substantive news, after much mental deliberation I have come to the conclusion that a ground-based character is not what I want to go with for this particular game after all.

It's one of those weird things that you don't put much thought into as a player, that the vast majority of shmups feature flying vehicles as the playable character. While there is definitely a historical component to this tradition, stemming from the old school "black for space" to save on graphics requirements, I believe now ships are used largely because there are a number of difficult problems to address when it comes to ground vehicles. With ships the sprite is free to fly above everything, including all terrain, enemies, bosses, and effects. With ground vehicles, you have to worry about things like ground collision which vastly affect gameplay style, visual layering problems which affect player vehicle visibility (namely it's a bad, bad thing to hide the player), and maneuverability around large enemies (can't really circle around a large boss in a ground vehicle).

There are definitely some games that have made ground based players work. Especially in the "commando warfare" genre. But those often are not auto-scrolling. In the realm of shmups, Guwange is definitely a standout that made the formula work. But there they made design decisions that in this case are not what I envision for the game I want to make, such as terrain collision, and some aspects of boss design.

So while I definitely love the idea of a tank-based manic shooter, I think for now in this case I'll be switching the game over to a more standard flying player vehicle set. This will definitely ease the problems I've been having trying to figure out stage and enemy design, and hopefully accelerate development!

[mice]

I have come to the conclusion that a ground-based character is not what I want to go with...

Pretend I didn't hear that. It's an awesome idea.
And the pixels looks awesome!

[BrooksBishop]

Perhaps if I were a much more experienced developer I could figure out how to make it work. But for now the impracticality of it is just killing me.

Anyway, updating with more pixels!


Here with the sidewalk you can see I often work on pixel art by finding a palette in another image I like, drawing using that, then sometime later after I'm done drawing I'll play with the colors themselves so things look better.

[S20-TBL]

So while I definitely love the idea of a tank-based manic shooter, I think for now in this case I'll be switching the game over to a more standard flying player vehicle set. This will definitely ease the problems I've been having trying to figure out stage and enemy design, and hopefully accelerate development!

Too bad, I was looking forward to the tank shooter. Although I understand your concerns about not wanting to complicate the development process any more than you would like, and you did mention that autoscrolling is what you wanted instead of a Commando/Ikari type game, so I respect that decision.

Pixels look great.

[Lord Satori]

I don't have much experience in game development so take it with a grain of salt I suppose, but it seems like a cop-out to me. The issues about the tank you complained about could be easily written off or worked around somehow. Hell, the ground vehicle doesn't even need to be a tank. It could be someone in a bike, with somebody else in a sidecar that has a turret for the gun, or something like that. Which would justify more maneuverability, and it would solve that "circling around large bosses" problem. Collision is a different issue, but I'm pretty sure we've all played shmups with collidable scenery before. That's not to say there isn't a way to avoid it, I'm just saying it wouldn't be detrimental if it were a factor in my opinion at least.

I'm not trying to be rude or anything, it just seems to me like there was no attempt to work around those issues before drastically changing the entire game like that. I suppose you're free to ignore all this and write me off as dumb ol' Lord Satori again, I'm just saying that it'll take a lot more to get people interested if all they see is yet another plane shmup. Of course the people at shmups forum will be, but still.

[ciox]

Flying vehicle set isn't so bad if you can fly a hover tank, though it might be too high-tech for your setting, here's some cool enemy hover tanks in Under Defeat: https://www.youtube.com/watch?v=rORTOq2eM9I#t=20m50s

[tiaoferreira]

Seeing that "bullet hell's scene, I remember GANDALF: "YOU CAN NOT PASS!" HAHAHAHHAHA!

[Lord Satori]

*SHALL

[tiaoferreira]

In BRAZILIAN version is "YOU CAN NOT PASS".