Making bosses in an action game is easy. They're essentially just regular enemies that have more health and hit harder. But if you're struggling with it, remember the boss triumvirate:
- The Wall: A large immobile boss who tanks lots of hits and fires a barrage of projectiles and weaker mobile enemies to whittle the player down. A fun subspecies of the Wall is the Invisible Sniper. Red dot appears on the player, and they need to duck and cover or be insta-killed!
- The Helicopter: An airborne boss who peppers the player with projectiles from a long range. In case the player brings the fight in close, this boss should be able to quickly zoom far enough away that they become unreachable for a period of time. If you like putting the player in a stressful situation, you can make the Helicopter completely invincible until the player finds a turret or rocket launcher at the end of a gauntlet of enemies and hazards to circumnavigate
- The Dancer: This boss is rotating on an axle in order to always be facing the player to give a convincing illusion that they're actually targeting them when they do their attacks. Have the bosses operate on a timer wherein they'll do their attacks regardless of player proximity, and simply make sure the arena is so small that the player won't be able to just camp in a corner when things get too heated.
One thing that players love is when a boss has a phase where they unload a string of attacks with rest periods that are juuuuust short enough that the only way for the player to make it out without at least taking a few scratches is if they have mastered the art of frame-perfect dodges. There... is a dodge in your game, right? C'mon now. Every action game needs a dodge. Invincibility frames on your dodge is optional though.
Got difficulty settings? No problem. All you gotta do is crank up those enemy stats. More health, more attack. Nothin' beats that! Oh, you're considering giving bosses more complex attack patterns at higher difficulties? You could do that if you want.... BUUUUUT I think you should hide those behind a special difficulty that can only be unlocked by beating the game. And if it's a level-based game (ie: DMC, not Kingdom Hearts), beating a level should only unlock the next level for that difficulty. This will ensure player retention and greatly extend the replay value and playtime.
All this difficulty needs a side-gig to calm the pacing, keep in mind. After an intense fight, just have the player walk slowly down a hallway. Maybe use this time to expound upon some plot.
I think all of you would like this video series.
Here's mine:
Be a game director, not a game developer! Get a team of people together to do everything for you while you tell them what to do, or just go hands off and say "looks good to me" to everything! Especially if the team is made of strangers who don't know who you are and you haven't earned any prior trust or respect from them!
If you're in a managerial role like that, never request a copy of the code. Everyone on your dev team has the best intentions, and your programmer would never do something like nuking the game entirely because you got into an argument. People just aren’t petty like that. (RIP Costume Clash)
When you finally start trying to program, make your first game a collab showcase piece! Not only that, but a BIG collab showcase piece! Having to quickly learn how to make complex mechanics while other people are counting on you to finish it by a deadline has a very low chance of going wrong!
Bring the whole dev team into your personal drama! If you don’t like the way someone responded to you, start a harassment campaign together! It’s a great bonding experience for the team, and any damage you do to someone else’s mental health is completely justified just because they didn’t praise you!
Most of all, the first rule of collaborating with other people is that nothing is ever your fault!
Someone please help me revive my clubs
If you make a platformer, always make pits an instakill
Be too afraid to even try out game development because you fear you are coding wrong.
But also never go back and improve and fix up your bad code. If it works now better not touch it so it works later.
Visit aapiarts Portal today by clicking her butt!
At 12/25/25 02:32 PM, aapiarts wrote:But also never go back and improve and fix up your bad code. If it works now better not touch it so it works later.
You should actually be constantly looking for better ways to optimize and improve your code. Just because it isn't broken doesn't mean it can't be fixed. When programming you should just assume that one day a nitpicky software engineer is going to find your game and do the CinemaSins routine on your code.
"That if/else statement could've been a switch. DING. Too many unnecessary variables with unique names. You could've just made 'em an array. DING. Uh-oh. Magic number spotted!!! DINGDINGDINGDINGDI-- "
At 12/23/25 09:27 PM, Edeshye wrote:bros if you could only see my projects from 2020 or so...
i used to put enter_frame functions and not remove them (i thought they got destroyed when the symbol was not on stage).
I had no idea why there were a bunch of error messages every single frame , but it was working so i just ignored them lol.
i managed to get the worst possible performance for a flash game.
Nowadays i'm being very thorough, though (thought it through!)!
This is new to me. I didn't know this was a thing. Is this an ActionScript 3.0 thing or just a general thing with ActionScript?
abuse infinitely nested if statements to create a black hole
At 12/25/25 05:11 PM, Nabella wrote:At 12/23/25 09:27 PM, Edeshye wrote:bros if you could only see my projects from 2020 or so...
i used to put enter_frame functions and not remove them (i thought they got destroyed when the symbol was not on stage).
I had no idea why there were a bunch of error messages every single frame , but it was working so i just ignored them lol.
i managed to get the worst possible performance for a flash game.
Nowadays i'm being very thorough, though (thought it through!)!
This is new to me. I didn't know this was a thing. Is this an ActionScript 3.0 thing or just a general thing with ActionScript?
you mean the enter_frame thing or it going on after the symbol is destroyed? i know in actionscript 2 it was called onEnterFrame or whatever. i don't know if it kept running after deletion, though.
Long live human hentai!
At 12/25/25 01:55 PM, Thetageist wrote:I think all of you would like this video series.
Here's mine:
Be a game director, not a game developer! Get a team of people together to do everything for you while you tell them what to do, or just go hands off and say "looks good to me" to everything! Especially if the team is made of strangers who don't know who you are and you haven't earned any prior trust or respect from them!
If you're in a managerial role like that, never request a copy of the code. Everyone on your dev team has the best intentions, and your programmer would never do something like nuking the game entirely because you got into an argument. People just aren’t petty like that. (RIP Costume Clash)
When you finally start trying to program, make your first game a collab showcase piece! Not only that, but a BIG collab showcase piece! Having to quickly learn how to make complex mechanics while other people are counting on you to finish it by a deadline has a very low chance of going wrong!
Bring the whole dev team into your personal drama! If you don’t like the way someone responded to you, start a harassment campaign together! It’s a great bonding experience for the team, and any damage you do to someone else’s mental health is completely justified just because they didn’t praise you!
Most of all, the first rule of collaborating with other people is that nothing is ever your fault!
I've actually watched quite a few of those videos, it's how I got the idea.
I'd say game directors should be like a level above game developers like they're the lead game developer, like how film directors are lead filmakers.
At 12/25/25 07:57 PM, Edeshye wrote:
you mean the enter_frame thing or it going on after the symbol is destroyed? i know in actionscript 2 it was called onEnterFrame or whatever. i don't know if it kept running after deletion, though.
onEnterFrame continuing to run even after a MovieClip it's attached to is removed from the stage.
Make GTA VII as your first game.
At 12/25/25 09:46 PM, Nabella wrote:At 12/25/25 07:57 PM, Edeshye wrote:
you mean the enter_frame thing or it going on after the symbol is destroyed? i know in actionscript 2 it was called onEnterFrame or whatever. i don't know if it kept running after deletion, though.
onEnterFrame continuing to run even after a MovieClip it's attached to is removed from the stage.
yeah idk about that. but nothing that a simple trace("asdfas"); can't verify lol
Long live human hentai!
At 12/25/25 08:51 PM, RosieUV wrote:At 12/25/25 01:55 PM, Thetageist wrote:I think all of you would like this video series.
Here's mine:
Be a game director, not a game developer! Get a team of people together to do everything for you while you tell them what to do, or just go hands off and say "looks good to me" to everything! Especially if the team is made of strangers who don't know who you are and you haven't earned any prior trust or respect from them!
If you're in a managerial role like that, never request a copy of the code. Everyone on your dev team has the best intentions, and your programmer would never do something like nuking the game entirely because you got into an argument. People just aren’t petty like that. (RIP Costume Clash)
When you finally start trying to program, make your first game a collab showcase piece! Not only that, but a BIG collab showcase piece! Having to quickly learn how to make complex mechanics while other people are counting on you to finish it by a deadline has a very low chance of going wrong!
Bring the whole dev team into your personal drama! If you don’t like the way someone responded to you, start a harassment campaign together! It’s a great bonding experience for the team, and any damage you do to someone else’s mental health is completely justified just because they didn’t praise you!
Most of all, the first rule of collaborating with other people is that nothing is ever your fault!
I've actually watched quite a few of those videos, it's how I got the idea.
I'd say game directors should be like a level above game developers like they're the lead game developer, like how film directors are lead filmakers.
Yeah. Being a game director isn't bad in like, more organized teams/companies, but from my experience, it should not be the role you take in your first game dev project. (This is for all those people on NG who ask others to make a game for them! Hint, hint!)
Someone please help me revive my clubs
Heres mine: You sync up a spotify playlist, with your game. You play a playlist separate from the game, and the game syncs with it and plays the right songs at a right times. That means the people that made the songs can't sue you, cause the songs aren't in the game. Its a spotify playlist that you play with the game, so you aren't monetizing of the music! ITS FOOL PROOF!!!
do you like Hatsune Miku?
you do?
THEN COME JOIN THE VOCALOID ART COLLAB!
ANYONE CAN JOIN! DEADLINE IS MARCH 6TH 2026!!
Forum Signature made by the incredible Vinity
At 12/26/25 08:38 AM, RedWonder8 wrote:Alt F4
I used to think that was a windows only shortcut, much to my surprise is that it's more or less OS agnostic when I tried it once.
"I don't want excuses. I want results."
~Skipper
Click here to see my art and animation thread postings. Just a note that some of it might be NSFW.
Your prototype isn't your first draft, it's your master build!
Sure it's spaghetti as shit and your time experimenting with the code has made you better at doing everything more cleanly and gracefully, but you already did the work! Don't iterate, don't reinvent, you did it already! If it "kinda works"*** then just keep truckin', baybee!
Go straight into making the graphics, forget about the gameplay loop
ich mag katzen
At 12/26/25 11:34 AM, CappyCatII wrote:Go straight into making the graphics, forget about the gameplay loop
Don't call me out like that.
At 12/26/25 12:41 AM, DweamCaster wrote:Heres mine: You sync up a spotify playlist, with your game. You play a playlist separate from the game, and the game syncs with it and plays the right songs at a right times. That means the people that made the songs can't sue you, cause the songs aren't in the game. Its a spotify playlist that you play with the game, so you aren't monetizing of the music! ITS FOOL PROOF!!!
ngl that sounds like a pain to code but is honestly quite smart. dunno why some shovelware developer haven't tried that out yet.
Always make a very long unskippable tutorial. Even after reaching NEW GAME+
ZombieGhost
At 12/22/25 06:09 PM, RosieUV wrote:Here's mine: do all the assets first, coding last. Don't bother with placeholders and just burn yourself out drawing hundreds of visual novel sprites over the course of a few months, and then when your artstyle inevitably improves, do it again!
This actually hits so close to home, because I did this exact same thing years ago while trying to make an RPG.
When Undertale was still new, I decided that I wanted to make the next big indie RPG, so I started learning Clickteam and tried making a vertical slice demo. It was Earthbound mixed with classic Paper Mario; the most original indie RPG ever made. The problem was that I could barely draw, let alone animate sprites. In order to get the sprites to fit on screen, I would have to scale them down after drawing them, which made them impossible to perfectly align when animating. It was full of stiff, yet twitchy sprites that only moved with limited animation. I was starting to get better as the demo went on, but halfway through, I knew the graphics and code were so messy that I needed to try again from scratch. This time, I figured I would start by making the over-world in a better art-style, and add everything else afterwards. I made about 6 rooms before finally giving up.
I haven't tried making a real game since, but next time I do, I'll know better than to shoot for the stars.
At 12/25/25 03:53 PM, Chdonga wrote:At 12/25/25 02:32 PM, aapiarts wrote:But also never go back and improve and fix up your bad code. If it works now better not touch it so it works later.
You should actually be constantly looking for better ways to optimize and improve your code. Just because it isn't broken doesn't mean it can't be fixed. When programming you should just assume that one day a nitpicky software engineer is going to find your game and do the CinemaSins routine on your code.
"That if/else statement could've been a switch. DING. Too many unnecessary variables with unique names. You could've just made 'em an array. DING. Uh-oh. Magic number spotted!!! DINGDINGDINGDINGDI-- "
That’s why it’s so nice to work with other devs because then your code gets torn apart in PR reviews (but in a good way!!). They catch stuff I wouldn’t have ever thought of sometimes
At 12/26/25 09:29 AM, Skoops wrote:Your prototype isn't your first draft, it's your master build!
Sure it's spaghetti as shit and your time experimenting with the code has made you better at doing everything more cleanly and gracefully, but you already did the work! Don't iterate, don't reinvent, you did it already! If it "kinda works"*** then just keep truckin', baybee!
ACTUALLY I lightly disagree with that, esp if someone is starting out. It’s tricky cause on one hand it might be spaghetti code, but on the other hand someone not used to coding focusing purely on optimization is gonna burn out. At least that’s just something I’ve observed!! For someone’s first game(s) spaghetti prototype code is ok imo, as long as they get better each game they make
Purely from a programming standpoint tho that is def a no-no, it’s better to get stuff working well than to have it glued together. But that’s something that just naturally happens w/ experience
I also think it’s good to take old code or reuse scripts if they already work. BUT if they run bad then it might be better to either optimize it or just remake it completely depending on what it is. I feel like it’s better for seeing what you can optimize imo! You go “eww actually this code sucks because of XYZ lemme fix these”, or “crap this is so bad it’s unsalvageable lemme attempt this again”
Basically imo reusing code is a way to get that experience because you start seeing firsthand why it’s better to have quality code and good practices (and what those are)
At 12/31/25 08:06 AM, Oddlem wrote:At 12/26/25 09:29 AM, Skoops wrote:Your prototype isn't your first draft, it's your master build!
Sure it's spaghetti as shit and your time experimenting with the code has made you better at doing everything more cleanly and gracefully, but you already did the work! Don't iterate, don't reinvent, you did it already! If it "kinda works"*** then just keep truckin', baybee!
ACTUALLY I lightly disagree with that, esp if someone is starting out. It’s tricky cause on one hand it might be spaghetti code, but on the other hand someone not used to coding focusing purely on optimization is gonna burn out. At least that’s just something I’ve observed!! For someone’s first game(s) spaghetti prototype code is ok imo, as long as they get better each game they make
Purely from a programming standpoint tho that is def a no-no, it’s better to get stuff working well than to have it glued together. But that’s something that just naturally happens w/ experience
I also think it’s good to take old code or reuse scripts if they already work. BUT if they run bad then it might be better to either optimize it or just remake it completely depending on what it is. I feel like it’s better for seeing what you can optimize imo! You go “eww actually this code sucks because of XYZ lemme fix these”, or “crap this is so bad it’s unsalvageable lemme attempt this again”
Basically imo reusing code is a way to get that experience because you start seeing firsthand why it’s better to have quality code and good practices (and what those are)
I think it's all a question of when you decide to do that 2nd draft. Don't do it too early, let things barely function until you hit a certain threshold of knowledge. It shouldn't be while you're still getting the hang of things, it should be well after you're established, comfortable with your engine and have figured out faster and more graceful ways to do things on your own.
It's equal parts painful and freeing to take all the stuff you did while learning, set it aside and go at it again knowing everything you've learned. It's like redrawing a piece from before you knew fundamentals: it comes more easily, you'll do it way better and in less time, but you need to have put a lot of work in before the difference will be significant.
Hello! Since I'm new to this site, I hope you have a great experience here. As a game developer with 5 years of experience, I have a lot of non-commercial and semi-commercial work, and I currently work remotely with a game company while also studying. You need to design your game to suit the market because it's constantly evolving. You should also promote your game on all social media platforms or send it to a content creator. You need to work with multiple teams to gain the necessary experience to develop yourself and build successful business projects.
NEVER organize your game files, always keep them in a single folder, no subfolders. Also, make sure to switch game engines at least 3 times during development.
At 1/2/26 11:55 PM, teamsonic2011 wrote:NEVER organize your game files, always keep them in a single folder, no subfolders. Also, make sure to switch game engines at least 3 times during development.
Make sure one of those engines is also like 20 years old and had barely any documentation on it. Troubleshooting is overrated anyway.
Go full speed ahead, with no breaks, while doing everything else you normally are obligated to do. Then burn out, do different completely projects, in fact, different entire games. Forget about the original idea in the process..
Then miraculously remember the original game the next year!
Remember my random "test this game" thread? Yeah well, I barely made any progress since then...
