Forums

Hi =)

I think this is a good place to ask since some people in here already made some games. What is YOUR personal(!) way of preparing and organizing a development project? I'm almost sure there are industry standard ways to do this, and i'd be happy for links or any info as well =) One of my biggest flaws in life was often, to not be a good organizer. I changed much of that, and, regarding my plans and projects for the closer as well as the distant future, i want to be prepared! How much experience is needed to guess the amount of data one needs for realizing an idea into a game? I'm sure with experience this is easier, but as a newcomer, i'm logically kind of overwhelmed with data management. If i'm not mistaken, the hardest part of making a good functional game is A) data management and B) timing management, including interrupts and all. At least this seems to be the hardest part to me.. At the moment i feel like i'm at a point where it seems way to easy to be real - the only part that looks dangerous to me is data and time management. But i'm digressing slightly, this thread is not solely about this haha. I would be interested to see how other people deal with these hurdles, and of course i'd also be happy to get to know the standard industry approach, if there is/was one. I can imagine it's similiar to creating a movie, regarding preparations? For my own project (which will not be announced until i actually realize it - it WILL happen, just wait) i wrote story, game features etc first, and i am making 'art assets' aka music and graphics as well already. Basically i am trying to draft out the whole game first - it will work size wise because the game will not be a data muncher =) music and graphics will probably eat up all the precious bits and bytes, so it's easy to align and just remove or change one or two songs if it gets too close to the M A X .
I'm more worried about giant future projects, namely JRPGs regarding size and Danmaku Shoot 'em ups (come on, if NES can do Recca, we can also make something~) regarding timing..
I think this is enough text for now, nobody will answer if i overdo it ;) I'm excited to read some responses! =)

The assets should be flexible because you are likely to change them in response to system limitations, gameplay considerations and just your whims as things go on. It's far better to use placeholders - perhaps deliberately ugly ones - and get the game engine going first, because I'd contend that that part is way harder.

Once the engine is in place you can consider what CPU time is left for music and graphical effects. If certain effects are key to the game then they need to be factored in earlier - for example, significant video memory changes require careful analysis.

IMHO it's quite hard to discuss about these topics if you haven't the slightest idea of what all this means so I'd suggest you start your own small project and learn by trying. For instance I didn't get the importance of WLA-DX superfree sections until I realized I had too many assets to juggle all by myself. :|
Some hints I might anyway suggest are here: A few hints on coding a medium/large sized game using WLA-DX

Thanks for the answers!

Maxim, of course i do all the art stuff with the limitations being followed! I come from pixel art and chiptune, and am new to programming - not the other way around =)) For the project i have in mind now, this is okay (making all art assets inbefore and maybe changing one or two in the end), however when it comes to, for example, a giant JRPG, i will surely follow the path of dev-art placeholders =))

sverx, thank You for the link, i'll read it soon! Actually, i really have to read all important stuff about WLA-DX, i guess this will solve much of my data management confusion haha. However, as i stated in the opening post, this thread shouldn't be only about my current struggle with one or two things =))

I would really like to know how You guys prepare Yourself and the project! I'm sure there's quite a variation in how people do that.. from a cold, rational approach, to someone meditating and praying to a deity, haha. Of course, if You're a businessman and don't want to enclose Your secrets to success, i can understand ;)

Is there any making of an SMS game documented somehow? Maybe i should contact Mr. González (the arp master) and ask him if he can somehow reach someone from the Smurfs' SMS dev team from back then.

edit:
apparently he also did graphics for that game, says wiki.. and the music for tintin in tibet and spirou for game gear =O imo one of the 'best' composers from that time, guy put so much feeling and class into his tunes!

Klangfarbe wrote

I would really like to know how You guys prepare Yourself and the project! I'm sure there's quite a variation in how people do that..

Is there any making of an SMS game documented somehow?

When I made my first real SMS game, I documented it here: http://www.smspower.org/Articles/CreateARacingGame. It is super simple, and the coding style is not exactly industry standard :) - but it is a pretty honest account of the project.

To me, the challenge remains about keeping my code and assets clean and in order, so that I can build/tweak parts without breaking the game as a whole. I'm slowly brewing a game for next year's compo, but due to me getting a new job, I have not had the time to work on it for a couple of months. The real test will be to see if I left everything in such a clean state, that I can resume development swiftly :)

While I haven't made terribly complex games, I've found that a few things help:

- Make the build process simple and self describing. It ought to be possible to build the whole thing with one or two commands, including any transformation of assets (BMP2Tile)
- Write the code cleanly with descriptive section names and function names, and comments about both what you're doing (register use, blocks of a few instructions) and why you're doing it (larger scope comments)
- Make use of the assembler features to help you - superfree sections, memory enumeration, structures, macros (used sparingly) can all help make your code more expressive and easier to deal with when there's a lot of it. Always expect that the next poor soul to have to figure out the code with no clue about how it works will in fact be a future version of yourself.
- Learn the debugger features, you will have to debug a lot
- Learn your text editor's features, it drives me nuts when people don't take advantage of the tools they have in front of them.

Woah i just finished reading Rodnay Zaks' book =) Hooray!

Thanks for the input, guys! I will definitely read into everything - i think learning how to use WLA-DX is the next thing to be done now. I think regarding functions and stuff in games, i will always do flow charts and not continue until every possible bug is cleared haha. I will learn mah debuggerz but old wise Rodnay Zaks said that a good boy doing his flow charts will not have to debug as much as everyone else =) which sounds very logical imo.. Surely flags and all may conflict, but that's part of it i guess, can't help but fiddle and develop solutions =) I will also right away learn all about the VDP and the SN76489, as well as the YM2413 (and if nobody is faster i'll be the one to hack psglib into psgymlib =P). luckily psglib is all ASM and not some fancy high level language stuff, unless i'm totally mistaken now! Then again, we may just "borrow" the "sound driver" from valleybell's Sonic 1 FM hack and alter it a bit.. Maybe i should open another topic! But now now, now i'm going to bed, i read all night long haha!

Spend time building a good toolchain which makes changing/adding/rehashing stuff easy and authomatic. This is mandatory. Once that's done, development should be a breeze.

A setup which let's you edit a couple of pixels in a PNG file then recompile and get the changes without manual work is raw gold. Aim for that.

Zaks is overrated in my opinion, it is interesting as a historical artefact but we can do better now. Flow charts are a terrible way to design anything except perhaps a very small state machine, Master System games are more like real-time systems than application software on a home computer and the state machine model doesn't work well.

Thanks for the advice, guys! Maxim, do You also think flow charts are outdated for designing subprograms (ie game function stuff)? As a newcomer it feels like a good security to have!

I'm a software developer by profession and I've never felt the need.

IMO flow charts are fundamental when learning the basis of conditionals, iterations, and the such. Once you have learnt that, you no longer need to draw anything on paper, the flow it's in your brain :)

I guess I first learned that stuff in BASIC before I learned what a flow chart is, and assembly is even more low level because it's only jumps (GOTO) and calls (GOSUB). These are so explicit with the labels (line numbers) that the program flow can be pretty obvious. Of course, you can make things much more complicated, and assembly does make it easy to confuse yourself while building basic constructs like if/else.

Okay, i think i we can trust Maxim on that one haha. I also agree, sverx, flow charts are nice to learn things in any case =) The frequent use of them will probably really vanish slowly from time to time..

Game design? I had large number of classes on logic gates, discrete mathematics and computer architecture. Before I start a game I draw a state machine (I can't break the habit, sorry). The routine called when vblank occurs implements the state machine. It reads the game state, then calls the subroutine needed to process that state. It also helps divide up the work, as I usually only get an hour or two to write game code per day, if that.

Something that helps me specifically with games is keeping the code and the content separated. Ideally, the same code runs every level. The content is simply different in each level. This makes the code development up front a bit more difficult. But once you finish then you can just focus on level design or content development. Level design is not as trivial as you might think.

Author	Message
Klangfarbe Joined: 21 Oct 2010 Posts: 47 Location: Space	Game development preparations/organization/etc Posted: Wed Oct 12, 2016 5:01 am
Klangfarbe Joined: 21 Oct 2010 Posts: 47 Location: Space	Hi =) I think this is a good place to ask since some people in here already made some games. What is YOUR personal(!) way of preparing and organizing a development project? I'm almost sure there are industry standard ways to do this, and i'd be happy for links or any info as well =) One of my biggest flaws in life was often, to not be a good organizer. I changed much of that, and, regarding my plans and projects for the closer as well as the distant future, i want to be prepared! How much experience is needed to guess the amount of data one needs for realizing an idea into a game? I'm sure with experience this is easier, but as a newcomer, i'm logically kind of overwhelmed with data management. If i'm not mistaken, the hardest part of making a good functional game is A) data management and B) timing management, including interrupts and all. At least this seems to be the hardest part to me.. At the moment i feel like i'm at a point where it seems way to easy to be real - the only part that looks dangerous to me is data and time management. But i'm digressing slightly, this thread is not solely about this haha. I would be interested to see how other people deal with these hurdles, and of course i'd also be happy to get to know the standard industry approach, if there is/was one. I can imagine it's similiar to creating a movie, regarding preparations? For my own project (which will not be announced until i actually realize it - it WILL happen, just wait) i wrote story, game features etc first, and i am making 'art assets' aka music and graphics as well already. Basically i am trying to draft out the whole game first - it will work size wise because the game will not be a data muncher =) music and graphics will probably eat up all the precious bits and bytes, so it's easy to align and just remove or change one or two songs if it gets too close to the M A X . I'm more worried about giant future projects, namely JRPGs regarding size and Danmaku Shoot 'em ups (come on, if NES can do Recca, we can also make something~) regarding timing.. I think this is enough text for now, nobody will answer if i overdo it ;) I'm excited to read some responses! =)

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14747 Location: London	Posted: Wed Oct 12, 2016 5:56 am
	The assets should be flexible because you are likely to change them in response to system limitations, gameplay considerations and just your whims as things go on. It's far better to use placeholders - perhaps deliberately ugly ones - and get the game engine going first, because I'd contend that that part is way harder. Once the engine is in place you can consider what CPU time is left for music and graphical effects. If certain effects are key to the game then they need to be factored in earlier - for example, significant video memory changes require careful analysis.

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Wed Oct 12, 2016 7:33 am
	IMHO it's quite hard to discuss about these topics if you haven't the slightest idea of what all this means so I'd suggest you start your own small project and learn by trying. For instance I didn't get the importance of WLA-DX superfree sections until I realized I had too many assets to juggle all by myself. :\| Some hints I might anyway suggest are here: A few hints on coding a medium/large sized game using WLA-DX

Klangfarbe Joined: 21 Oct 2010 Posts: 47 Location: Space	Posted: Wed Oct 12, 2016 3:30 pm
Klangfarbe Joined: 21 Oct 2010 Posts: 47 Location: Space	Thanks for the answers! Maxim, of course i do all the art stuff with the limitations being followed! I come from pixel art and chiptune, and am new to programming - not the other way around =)) For the project i have in mind now, this is okay (making all art assets inbefore and maybe changing one or two in the end), however when it comes to, for example, a giant JRPG, i will surely follow the path of dev-art placeholders =)) sverx, thank You for the link, i'll read it soon! Actually, i really have to read all important stuff about WLA-DX, i guess this will solve much of my data management confusion haha. However, as i stated in the opening post, this thread shouldn't be only about my current struggle with one or two things =)) I would really like to know how You guys prepare Yourself and the project! I'm sure there's quite a variation in how people do that.. from a cold, rational approach, to someone meditating and praying to a deity, haha. Of course, if You're a businessman and don't want to enclose Your secrets to success, i can understand ;) Is there any making of an SMS game documented somehow? Maybe i should contact Mr. González (the arp master) and ask him if he can somehow reach someone from the Smurfs' SMS dev team from back then. edit: apparently he also did graphics for that game, says wiki.. and the music for tintin in tibet and spirou for game gear =O imo one of the 'best' composers from that time, guy put so much feeling and class into his tunes!

hang-on Joined: 23 Mar 2013 Posts: 611 Location: Copenhagen, Denmark	Posted: Wed Oct 12, 2016 8:23 pm
	Klangfarbe wrote I would really like to know how You guys prepare Yourself and the project! I'm sure there's quite a variation in how people do that.. Is there any making of an SMS game documented somehow? When I made my first real SMS game, I documented it here: http://www.smspower.org/Articles/CreateARacingGame. It is super simple, and the coding style is not exactly industry standard :) - but it is a pretty honest account of the project. To me, the challenge remains about keeping my code and assets clean and in order, so that I can build/tweak parts without breaking the game as a whole. I'm slowly brewing a game for next year's compo, but due to me getting a new job, I have not had the time to work on it for a couple of months. The real test will be to see if I left everything in such a clean state, that I can resume development swiftly :)

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14747 Location: London	Posted: Wed Oct 12, 2016 9:06 pm
	While I haven't made terribly complex games, I've found that a few things help: - Make the build process simple and self describing. It ought to be possible to build the whole thing with one or two commands, including any transformation of assets (BMP2Tile) - Write the code cleanly with descriptive section names and function names, and comments about both what you're doing (register use, blocks of a few instructions) and why you're doing it (larger scope comments) - Make use of the assembler features to help you - superfree sections, memory enumeration, structures, macros (used sparingly) can all help make your code more expressive and easier to deal with when there's a lot of it. Always expect that the next poor soul to have to figure out the code with no clue about how it works will in fact be a future version of yourself. - Learn the debugger features, you will have to debug a lot - Learn your text editor's features, it drives me nuts when people don't take advantage of the tools they have in front of them.

Klangfarbe Joined: 21 Oct 2010 Posts: 47 Location: Space	Posted: Thu Oct 13, 2016 2:35 am
Klangfarbe Joined: 21 Oct 2010 Posts: 47 Location: Space	Woah i just finished reading Rodnay Zaks' book =) Hooray! Thanks for the input, guys! I will definitely read into everything - i think learning how to use WLA-DX is the next thing to be done now. I think regarding functions and stuff in games, i will always do flow charts and not continue until every possible bug is cleared haha. I will learn mah debuggerz but old wise Rodnay Zaks said that a good boy doing his flow charts will not have to debug as much as everyone else =) which sounds very logical imo.. Surely flags and all may conflict, but that's part of it i guess, can't help but fiddle and develop solutions =) I will also right away learn all about the VDP and the SN76489, as well as the YM2413 (and if nobody is faster i'll be the one to hack psglib into psgymlib =P). luckily psglib is all ASM and not some fancy high level language stuff, unless i'm totally mistaken now! Then again, we may just "borrow" the "sound driver" from valleybell's Sonic 1 FM hack and alter it a bit.. Maybe i should open another topic! But now now, now i'm going to bed, i read all night long haha!

na_th_an Joined: 07 Oct 2015 Posts: 114	Posted: Fri Oct 14, 2016 8:42 am
na_th_an Joined: 07 Oct 2015 Posts: 114	Spend time building a good toolchain which makes changing/adding/rehashing stuff easy and authomatic. This is mandatory. Once that's done, development should be a breeze. A setup which let's you edit a couple of pixels in a PNG file then recompile and get the changes without manual work is raw gold. Aim for that.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14747 Location: London	Posted: Fri Oct 14, 2016 7:55 pm
	Zaks is overrated in my opinion, it is interesting as a historical artefact but we can do better now. Flow charts are a terrible way to design anything except perhaps a very small state machine, Master System games are more like real-time systems than application software on a home computer and the state machine model doesn't work well.

Klangfarbe Joined: 21 Oct 2010 Posts: 47 Location: Space	Posted: Wed Oct 19, 2016 6:14 am
Klangfarbe Joined: 21 Oct 2010 Posts: 47 Location: Space	Thanks for the advice, guys! Maxim, do You also think flow charts are outdated for designing subprograms (ie game function stuff)? As a newcomer it feels like a good security to have!

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14747 Location: London	Posted: Wed Oct 19, 2016 2:53 pm
	I'm a software developer by profession and I've never felt the need.

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Wed Oct 19, 2016 7:45 pm
	IMO flow charts are fundamental when learning the basis of conditionals, iterations, and the such. Once you have learnt that, you no longer need to draw anything on paper, the flow it's in your brain :)

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14747 Location: London	Posted: Fri Oct 21, 2016 10:05 am
	I guess I first learned that stuff in BASIC before I learned what a flow chart is, and assembly is even more low level because it's only jumps (GOTO) and calls (GOSUB). These are so explicit with the labels (line numbers) that the program flow can be pretty obvious. Of course, you can make things much more complicated, and assembly does make it easy to confuse yourself while building basic constructs like if/else.

Klangfarbe Joined: 21 Oct 2010 Posts: 47 Location: Space	Posted: Fri Oct 21, 2016 5:29 pm
Klangfarbe Joined: 21 Oct 2010 Posts: 47 Location: Space	Okay, i think i we can trust Maxim on that one haha. I also agree, sverx, flow charts are nice to learn things in any case =) The frequent use of them will probably really vanish slowly from time to time..

dragonfeet Joined: 08 Oct 2012 Posts: 108 Location: Colmar PA, United States	Posted: Sun Oct 23, 2016 2:57 am
	Game design? I had large number of classes on logic gates, discrete mathematics and computer architecture. Before I start a game I draw a state machine (I can't break the habit, sorry). The routine called when vblank occurs implements the state machine. It reads the game state, then calls the subroutine needed to process that state. It also helps divide up the work, as I usually only get an hour or two to write game code per day, if that. Something that helps me specifically with games is keeping the code and the content separated. Ideally, the same code runs every level. The content is simply different in each level. This makes the code development up front a bit more difficult. But once you finish then you can just focus on level design or content development. Level design is not as trivial as you might think.

Forums

View topic - Game development preparations/organization/etc