Tetsuishi

[gamingjustin]

Tetsuishi is a project I'm working on to teach myself how to design and complete a game from start to finish. I decided to make an STG because I've had a long history playing them, and I feel they can be fun without the need for complex physics or computation. This is my first build of the game where everything works smoothly. For now, the game is just a short looping stage to test that everything is functional, but I want to share it to help motivate myself to finish it. And I would be glad to hear any and all feedback-- criticisms, gamemaker tips, anything.

Dev tools:
GameMaker 8.1 for putting it all together
ProMotion for graphics
SFXR for original sounds with other sound ripped from other STGs.

DOWNLOAD: https://mega.co.nz/#!EIEgUBCT!c39851awU ... pkrtINdIdg

SCREENSHOTS kindly hosted by fellow shmuppers:

As it is, the game runs in 720x960 in a window (f4 to play with black background) and only uses keyboard controls: Z, X, directional keys, and 1 and 2 toggle scanlines and brightness adjustment. Bombs look cool but do nothing right now

My goal is to essentially reverse engineer the aesthetics and mechanics of my favorite STGs-- mostly "old-school" ones made by Toaplan, Seibu Kaihatsu, Konami and Irem-- and incorporate a simple but original scoring system based on survival and skilled play.

Here's how the various systems will work in the full game:

POWER-UPS
----------
Both weapons can be powered up twice by collecting Ps. You need 4 to increase your weapon power one level. Upon death, you start with the basic laser, but you retain any Ps in stock. This way, if you're stuck at a section you can at least snatch some Ps until you finally have enough to increase your laser power and get past a tricky section. This system was lifted straight out of Toaplan games like Tatsujin and Same! Same! Same!

All enemies that drop power-ups can be killed in a special way to instead drop a Force pick-up. Your ship gains a shiny outline and your laser is slightly modified and stronger. The power is only temporary, but the more you collect, the longer it will last. Its up to you to decide if you just want a normal power-up, or take a little risk and go for the Force pick-up.

SCORING
----------
I want scoring to complement survival as much as possible. Scoring reflects this philosophy: The more you play earlier stages, the better you become, the higher the score you get, the more lives you earn, and the longer you can survive in the later unfamiliar stages. It gives you something to come back to when you play again and again, since you'll always see progress.

There are medals, and crates that contain medals. The more Ps you collect, the higher each medal is worth on pick-up. The more powerful your laser is, the more medals a crate will yield when destroyed. Scoring high is tied to survival and mastery. A counter is kept for how many of each you destroy or collect. Upon death the medal counter is reset, but the crate counter DOES NOT.

At the end of the stage, the medal count value is multiplied by the number of crates destroyed. The amount of leftover Force time is also tallied at roundend.

This scoring system facilitates the idea that survival is most important way to earn as many lives as possible. Its less about seeing numbers go up and more about a representation of your progress.

Thanks for reading, testing it out, and sharing your criticisms. I hope to finish Tetsuishi in the next few months and release it for free.

[BPzeBanshee]

I'm so trying this out when I get back from work tonight. If you need a hand with anything like TATE/Vbox support/general GM coding advice let me know.

[BPzeBanshee]

Okay, gave this a spin at last (bit longer than I expected, sorry!).

The game ran perfectly except for one thing: firstly that it was hard-set to a resolution higher than my monitor could stand at native res (which GM handles by scaling down). Your game clearly isn't natively at this res though, because the tiles were showing lines which generally indicates up-scaling. I've looked around on this issue and the general consensus seemed to be related to non-exact up-scaling and GM being funny, which the one code example I found's solution was to scale the tiles up by an additional 0.05% of whatever scale the rest of the game runs - haven't tried this myself with tiles as I don't use them however. I think it's best that if you're ever planning a kind of dip-switch settings area to allow for scale adjustment, including allowing the native res - somehow I think you might know this already though.

Regarding the sounds, I'm not much of an audiophile but one thing to consider is that some may frown upon the stolen sound effects. Personally I don't give a damn, it sounds great and you've done a really good job making use of them, but if sfxr got you 99% of the way there with your own content perhaps going the 1% further wouldn't be too difficult? Either way, food for thought. I'd be a hypocrite to genuinely hark on this matter.

The only other critique I can really make is regarding the lack of auto-fire for the wide shot: considering the very cool laser allows for holding down I think it'd be more consistent to have the wide shot be able to be held down as well.

Overall it's really shaping up nicely. I'm so glad you've come to Development to reveal this to the public.

[Ebbo]

Looks absolutely stunning. If I didn't know I would easily confuse this one with Toaplan's early arcade-shooters. Very solid foundation, although I do hope the stage results screen would move at much more brisk pace. I don't mind a small breathing room, just give me a chance to fly aimlessly in circles until you enable autopilot

[gamingjustin]

Hey thanks for the feedback, I really appreciate it.

Yes, sorry about the resolution and thanks for letting me know about the tiling problem-- because on my computer it looks fine! It's a huge issue I haven't tackled yet. I think the reason you can see seams between the graphics is because the game is showing two views simultaneously. The game's native graphics run in a 240x320 environment, but in order to get the scanline effect without covering pixels I tripled the size to 720x960.

So here's what I did:
game view: 240x320, scaled to 720x960
scanline-only view: 720x960
both views are enabled, so the "higher res" scanlines appear over the lower-res, zoomed in game graphics.

My plan for resolutions is as follows:
Game will always start in a window with fullscreen option.
A 3x view, with scanlines made specifically for 3x zoom. Can be rotated.
A 2x view, with scanlines made specifically for 2x zoom. Can be rotated.
A native view 240x320, that will fill up the screen while maintaining aspect ratio. No scanlines. Can be rotated. This is intended for displays than can actually go that low, like old CRT monitors, or displays that actually produce scanlines.

I tried implementing all this with zero success-- switching resolutions is extremely quirky in Game Maker. From what I understand it cannot be done in the same room on the fly. The room or game has to be restarted or something.

The sounds are placeholders so don't worry.

And now I'll explain why I included the need for tapping when using the red laser. It's true that pressing the button faster does not increase the amount of shots you fire normally. However, once you get the force power-up (when your ship glows) it DOES matter. There is no limit to how many secondary lasers are on screen; so the faster you press, the better. However, this secondary laser is very weak and it's main function is that is passes through targets, unlike the primary laser which does a vast majority of the damage but stops on hitting a target. In older STGs, people with fast fingers always had a huge advantage. I wanted to retain the importance of pressing the button fast, but now it only gives a slight advantage so it's not the key to victory. For people who don't care (or can't), they can tap the button at a nice pace and deal plenty of damage.

I even thought about making the blue laser stronger the longer you held down the button-- to contrast it even more with the red laser-- but I felt it would be too annoying to use.

So thanks again for feedback. I also wish I had checked out your G.M.O.S.S.E. project sooner! It's a really good STG engine and I could have learned a lot SO much faster. I resorted to Googling stuff a billion times a day, endlessly trawling Game Maker and indie developer forums. So yes, if it's okay, I will probably take you up on your offer and consult you regarding resolution/tate stuff. But for now I think I'll get more enemy programming done.

[mice]

Screams potential! This is how you do tributes.
So, please continue.

[n0rtygames]

Screams potential! This is how you do tributes.
So, please continue.

See this comment? I just wanted to let you know I whole heartedly agree with it.

Please make more.

[n0rtygames]

Also, I think you should post some screenshots to show this off and get yourself some attention. It's really fucking worthy of it.

Here's one I hosted for you!

[mice]

It's really fucking worthy of it.

.

[gamingjustin]

Hey, thanks for the cool screenshots guys-- I was lazy to not include any. My plan right now is for the game to be just one stage, 5-6 minutes long, and loop infinitely; probably adding increased enemy bullet speed and suicide bullets with each round until round 8. This is all new to me, so it takes me a super long time to program and even longer to draw the graphics. If I made a 40-45 minute game it would probably never get done.

I'll keep checking this thread for any feedback and criticisms, and will update with significant builds whenever I get the chance. This first test build took me about 4 months to make, but hopefully I can finish this project by the end of the year.

[n0rtygames]

Feel free to include the screens in your first post. I'm sure mice won't mind either!

Generally it's quite hard to get attention round these parts, so if your game stands out as beautiful (which it is) - it won't do you any harm. More players = more feedback, right?

[BareKnuckleRoo]

And now I'll explain why I included the need for tapping

lol

I wanted to retain the importance of pressing the button fast, but now it only gives a slight advantage so it's not the key to victory. For people who don't care (or can't), they can tap the button at a nice pace and deal plenty of damage.

I choose a third option.



There's a reason Tatsujin Oh has a dipswitch setting for autofire.

As much as I detest having to tap constantly in a genre where you'll want to be pressing that button nearly all the time, if you really wanted to retain an element of tapping shot you could perhaps balance it out by having hold shot autofire the non-piercing shots and have only the piercing shots activate on each tap of the button?

It's very good, clearly Tatsujin/Truxton inspired. I notice enemies fire at you if you don't kill them and they get near the bottom of the screen, I got sniped once this way by moving horizontally and taking a bullet when a turret came onscreen at the bottom. This can make things rough, and the stage ending sequence is a bit slow as others have mentioned, but maybe it just feels slow/empty without music? Obviously once you've got more than placeholders it'll feel more 'alive', and as you said you'll add in your own stuff. Really, it's great for an early prototype to see it this polished/playable and I'd love to see more devs release quality stuff like this.

Is it me or does your movement speed go up when you're using the blue powerup?

[gamingjustin]

Yeah Roo, that's a really good solution to the tap/hold problem. I really like to drummer tap with my index and middle finger on arcade controls, so that's my bias creeping into development. This is one example why I decided to share this project, since it's hard for me to think of things from an outside perspective.

And THANKS for reminding me about deadzones/no-fire zones. I think I have them programmed in there, but they're not big enough. Certainly, I'll make it so no enemy can fire in the bottom-most 32 or 64 pixels of the screen (i'll have to test of course), and any ground enemy you hover over won't fire at you. And I want it so if an enemy can shoot at you, you can shoot at it. I never want an off-screen thing shooting you, or you killing stuff before it appears on-screen. I think the system works, but keep an eye out for oddities.

Also yes, for now you move faster with the blue laser than the red. The reason being the blue will be weaker against bosses, so I want the player to be able to have a slight edge in dodging compared to the red laser. Also, the first power level of the blue laser is a single beam, so moving faster helps you sweep across the screen faster. But all the weapon balance is in flux. It might be problematic to constantly switch speeds when switching weapons. Might be better to just have one consistent speed so a player can learn to dodge better.

[BPzeBanshee]

I tried implementing all this with zero success-- switching resolutions is extremely quirky in Game Maker. From what I understand it cannot be done in the same room on the fly. The room or game has to be restarted or something.

It can be done without restarting the room but with severe distortion as a result of altering the various view settings. I did it before, it looks really ugly especially for the clarity you're attempting to have here. It's a somewhat annoying issue that Pieterator discovered the solution for last year in Aero Flux by making use of room_set_view. He did it for each room line-by-line, after a bit of searching through YoYoGames Forums I managed to get a method of cycling through all the rooms with the necessary adjustments. Crash course as below:

Code: Select all

i=room_first;
while i != -1
    {
    if i != rm_init
        {
        room_set_view(i,0,true,-x_o,-y_o,win_w,win_h,xport,yport,w,h,0,0,0,0,noone);
        room_set_view_enabled(i,true); 
        }
    i = room_next(i);
    }

Doing rotations of the view with view_angle combined with altering the view dimensions result in offsets when using view_xview/yview[], and also with some other drawing routines. For this reason you'll need to design around this with appropriate offset variables to ensure everything renders/draws on all relevant angles.

I'm sure you're probably familiar with the concept of a while loop. Some folks originally tried this in a for-loop but I found it to be glitchy, clearly the guys on Yoyo didn't test their code before posting it as a solution and locking the thread down.

rm_init in my case is my initialisation room where I load my config file, external resources, initial music etc....and do all the screen adjustments. If you don't have one it's a good idea to start having one: good practice in general and allows for situations as these.

win_w/h is obviously width and height of the view: if you're flipping the game on it's side you'd want 320x240, 240x320 otherwise. xport/yport and w/h I only have there for my VirtualBox compatibility hack to get it to appear properly in fullscreen, for normal purposes you can just have them as 0,0,win_w,win_h.

GMOSSE's scr_screen_init() has all of this and then some, next release's version will be condensed a bit better thanks to the while loop. Once this initialisation of the rooms is done when you enter the room it's a simple matter of using view_angle[0] = 90. If you'd like I can cobble up an example with current code.

[gamingjustin]

I appreciate the detailed explanation on resolution and angle switching, Banshee. I'll probably add a room at the beginning that looks like a video test screen that will run the code for the resolution switch (with screen variables stored in an .ini perhaps?). Don't worry about having to whip up an example; between the code you provided and referencing G.M.O.S.S.E. I can probably get it together. Thanks.