Hello,

I'm Dave, thank you for having me on your forum. I am making a video game (RPG) and I am here for guidance. Preproduction is largely complete so I've begun learning how to actually put this thing together so I can make a demo. I am essentially new to coding (my only languages before this project were HTML, Applescript, and some javascript). I know to read and write as much as I can, but I don't know where to begin. I intended to lurk moar before posting, but then realized I'd no idea what terms to search.

So far, I'm learning Unity (and thus C#) because the distribution platform looks dope, but am considering a switch to Unreal (which uses C++ if I'm not mistaken). I don't know how to ascertain which better suits my work. I have a cube that walks via arrow keys and the game saves his stats and inventory as a binary string. I learned from tutorials (and debugging my transcription errors), but I am still dissecting the roles of different objects and functions and don't fully comprehend why what I've written works.

Currently I'm seeking to create NPCs the player can walk up to and interact with, making dialog choices that affect other dialog options with other NPCs. I also want to ask people who know more than me, is C# a good language for that sort of thing? Are there others I should be learning instead or as well? I've heard that XML is good for storing inventory and character sheets.

Being a n00b is hard. I know that I am taking on a large project for a complete beginner, but as a man of boundless optimism I welcome the challenge. If you can point me in any direction it would be greatly appreciated.

Love and kisses,

Electrik Dave

xoxo

Edit: I have discovered the FAQ since posting this, apologize for posting before reading it, and still welcome any guidance. Especially with dialog choices.

Love and Kittens,

Dave

Hi,

So far, I'm learning Unity (and thus C#) because the distribution platform looks dope, but am considering a switch to Unreal (which uses C++ if I'm not mistaken). I don't know how to ascertain which better suits my work.

Unity vs Unreal there are some differences but from what you said you're planning to make it can be done in either and if you have already started learning Unity I would say stick with it. One point to make, Unreal 4 does allow you to use Blueprints as well as C++ whereas Unity doesn't have anything like that.

is C# a good language for that sort of thing? Are there others I should be learning instead or as well? I've heard that XML is good for storing inventory and character sheets.

As for C# vs C++, you can achieve what you would like to do with both languages, how you save your inventory you might want to think about - do you want to keep writing it to a file and reading it again every time you want to access it? Or would you rather just save it to an XML, custom format or whatever file when the player saves and quits the game and load it once when they load the game, meaning you keep track of what's in the inventory in some gameobject?

I am essentially new to coding (my only languages before this project were HTML, Applescript, and some javascript). I know to read and write as much as I can, but I don't know where to begin. I intended to lurk moar before posting, but then realized I'd no idea what terms to search.

As for which languages you should know, depends on who you ask, personally I would say knowing C++ or/and C# is useful and once you know one you can learn the other fairly quickly. Same if you know C++ you know a lot a C, just some small details you need to learn about.

If you can point me in any direction it would be greatly appreciated.

First, work out what game engine you want to use, then learn the basics of the engine and the language that it supports (i.e. C++ or C#).

Second, I would just build a small project to play around with how the game engine works before starting on your game. You might find the structure of the game engine might affect your current game design.

Third, Version Control! Git, SVN and many more out there. If you are programming this is super important and engines support some version control systems (I know they both support Git).

Four, Start on making your game and have fun.

Thanks for the reply L,

I've been using Unity so far, but I am getting the sense that Unreal is more powerful so I think I may switch. I have a demo project in Unity that I want to finish though. I've made a few scenes and a world map, and I am working to discover how I can create dialog with NPCs. Like "Go tell X to that guy over there then come back" and then when you talk to the guy over there, the first guy's dialog changes to something like "thanks for telling him for me." Once I learn that I can build a small game and play around with the fine tuning until I know the program well, but I don't know what to search for.

It sounds to me like you are saying C++ and Unreal may be a better long-term plan, and Unity a better short term plan.

As far as Inventory, I would like to have one file that contains the information about character level and stats, inventory, player choices, and a variety of other variables. I learn best from dissecting working code, but I don't know where to find example code from games like this.

What search terms do you recommend for saving and for dialog?

So far, I'm learning Unity (and thus C#) because the distribution platform looks dope, but am considering a switch to Unreal (which uses C++ if I'm not mistaken). I don't know how to ascertain which better suits my work.

They're actually pretty similar. On one layer you have the actual engine, the engine being code that provides all the base functionality for your game. Then you have a suite of content creation tools to actually assemble a "game" which is just a bunch of data the engine loads and works with. It's not that different from something like game maker when you boil it down to it. As for which to pick that kinda depends on the needs of your game. Unity probably is easier to pick up for people that have never coded before because it's more marketed towards that group and has a lot of supporting information. Unreal is pretty nice too though, it's arguably designed to be more industrial grade than unity, which is why you see very graphically demanding games use it a lot.

I have a cube that walks via arrow keys and the game saves his stats and inventory as a binary string. I learned from tutorials (and debugging my transcription errors), but I am still dissecting the roles of different objects and functions and don't fully comprehend why what I've written works.

Arguably you can think of saving as being completely distinct from normal gameplay. Your normal gameplay will be manipulating data that's loaded into memory and saving is just you "backing up" that data to be loaded again later.

I also want to ask people who know more than me, is C# a good language for that sort of thing? Are there others I should be learning instead or as well?

People often bring up game engines using certain languages for scripting like it should affect their decision, but frankly it shouldn't really. Scripting with a language is rather different from using it for pure programming, you'll often have a limited selection of logic you need to code for and don't have to think about the big picture very often. It's sort of like knowing enough English to count and read basic math word problems vs knowing enough English to write a novel. Although you often CAN use in depth features of the language for scripting you generally do not need to.

I've heard that XML is good for storing inventory and character sheets.

Going back to what I said about saving, saving is really just taking data in RAM and dumping it into longterm storage. XML is just a format for how to read/write the data. You could just as easily dump out all the data as binary then read it back in, well, "easily" anyway. The main advantage of formats like xml is both to make them human readable-easy to edit, and to give convenient structure to the file so it's easy to save and load certain parts of the data. These things also depend on what you're using to write files too though. I assume unity has built in functionality for serializing things so they might have all the code already written to easily read or write different kinds of files. I'm not a unity expert so I couldn't advise on that directly.

I've been using Unity so far, but I am getting the sense that Unreal is more powerful so I think I may switch.

You certainly CAN switch but I'd be highly suspect that many of Unreal's power selling points will affect anything you make at all, unless you suddenly form a large capable team.

I've made a few scenes and a world map, and I am working to discover how I can create dialog with NPCs. Like "Go tell X to that guy over there then come back" and then when you talk to the guy over there, the first guy's dialog changes to something like "thanks for telling him for me." Once I learn that I can build a small game and play around with the fine tuning until I know the program well, but I don't know what to search for.

Alas you've hit one of the pitfalls of game development, it's often not clear how something really works until you try to create it. Game development definitely benefits from experience on making different systems. Your best bet to figure it out is to try and break the goal into different tasks you need to accomplish. Like you know you'll have to detect when you're near an NPC and change into some sort of "chatting" state, that pops up the dialogue and stops your input from moving your character. You'll also have to tell the game what dialogue to actually display(loading it based on npc id or something.) The hardest part is figuring out those steps when you aren't familiar with them.

As far as Inventory, I would like to have one file that contains the information about character level and stats, inventory, player choices, and a variety of other variables. I learn best from dissecting working code, but I don't know where to find example code from games like this.

There aren't any "rules" for writing save files and trust me, every game uses a million different versions. Some games save everything into one giant file, some games save almost every object and its position and some only save character data and reset everything else. I will say usually everything gets stuck in one file for a "save" though, for simplicity sake. Think about the use pattern, if you'll be loading it all at once when you load a game then it probably should all be in the same place.

So far, I'm learning Unity (and thus C#) because the distribution platform looks dope, but am considering a switch to Unreal (which uses C++ if I'm not mistaken). I don't know how to ascertain which better suits my work.

They're actually pretty similar. On one layer you have the actual engine, the engine being code that provides all the base functionality for your game. Then you have a suite of content creation tools to actually assemble a "game" which is just a bunch of data the engine loads and works with. It's not that different from something like game maker when you boil it down to it. As for which to pick that kinda depends on the needs of your game. Unity probably is easier to pick up for people that have never coded before because it's more marketed towards that group and has a lot of supporting information. Unreal is pretty nice too though, it's arguably designed to be more industrial grade than unity, which is why you see very graphically demanding games use it a lot.

The reason I originally chose Unity is their distribution. I want as many people to have access to my game as possible once it's done. But it's tough because if Unreal can do enough more, it might draw more people to the game. It's a quandary I'm sure many here have battled. Either way I have to learn to code in the native language of the engine I choose.

I have a cube that walks via arrow keys and the game saves his stats and inventory as a binary string. I learned from tutorials (and debugging my transcription errors), but I am still dissecting the roles of different objects and functions and don't fully comprehend why what I've written works.

Arguably you can think of saving as being completely distinct from normal gameplay. Your normal gameplay will be manipulating data that's loaded into memory and saving is just you "backing up" that data to be loaded again later.

That makes sense. I'm still not sure how stuff gets from my code into memory, but I am able to give my "player" stats that can be recalled later by another script, so I know I am doing it. I assume this is managed by the engine, but I know soon I will need to learn to make save points or auto-save. I'm still working on battling and dialog, because without leveling or making choices there's nothing to save.

I also want to ask people who know more than me, is C# a good language for that sort of thing? Are there others I should be learning instead or as well?

People often bring up game engines using certain languages for scripting like it should affect their decision, but frankly it shouldn't really. Scripting with a language is rather different from using it for pure programming, you'll often have a limited selection of logic you need to code for and don't have to think about the big picture very often. It's sort of like knowing enough English to count and read basic math word problems vs knowing enough English to write a novel. Although you often CAN use in depth features of the language for scripting you generally do not need to.

This makes sense. I feel like whichever language I use, once it clicks I will learn as much about it as I can, as that's how I generally am with things, but I don't want to underestimate my project and wind up having to rewrite everything.

I've heard that XML is good for storing inventory and character sheets.

Going back to what I said about saving, saving is really just taking data in RAM and dumping it into longterm storage. XML is just a format for how to read/write the data. You could just as easily dump out all the data as binary then read it back in, well, "easily" anyway. The main advantage of formats like xml is both to make them human readable-easy to edit, and to give convenient structure to the file so it's easy to save and load certain parts of the data. These things also depend on what you're using to write files too though. I assume unity has built in functionality for serializing things so they might have all the code already written to easily read or write different kinds of files. I'm not a unity expert so I couldn't advise on that directly.

Would you say XML is a good way to store things like current Level/HP/MP/Exp/Gold/Inventory? I wanted originally to write the game in a manner in which I can look at one file and read all the stats/player choices etc. I assume other scripts throughout playing would modify this file, like a int for current gold, or a bool for like didTalkToWizardinCave could be true or false and you can read that file to see what choice the player made. I am not sure if one file is the best place for all of this anymore though. What do you think?

I've been using Unity so far, but I am getting the sense that Unreal is more powerful so I think I may switch.

You certainly CAN switch but I'd be highly suspect that many of Unreal's power selling points will affect anything you make at all, unless you suddenly form a large capable team.

My concern is if I eventually will want to. I know which point in the game I must write by myself to demo, but I will be expanding the project to include more people once it's playable up to a certain level. I want to make sure that once I start growing the project I don't find myself wishing I had chosen differently.

I've made a few scenes and a world map, and I am working to discover how I can create dialog with NPCs. Like "Go tell X to that guy over there then come back" and then when you talk to the guy over there, the first guy's dialog changes to something like "thanks for telling him for me." Once I learn that I can build a small game and play around with the fine tuning until I know the program well, but I don't know what to search for.

Alas you've hit one of the pitfalls of game development, it's often not clear how something really works until you try to create it. Game development definitely benefits from experience on making different systems. Your best bet to figure it out is to try and break the goal into different tasks you need to accomplish. Like you know you'll have to detect when you're near an NPC and change into some sort of "chatting" state, that pops up the dialogue and stops your input from moving your character. You'll also have to tell the game what dialogue to actually display(loading it based on npc id or something.) The hardest part is figuring out those steps when you aren't familiar with them.

Yeah, right now I'm making an invisible collider around each NPC, and I'm trying to write it so if you GetKey while in the collider it will launch the dialog sequence associated with that collider/NPC. I'm sure once I get it to remember one player choice and make that affect a second conversation, I'll be able to write the entire game's story and build the whole world.

As far as Inventory, I would like to have one file that contains the information about character level and stats, inventory, player choices, and a variety of other variables. I learn best from dissecting working code, but I don't know where to find example code from games like this.

There aren't any "rules" for writing save files and trust me, every game uses a million different versions. Some games save everything into one giant file, some games save almost every object and its position and some only save character data and reset everything else. I will say usually everything gets stuck in one file for a "save" though, for simplicity sake. Think about the use pattern, if you'll be loading it all at once when you load a game then it probably should all be in the same place.

That's a lot to think about. I never thought about saving whether each chest that's out in the wild has been opened, or whether the character has spoken to an NPC yet or not. I'm going to have to I guess first figure out how to make an NPC that says one thing the first time you speak to them, and then something different every time after that.

Do you know what a good resource is to read scripts that do something like this, or to learn what functions I must understand to write this stuff?

The reason I originally chose Unity is their distribution. I want as many people to have access to my game as possible once it's done. But it's tough because if Unreal can do enough more, it might draw more people to the game. It's a quandary I'm sure many here have battled. Either way I have to learn to code in the native language of the engine I choose.

Well it's up to you really, you could look at the features of both and try and get an idea of what would benefit you more.

That makes sense. I'm still not sure how stuff gets from my code into memory, but I am able to give my "player" stats that can be recalled later by another script, so I know I am doing it.

Without going into a huge rant with traditional code the goal is to turn a text file(source code) into machine code(numbers in memory that act as instructions the CPU can run.) There are different ways of getting to that goal, scripts are basically text files that use the rules of a certain language(C# for example) but other than that they are just text files. The goal is for the game engine to take your script and use some wizardry to make it execute machine instructions at the endpoint.

Pretty much all data the computer is working with is in memory, the CPU reads instructions and executes them. Maybe it reads a number from a spot in memory, adds a number to it, then sets that memory to the resulting number. In scripts you're essentially reserving a space in memory whenever you create a variable. Int i = 3; In most languages that gives you a chunk of memory of size int and sets it to value 3. Code is literally just millions of math instructions modifying memory. When you play a game anything that you can see is currently loaded into memory, any number is a game is either loaded in memory or has to be grabbed from storage before you use it(a very slow process.)

but I know soon I will need to learn to make save points or auto-save. I'm still working on battling and dialog, because without leveling or making choices there's nothing to save.

Everything is essentially broken up into functions in most modern programming languages. Functions being blocks of code that you can "jump to" and run and then jump back when you're finished. Scripts follow the same premise, you might write some code somewhere to save your game data, then you can call that code whenever you get into a situation where you need to save the data. Maybe your character just collided with a save point then he clicked yes on a dialogue box, the dialogue box could call your save code. You can think of code as building blocks.

This makes sense. I feel like whichever language I use, once it clicks I will learn as much about it as I can, as that's how I generally am with things, but I don't want to underestimate my project and wind up having to rewrite everything.

Honestly a lot of this stuff has to be learned by experience, you will end up writing awful code and rewriting things because coding is so deep that you often have to write something before you understand what you could have done better with it. It's like cooking, you can teach anyone the basics of cooking but it takes experience to know how to cut up, cook and season the perfect roast chicken.

Would you say XML is a good way to store things like current Level/HP/MP/Exp/Gold/Inventory? I wanted originally to write the game in a manner in which I can look at one file and read all the stats/player choices etc.

Just pick something and do it and see how it works. A lot of people(myself included) start coding with this attitude of "I have to do everything the best way/efficiently" after awhile you learn that getting the thing working is the basic and most important goal. Unless you have some reason you think multiple files is better, why not shove it all in one file? You can always change it later. As for XML, usually that just depends on your personal taste and what kind of data you're storing. Unity might offer prewritten code you can call that writes files in different formats. XML and JSON are probably the most generally used text formats.

I assume other scripts throughout playing would modify this file, like a int for current gold, or a bool for like didTalkToWizardinCave could be true or false and you can read that file to see what choice the player made. I am not sure if one file is the best place for all of this anymore though. What do you think?

No! Well, not quite anyway. That was what I was trying to get across, you don't want multiple scripts modifying one file, you want the data to -stay- in memory. When you start a new game or load a game you have an int somewhere representing gold amount, you either set this to a starter value or you load that value from storage. When code adjusts your gold amount it is adjusting the number in memory, not a file. It could take 10,000x longer to open a file and read that int, modify it and save it then it would to just keep changing it in memory.

My concern is if I eventually will want to. I know which point in the game I must write by myself to demo, but I will be expanding the project to include more people once it's playable up to a certain level. I want to make sure that once I start growing the project I don't find myself wishing I had chosen differently.

It's good to question but don't let it paralyze you, I can almost guarantee you will not find any feature between both engines that will ever make you want to port the entire thing after you've made any decent amount of content. You'll just work around it.

That's a lot to think about. I never thought about saving whether each chest that's out in the wild has been opened, or whether the character has spoken to an NPC yet or not. I'm going to have to I guess first figure out how to make an NPC that says one thing the first time you speak to them, and then something different every time after that.

It makes sense when you think about it. What if you opened a chest in a map an hour ago, saved your game 5 minutes ago then your game crashed and you had to load it up again. How would it know you opened that chest if it doesn't read it from a file? Anything you don't save to storage is lost when your program ends, just like everything in ram is lost if your computer shuts off. On the bright side you can save data like that pretty cheaply, something like a chest id and a true or false if it is opened. A few MB text file can contain massive levels of information, if its binary you can fit even more.

Do you know what a good resource is to read scripts that do something like this, or to learn what functions I must understand to write this stuff?

Google is the coder's friend, honestly it's hard to find how something works on demand. Often if I don't know how to do something I can spend many hours researching it, prototyping it, looking at games that do something similar. It's part of why knowledge is so powerful in game dev, when you know how to assemble something you can throw it together very quickly in the future. If you don't it's a big chore. Unity related sites will probably help you a lot with specifics, google can help with concepts.

The reason I originally chose Unity is their distribution. I want as many people to have access to my game as possible once it's done. But it's tough because if Unreal can do enough more, it might draw more people to the game. It's a quandary I'm sure many here have battled. Either way I have to learn to code in the native language of the engine I choose.

Well it's up to you really, you could look at the features of both and try and get an idea of what wouldbenefit you more.

Thanks.

That makes sense. I'm still not sure how stuff gets from my code into memory, but I am able to give my "player" stats that can be recalled later by another script, so I know I am doing it.

Without going into a huge rant with traditional code the goal is to turn a text file(source code) into machine code(numbers in memory that act as instructions the CPU can run.) There are different ways of getting to that goal, scripts are basically text files that use the rules of a certain language(C# for example) but other than that they are just text files. The goal is for the game engine to take your script and use some wizardry to make it execute machine instructions at the endpoint.

Pretty much all data the computer is working with is in memory, the CPU reads instructions and executes them. Maybe it reads a number from a spot in memory, adds a number to it, then sets that memory to the resulting number. In scripts you're essentially reserving a space in memory whenever you create a variable. Int i = 3; In most languages that gives you a chunk of memory of size int and sets it to value 3. Code is literally just millions of math instructions modifying memory. When you play a game anything that you can see is currently loaded into memory, any number is a game is either loaded in memory or has to be grabbed from storage before you use it(a very slow process.)

I guess the part that's hard for me is learning to relate to memory vs storage. I've only ever worked with storage directly before coding, so I don't really know what the save data will be doing while it is "in memory."

but I know soon I will need to learn to make save points or auto-save. I'm still working on battling and dialog, because without leveling or making choices there's nothing to save.

Everything is essentially broken up into functions in most modern programming languages. Functions being blocks of code that you can "jump to" and run and then jump back when you're finished. Scripts follow the same premise, you might write some code somewhere to save your game data, then you can call that code whenever you get into a situation where you need to save the data. Maybe your character just collided with a save point then he clicked yes on a dialogue box, the dialogue box could call your save code. You can think of code as building blocks.

I think learning the terms, like function vs object vs method etc is a pretty fundamental starting point, but remarkably more difficult to search for online than I had anticipated. Perhaps again this is a case of my not knowing what terms specifically to query.

This makes sense. I feel like whichever language I use, once it clicks I will learn as much about it as I can, as that's how I generally am with things, but I don't want to underestimate my project and wind up having to rewrite everything.

Honestly a lot of this stuff has to be learned by experience, you will end up writing awful code and rewriting things because coding is so deep that you often have to write something before you understand what you could have done better with it. It's like cooking, you can teach anyone the basics of cooking but it takes experience to know how to cut up, cook and season the perfect roast chicken.

Does everyone write every game they make from total scratch and testing, or are there techniques that have become sort of the common way of doing things? In my native art (Music) there are no real "rules" per se, but the ways to do many things in production and engineering have become largely standardized.

Would you say XML is a good way to store things like current Level/HP/MP/Exp/Gold/Inventory? I wanted originally to write the game in a manner in which I can look at one file and read all the stats/player choices etc.

Just pick something and do it and see how it works. A lot of people(myself included) start coding with this attitude of "I have to do everything the best way/efficiently" after awhile you learn that getting the thing working is the basic and most important goal. Unless you have some reason you think multiple files is better, why not shove it all in one file? You can always change it later. As for XML, usually that just depends on your personal taste and what kind of data you're storing. Unity might offer prewritten code you can call that writes files in different formats. XML and JSON are probably the most generally used text formats.

Ok, I suppose then I'll seek resources for those, although if Binary is faster maybe that's the best.

I assume other scripts throughout playing would modify this file, like a int for current gold, or a bool for like didTalkToWizardinCave could be true or false and you can read that file to see what choice the player made. I am not sure if one file is the best place for all of this anymore though. What do you think?

No! Well, not quite anyway. That was what I was trying to get across, you don't want multiple scripts modifying one file, you want the data to -stay- in memory. When you start a new game or load a game you have an int somewhere representing gold amount, you either set this to a starter value or you load that value from storage. When code adjusts your gold amount it is adjusting the number in memory, not a file. It could take 10,000x longer to open a file and read that int, modify it and save it then it would to just keep changing it in memory.

So everything is in memory until we hit a save point. That makes sense, obviously. Maybe I can find a save point script I can read.

My concern is if I eventually will want to. I know which point in the game I must write by myself to demo, but I will be expanding the project to include more people once it's playable up to a certain level. I want to make sure that once I start growing the project I don't find myself wishing I had chosen differently.

It's good to question but don't let it paralyze you, I can almost guarantee you will not find any feature between both engines that will ever make you want to port the entire thing after you've made any decent amount of content. You'll just work around it.

The graphic capabilities of Unreal seem to be greater, which is honestly the only reason I would use it over Unity, since Unity has way better distribution.

That's a lot to think about. I never thought about saving whether each chest that's out in the wild has been opened, or whether the character has spoken to an NPC yet or not. I'm going to have to I guess first figure out how to make an NPC that says one thing the first time you speak to them, and then something different every time after that.

It makes sense when you think about it. What if you opened a chest in a map an hour ago, saved your game 5 minutes ago then your game crashed and you had to load it up again. How would it know you opened that chest if it doesn't read it from a file? Anything you don't save to storage is lost when your program ends, just like everything in ram is lost if your computer shuts off. On the bright side you can save data like that pretty cheaply, something like a chest id and a true or false if it is opened. A few MB text file can contain massive levels of information, if its binary you can fit even more.

So every chest, NPC, etc needs an ID? That's extremely helpful. Any examples of how to format something like this to keep it organized?

Do you know what a good resource is to read scripts that do something like this, or to learn what functions I must understand to write this stuff?

Google is the coder's friend, honestly it's hard to find how something works on demand. Often if I don't know how to do something I can spend many hours researching it, prototyping it, looking at games that do something similar. It's part of why knowledge is so powerful in game dev, when you know how to assemble something you can throw it together very quickly in the future. If you don't it's a big chore. Unity related sites will probably help you a lot with specifics, google can help with concepts.

What I am looking for specifically are examples of code that work which I can read to disassemble and understand.

I've only ever worked with storage directly before coding, so I don't really know what the save data will be doing while it is "in memory."

Every variable or object in your code is 'in memory'. The save data is just a persistent store where this information can live when the code isn't running.

if Binary is faster maybe that's the best

No, stick with XML if you know how to use it.

Does everyone write every game they make from total scratch and testing, or are there techniques that have become sort of the common way of doing things? In my native art (Music) there are no real "rules" per se, but the ways to do many things in production and engineering have become largely standardized.

The issue is that you have to start at the bottom before you can understand the conventions. Trying to ask experienced developers about their methods when you're just starting out is going to end up with you buried under a sea of terms that mean little. It would be like a new musician asking someone else how they write music and they talk about how they like to use rondo form for their compositions with liberal use of phrygian cadences - if you just picked up a guitar yesterday you don't know what "rondo", "form", "phrygian", or "cadence" means yet. But after some time and self-directed study, those things will start to make more sense.

(Despite the term 'software engineering', coding games is much more like the composition aspect of music than the mixing/mastering/engineering aspect.)

Your music analogy is helpful. To expand on the analogy, let's say I'm learning to play and write on piano. Right now I am just sitting at it hitting keys, and sometimes playing along to the radio. I am trying to find copies of sheet music to read so I can study what the different composers have done.


I understood it that writing the parts of the game like characters, story, events, villains, game environment et cetera is more like the composition aspect, and the coding would be more like the sequencing, recording, editing and mixing part of the project. The part that goes unseen but takes it from being an idea in your head to a sellable phonorecord.

Obviously there is a knowledge gap to bridge here for me. I want to know how to find working code to read so I can study, or a resource for learning basics other than "you just gotta keep trying." Back to the piano analogy, someone might recommend I work the Hannon book, or practice the Inventions, or maybe send me a link to some MIDI files I can deconstruct, or like jwpepper.com to get some sheets to look at.

Is there a way to like dismantle a game to read its code? Are there common techniques used for things like Saving? I would imagine for example Final Fantasy V and Final Fantasy VI used similar code for things like changing from the World Map to a Village, or launching the Menu when you hit X, and didn't have to figure out how to code that stuff all over again.

I came here to try and learn from the people who have walked this path before me, but so far I think the only answer I have really gotten is "You're thinking about it wrong, just Google it yourself," at which point I wonder if the reply was more for me or more for the person replying.

It's tough to be new and know very little. It's embarrassing and frustrating. I don't need to be reminded that it's hard, or that there's a lot of testing, trial, and error. What I would like is someone who understands the challenge from the perspective of a beginner to say "here's a great resource" or "try X" or "a book that really helped me is" or "here's a link to a great tutorial project with assets you can download to read."

I know how forums are. I am on a few for my industry and it's impossible to help everyone who comes looking, but I must no matter what continue working on this project until it is finished, and I am at a standstill pending guidance.

To close on the music analogy, imagine a punk guitarist with a knowledge only of power chords, wanting to learn to play funk. Telling him "it's more complicated than punk" or "asking classical musicians how to go from punk to funk will confuse you because of lingo" is an unhelpful sort of masturbation. Recommending that they look into R&B first, or to study blues scales or like dorian modes, aeolian/minor scales, or "just practice along to James Brown records" would be far more helpful.

All good points. I made the analogy not to be dismissive and say "we can't help you because it's too hard" but to recalibrate your expectations regarding just how helpful a question-and-answer format on a forum can be for a new learner.

By far the best thing you can do is pick up a book or two about programming. Sadly I don't know which books are good these days. That's the first problem. I think most people get into game development via a full-time computing degree course, so trying to distill that down and transmit the same information in forum posts is tricky. And good books aren't as common as they used to be.

There isn't a (practical) way to examine the code of professionally-released games - and, to be honest, if there was, it wouldn't do you much good because they are often written badly and are not good examples to learn from. The next best thing is to read code from tutorials and books. You'll need to pick a language and/or engine, and then get a book or tutorial that covers that combination (or several books and tutorials). You say you've already been using tutorials so maybe they're just not of a high enough quality for what you want to do. (Which is common, sadly - tutorials are often written by people who've just recently learned something and want to pass on what they've learned - but they don't always fully understand what they're talking about.)

There are a lot of good techniques and concepts covered at Game Programming Patterns. Just reading through that from start to finish will teach you a lot of things, even if they don't appear immediately useful.

Regarding specific questions:

"Are there common techniques used for things like Saving?" - Yes, but there's no standard. (You're going to hear this a lot - or will hear 4 or 5 different people claim their way is standard.) At a basic level it's just about taking the data you have, knowing how to write it to disk, and knowing how to read it from disk. This isn't game-specific so traditional developers just use the facilities provided by the programming language. However, certain engines will provide systems to help you with this. (e.g. Unity has 'PlayerPrefs' which aren't really for full save-games, but which can be used that way.) In generic programming terms saving and loading is called 'persistence', which builds upon 'serialization'.

"I would imagine for example Final Fantasy V and Final Fantasy VI used similar code for things like changing from the World Map to a Village, or launching the Menu when you hit X" - this is what most people call "game states" - and although they tend to follow the concept of a 'finite state machine', everybody codes them a little bit differently.