Game Design Megathread

Author Topic: Game Design Megathread  (Read 433025 times)

but if you're making a game for PC you should really design for mouse and keyboard first
I disagree. You should make the controls you the developer want to use work first to ease testing, and then down the track when you know the game actually works and is fun you can then play around with other control inputs.

It's best to push as many variables further down the line so you can focus on getting the core right first.

It's best to push as many variables further down the line so you can focus on getting the core right first.
i think this is an extremely destructive mindset personally

if you don't think of the implications of your design choices on the game as a whole as you make them you'll run into serious problems either instantly or way too far ahead for you to have expected it

i think this is an extremely destructive mindset personally

if you don't think of the implications of your design choices on the game as a whole as you make them you'll run into serious problems either instantly or way too far ahead for you to have expected it
I'm not saying don't consider everything from the outset. That's the reason we have a whole pre-production phase to plan for every eventuality that'll arise during development. You can't really plan the definite controls without testing how the mechanics work first though (you can certainly make guesses of what they'll be, but I don't think I've read many prototype documents that cover control schemes).

Once you've got that plan, you can then focus on the core elements first. Things like alternate control schemes that you don't plan on using primarily for development are something you shouldn't worry about until you've nailed the important bits first, especially if you're not making a massive game for millions of people to play.

I'm not saying don't consider everything from the outset. That's the reason we have a whole pre-production phase to plan for every eventuality that'll arise during development. You can't really plan the definite controls without testing how the mechanics work first though (you can certainly make guesses of what they'll be, but I don't think I've read many prototype documents that cover control schemes).

Once you've got that plan, you can then focus on the core elements first. Things like alternate control schemes that you don't plan on using primarily for development are something you shouldn't worry about until you've nailed the important bits first, especially if you're not making a massive game for millions of people to play.
There's a very simple way to avoid this issue that torque itself implements. We call them keybinds. They're incredibly easy to manage, store, and change. Even with the most basic of custom made games, all you'd ever have to do is go into keybinds.txt or whatever and change a line of text, and the controls would be different. No need for horrible hard coded keys like most games have.

Another plus is that if you're using a library with controller support (i.e. SFML) you can "keybind" buttons on the controller with no goddamn effort.

Though I do agree keys aren't important at all if you're still working on the basics of the game. Nothing has to be user friendly if it's only you that needs to use it. A keybind system however is still something you want to implement right off the bat simply because you don't want to have to go through all your code changing function calls later.

Game idea:
You are a night-dwelling beast in a survival plane.
Almost everything around you is usable and able to build stuff.
The twist is: Light hurts you.
That's right, any shard of light will cause damage to you.
You have to build temporary shelters that become damaged by the sun/light and you have to fight off enemies during the night.

games certainly handle different with a controller than with mouse and keyboard

keybinds will work fine for a lot of games but you just have to be aware what kind of game you're making when you make decisions about controls. it's an important part of your game that deserves a lot more attention than people think

as long as you're completely aware of what you're doing, it probably doesn't matter what order you do it in, but you just gotta kno, u kno?

On a completely unrelated subject...

 :cookieMonster:



working on my game for gbjam3

that color scheme is goddamn fantastic

oh my goddddddddddddd



Working on an RTS game I guess.

I DON'T KNOW HOW TO PHYSICS



HOW TO COLLISION

are those balls of supercooled water


Working on an RTS game I guess.

looks good! i would play it, despite me not being such a big fan of RTS games
either way i made some progress on this run n' gun arcade game i've been working on

still a few things that definitely need to be tweaked with, but yeah

that's actually very good

it's really overanimated but not in a way that implies that the characters are all just hams and more like it's a cartoon