Jaelights

Slooping dupes over here

Succinct transbien musician behind Lorelei and the Ghost.
Bring me your finest Yuris!





Music Links:
YouTube: https://youtube.com/@Jaelights
SoundCloud:
https://soundcloud.com/jaelights
BandCamp:
https://jaelights.bandcamp.com/



Writing:
https://www.wattpad.com/user/Jaelights



Business Email if you want music:
loreleiandtheghost@gmail.com



Profile Pic by @nomnomnami


ctmatthews
@ctmatthews

Before I became a solo indie developer and made games like Chessplosion and Ducky's Delivery Service, I spent over a decade working for other game studios. I was mostly a gameplay programmer at AAA studios (~150 people) and "big indie" studios (~15 people), and I've done some engine/tools programming and some game design consultant work too.

I was going to write a big post on the game production process but I realized that most of it is pretty obvious. You come up with an idea for a game, then you make sure that the idea is good by prototyping its mechanics and planning everything out (also known as pre-production), then you make the rest of the game (also known as production).

It's just like any other type of art. You think of an idea for a drawing, then you sketch it, then you render the final picture. You think of an idea for a book, then you write an outline and a rough draft, then you write the final novel.

The only part that isn't obvious, judging from how I've seen this exact mistake being made over and over again on all sorts of games, is that you shouldn't move on from pre-production to production until you are 100% confident that the game is already good enough. I really cannot overemphasize how important this is. Ignoring this is by far the biggest and most common mistake that I see game developers make, and it is often game-ruiningly bad.


Jaelights
@Jaelights

Seriously, read this. It applies to music, imo, as well. I remember I used to have issues where I’d write an interesting chord progression for a verse, decide it was amazing, then spend hours embellishing it before even considering a chorus, a bridge, an interlude….a melody….

It was difficult to add those parts in after I’d done so much to a single section of the song. This would force me to either strip back a bunch of work or, worse, just abandon the idea and release the song as a simple, one trick loop. Not that that is inherently bad, it’s just not what I had intended.

Moral? It’s just as Cassandra is saying, sort out the core of your art before you start refining it. These days I make sure I have a solid chord progression and a beat for every section of my song before I even start arranging the sections. Once the arrangement feels good, I’ll test to make sure I can figure out a melody for it by doing a few improves (either vocally or with my guitar, my most natural instruments). If it feels like my improved are flowing naturally, I move on to refining. You know, adding little parts here and there, playing with effects, doing some mixing, etc.

lol, didn’t mean to get that in depth. But hopefully it helps illustrate that the process can deffo be used in any creative endeavor.


You must log in to comment.

in reply to @ctmatthews's post:

yeah! mostly making content. levels, art, music, sound effects, extra game modes, and so on. and any features that are so straightforward in their design that you didn't need to prototype them, such as leaderboards, achievements and the options menu.

something i didn't mention here is that i personally tend to split pre-production into two halves: the prototyping phase where i make sure the gameplay is good, and the rest of pre-production that i usually try to do afterwards. so if my gameplay idea ends up being bad, i didn't waste any time trying to figure out what the game should look and sound like.

so if i was a game-making robot who didn't need to take a break from programming in the middle of the prototyping phase to draw some sprites, i would have done all of the gameplay prototyping first and then done the rest of pre-production afterwards: deciding the art direction and making a few sprites, deciding what the music should sound like and making a music track, deciding how the sound effects should sound and making a couple of them, and then making a short level that's representitive of the full game. you could tie all of these together to try and make a vertical slice of the full game, or you could just do them all separately.

the important part is just that you try to make sure that the game is good as early as possible, so you don't have to waste too much time if there are any surprises.

Really good advice! thank you!

prototyping "all" of the game is one that's really close to me, as there's this really compelling feeling when I started out that 'game development' should 'feel' like a linear story- which results in stuff like trying to do all the first levels and 'start' of the game polished, before moving onto the 'end' of the game-

but it doesn't really work this way! it's like building a ship and making sure the stern is completely finished and furnished before starting on the bow. It's a tricky one because most people get into game dev because they llove games, and at least for me, it was challenging to develop a different attitude for making games vs playing them!

I think the big issue with extensive prototyping is just figuring out when your prototype is good enough. Without a good feel for that, it's easy to get stun in an iteration loop and just prototype non-stop. To the point where taking the L and releasing a kind of eh game, then iterating with a sequel/successor would better, at least from a creative perspective if not financial one.

How did you tell when enough was enough for example? Were there moments where it clicked and made you go "ok this is gonna be a cool full game" or was it just a very intangible, gradual feeling?

My personal rule right now is to keep working on it until the player's encouraged to use a variety of mechanics based on situation, encouraged to use noticably different tactics against different enemy types, and forced to vary up their approach based on environment & enemy combinations in a way that again, is clear instead of really technical and nuanced. And all of that should be "natural", stemming from player move properties, how the different objects interact, etc. instead of enemy-specific gimmicks and stuff like super armor. Needless to say, I'm far from that point despite working on my prototype for quite a while 💀

my rule of thumb is that i stop working on a prototype if it's good enough that i'll be satisfied with the final game, even if it doesn't get any better between now and the final release.

with this game in particular, i wanted to it to be satisfying to dodge enemy attacks and line up big hits, i wanted there to be enough enemy variety that the game was interesting to play even after i had practiced it a lot, and i wanted there to be enough enemy snowballing that i could get stuck in bad situations that i had to fight my way out of, instead of the only difficulty coming from overloading the screen with so many long-distance threats that i would randomly get hit by enemies i didn't notice.

once i got the mouse enemies working and i cranked up the difficulty of all the enemies to make sure that i can still make it fun for good players, i felt good about all those things. i still need to prototype some other mechanics (items, boss fights etc) and i'll probably try to make a public demo before i make the full game, but i at least feel good enough about the core melee combat mechanic that i can start working on those other things now.

Right so you mean literally if you had to stop developing mechanics altogether, you'd have a fun game on your hands? Yea that makes sense, I tend to build a lot of mechanics with hypothetical future use cases in mind which is a lot harder to get any kinda feel for since they don't exist ingame yet

really good stuff!! as someone who worked at a big studio and unfortunately ended up on many projects where management just pushed us into production when we clearly didn't have a compelling gameplay loop, it is hell on earth when it happens

in my experience you can often figure out if an idea is a flop fairly quickly, so starting again from scratch usually doesn't add too much time to pre-production. but if you reach the point where you have an entire team's worth of people with no game to work on, you messed up. ideally you could get them to temporarily work on a different game (if your studio makes multiple games at once), work on updates for a previous game, do contract work on another studio's game, or anything at all that you can find for them to do.

it's a difficult situation to be in and it's one of the reasons why companies cut pre-production short so often. but in my experience this is usually a side effect of a company not starting pre-production on the next game until the previous game is completely finished, at which point there's usually not enough time for a thorough prototyping phase regardless of how smoothly it goes.

on a technical level, do you have any advice for making a playable prototype? im working on a somewhat minimalist grand strategy game(well, maybe only minimalist relative to 95% of grand strategy games, haha) but its kind of difficult to imagine a time-efficient playable prototype in terms of code.

like ideally everything i code will be very modular, D.R.Y., etc but to get a prototype out in a reasonable amount of time i would probably make ad hoc code that is less modular/DRY, but im worried that making a prototype may make even that a lot more work than is worth it. unsure.

i guess if i make the code modular enough that can moderate the risk of "this fundamental thing needs to be thrown out or reworked", but hmm.

i think my situation may be more challenging on this front than average because its a type of game that is a bunch of interrelated systems, rather than a game that can rely on a core of fundamental movement+spatial mechanics that exist across a lot of genres and thus can utilize ad hoc libraries/placeholders as reasonable foundations because those already exist(i assume) in relative abundance for those genres. i might be wrong though. plus maybe the lack of Physics makes coding interrelations less cumbersome than i think outside of things like AI behavior

(also im thinking of making it in godot, if its relevant, but im still figuring that out. currently in the latter parts of the initial design+research stage)

i feel like this is lots of questions in one, so i'll try to unpack it and answer things from a few different angles. sorry if i'm misinterpreting what you were asking!

Q: how do i program games in general?

A: make lots of tiny games and get a feel for it! i personally use my own game engine and i program things in a very simple and straightforward procedural manner, with C structs, fixed-size arrays, for loops and not much else, but that's because i have lots of professional game/engine programming experience and i hate object-oriented programming. lots of other people prefer to use various engines or frameworks or programming languages or programming styles. just make sure you're programming in a way that makes it as easy as possible to modify aspects of your game, even beyond the prototyping stage.

Q: how do i program a game prototype?

A: same as above, but it's even more important that it's easy to modify aspects of the game.

Q: how do i decide what to prototype (if anything) for a game i want to make?

A: a prototype exists to help you decide what your game should be like, and whether or not you even want to make the game in the first place. so it heavily depends on what type of game you're making, how big it is, and how strict your personal standards are of what you want to make.

if you're making a tiny experimental game with low-fidelity assets, making the full game probably takes barely any more time than making a prototype so you might as well just make it all.

if you're someone like me who is weirdly obsessed with the exact nuances of action game mechanics and enemy design, you probably want to start by prototyping a room full of enemies that you can fight over and over while tweaking everything until you're satisfied (or until you decide that the game idea isn't as good as you thought it would be).

the above applies to basically every other genre too. start off by making sure that you like the most important part of your game enough for it to be worth making the full game, and then grow that prototype into a small version of the full game (e.g. a full level, boss encounters, rpg elements) to figure out exactly how the full game should work, then make the game.

Q: how do i decide what to prototype (if anything) for a grand strategy game?

A: i have never even played a grand strategy game, let alone thought about making one, so i'm not the best person to ask. i guess the questions to ask are which parts of your game idea you care about and what you would do if they ended up being bad. if you have a specific idea for some mechanics or vibes and you want to know if they're fun, you could throw together a pen/paper/dice prototype or make a quick and janky mod for an existing game. if you're determined to build a grand strategy game regardless of whether or not your current idea ends up being fun, then you might as well just start programming a grand strategy game. because even if your idea for a grand strategy game ends up not living up to your standards in practice, you can just reuse the code to make another one.

i'll use fighting games as an analogy, because we're both familiar with them and they also require lots of programming just to get a serviceable prototype up and running. if you knew that you wanted to dedicate lots of your life to making fighting games, you could go learn as much as possible about how other fighting games are put together and then start making your own fighting game while building your own framework or engine. but if you just had one specific idea for a fighting game that you wanted to try, you could throw something together in an existing fighting game framework, make a mod for an existing fighting game, or even just apply some house rules to an existing game and test it with your friends. like you could prototype divekick by playing mvc3 doom mirrors without dashing or blocking, and you could prototype a swordfighting anime fighting game with no jumps by playing johnny mirrors and never jumping.

so uh, do that. make whatever you need to make as quickly as possible that helps you figure out whether or not you like the game, while considering what you're likely to do next if the game idea doesn't live up to your standards. let me know if there's anything i didn't cover, and feel free to reach out via the contact info in my profile any time!

FWIW I program as a job so i'm pretty used to it in general (i also dislike object oriented programming, haha)

"are which parts of your game idea you care about and what you would do if they ended up being bad" is a good framing and i also appreciate the pen/paper/etc suggestion. the mod idea/house rules idea are also interesting. i'll try at least one of those to do prototyping, thank you!

in reply to @Jaelights's post:

that's really interesting! i've seen all sorts of of approaches towards composition: melody first, chord progression first, drums first, and so on. but whatever approach people use, it makes sense to have an approach and to try and figure out the arrangement as a whole instead of just refining one short section forever.