next »

[Hydorah]

I've got this rather ambitious 2D game idea in my head, main character, setting, overall plot... Everything's still vague and brainstorm-esque, but I have some images in my head of how it'll look and play out. I have tons of experience with GM:S programming, and can make any idea a reality. The question is, where do I start? I won't get a freelance artist or a writer on-board just by saying "HEY BITCH LOOK AT MY AMAZING GAME IDEA, NOW GET TO WORK", I'll need to reel them in by showing them what I'm capable of, and what the game could potentially become to the point that they'll want to take part in it... But I need an artist to even begin the design process. Character design, character animation, atmosphere, that's all heavily reliant on the artists and designers.
I just don't know where to start. Need stuff to pitch game to others, need others to make said stuff in the first place.

[cynicalsandel]

placeholder art

edit: or you know, crazy idea here, you could pay an artist

[Jordgubben]

How about opengameart.org or similar?

Personally I'm a bit sceptical of low quality placeholder art (aka "programmer art"). My experience of so called "temporary" solutions is that they tend to be the most long-lived solutions. Using premade assets of relatively high quality means that you get a Minimum Viable Product at a much earlier stage in development.

You could also make mock screen shots if you just want to be able to pitch.

[ｂ∀ ｋｋｕｓａ]

You can use Game Sprite Sheets from existing games (neogeo nsk), lot of ressources available in the internet and the quality is good for your game prototype.

rather ambitious 2D game idea in my head, main character, setting, overall plot

if your game is heavily dependent of the atmosphere  and design you've already imagined. You're at the risk of giving less artistic freedom and that will usually cost you money.


the videos on your youtube channel are already convincing.

Get more social, try to hang out around art schools and universities.

you might find some people here.

[Sgt. Pepper]

I draw multicolored square, then replace them later on with the actual art.

[Impmaster]

I mean, if you're highly experienced at GM:S it's likely that you've made other games. Now, I'm not an artist but I'm thinking that I'd collab with a guy who knows his shit. Just show some of your portfolio and then if people like your idea, they'll want to join in, I guess.

[ஒழுக்கின்மை (Paul Eres)]

a design document and a mock-up of what the finished game would look like (drawings / art, of fake screenshots, done in photoshop or something of what you want the finished game to look like)

[Andrew Brophy]

i've ripped so much placeholder music i can't tell what's real anymore

[DanglinBob]

up up down down left right left right a b start.

That's how I start all my games, just in case.

[Capntastic]

The protagonist being told to wake up by their mother.  They're late.  Then you enter the name.

[Photon]

So is the part where I make a snide remark about putting the game in the console, turn it on, and select "New Game?"

Honestly though, I tend to just attack things. I come up with an idea and just sort of starting coding stuff. Admittedly, this is not the best strategy and something I hope to rectify over time.

[Jordgubben]

Honestly though, I tend to just attack things. I come up with an idea and just sort of starting coding stuff. Admittedly, this is not the best strategy and something I hope to rectify over time.

That is the worst possible approach, except if you consider the alternatives. Constantly procrastinating on writing that lengthy  "design document" that no one will ever read will not lead you anywhere. All your initial ideas will be wrong. The least bad way to do is to just start by doing something small and to the point, accumulate knowledge by doing, then thinking and refactor the design.

Of course, as usual, the co called "best" approach all depends on the type of game project.


https://en.wikipedia.org/wiki/Cynefin

If you are doing a new game, then you are doing something *Complex*. The relation between input and the output (in to and out of the player) is not predictable. Established practises do not and exist genre standards are undefined. No one understand what you are trying to do, not even you yourself. Experiment, question your assumptions and make music out of the cognitive dissonance. You are *Ken*.

If you are working in an established genre, then you are doing something *Complicated*. Prior experience and expectations exist outside your game. Proven good and "good" ideas can be both reapplied and subverted. While your code base starts from an initial empty repo, you are at the core already refining and improving existing games from your first commit. Wake up early, practice regularly and stand on the shoulders of giants. You are *Ryu*.

So pick one. Or be the ultimate warrior. Go for broke. Be both.



(Pardon the text wall. Working wit operative IT management for a few years has caused me to grow a sore spot and admittedly a "strong opinion"  in in this this topic.)

[JWK5]

Alcohol. Lots and lots of alcohol.

Everything beyond that is a blur.

[Photon]

"wall of text"

(Pardon the text wall. Working wit operative IT management for a few years has caused me to grow a sore spot and admittedly a "strong opinion"  in in this this topic.)

Not a problem at all. I know its not a great strategy and occasionally you'll get away with it in a very small game project. As I move towards the bigger stuff, my planning and design really needs to get better. GIMME THAT SELF-DISCIPLINE.

[mks]

[Jordgubben]

"wall of text"

(Pardon the text wall. Working wit operative IT management for a few years has caused me to grow a sore spot and admittedly a "strong opinion"  in in this this topic.)

Not a problem at all. I know its not a great strategy and occasionally you'll get away with it in a very small game project. As I move towards the bigger stuff, my planning and design really needs to get better. GIMME THAT SELF-DISCIPLINE.

Please do not misunderstand. It was not my intention to criticize your approach. Rather I meant to praise it.

Having to much of a plan can be just as damaging to a project as having to little of it. Add the fact that making that surplus planing, even thou it is excessive, still requires considerable effort. This is effort that could have been spent on something more useful to the project goal. Seen in this light it's perfectly reasonable to conclude that having to much plan is actually a little worse then having to little of it.

[Melon Mason]

I tend to discourage people from doing the design document approach, I've always felt that it's a method that works best in teams of people. You can procrastinate by over-planning things, a design document is an illusion of progress when you are a solo developer. You don't need to work so conventionally if you are largely creating the game yourself.

That said, I fear people grossly neglect code / functionality design. Whenever people talk about planning and design, it's always about the story or the graphics. In my mind, those things are important to keep flexible and should evolve with the game as you develop it.

Programming requires forethought unless you want to regularly waste time rewriting code. Write notes about features you want in the game, draw out and brainstorm how you will program core systems in your game, and comment code as you develop it. It's all standard practice professionally, it works for solo hobbyists as well.

Once you understand what needs to be done in terms of programming, you shouldn't be confused as to how you should start. Placeholder art is acceptable, if you need a break from programming you can always have a crack at improving your graphical skills and making some assets yourself.

[s0]

@melon mason: good post!

Programming requires forethought unless you want to regularly waste time rewriting code. Write notes about features you want in the game, draw out and brainstorm how you will program core systems in your game, and comment code as you develop it. It's all standard practice professionally, it works for solo hobbyists as well.

ohhh yeah i learned this the hard way. my code used to be so unreadable that i literally couldn't refactor it after not touching it for 2 weeks, so i wasted a LOT of time trying to "reverse engineer" my own code to fix bugs and add features and etc.

[ra51]

[Jordgubben]

That said, I fear people grossly neglect code / functionality design. Whenever people talk about planning and design, it's always about the story or the graphics. In my mind, those things are important to keep flexible and should evolve with the game as you develop it.

Programming requires forethought unless you want to regularly waste time rewriting code. Write notes about features you want in the game, draw out and brainstorm how you will program core systems in your game, and comment code as you develop it. It's all standard practice professionally, it works for solo hobbyists as well.

Word. Your going to end up rewriting a lot regardless of how much you plan. Having a good holistic understanding of your architecture means you know how it needs to change when (not "if" but "when") it has to change.