# Novice Seeking Guidance

This topic is 428 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

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

Edited by electrikdave

##### Share on other sites

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.

##### Share on other sites

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?

##### Share on other sites

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.

##### Share on other sites

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?

##### Share on other sites

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.

##### Share on other sites

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. Edited by electrikdave

##### Share on other sites
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.)

Edited by Kylotan

##### Share on other sites
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.

##### Share on other sites

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.

##### Share on other sites

One thing you'll pick up if you stick to game development is that although we have certain coding patterns, the problem is that code is so flexible.

As an analogy imagine you were in charge of inventing the first railroad(both the rails and train) to transport things across country. Maybe someone told you how a railroad generally works, but all the details are really up to you. The gauge of the rails, what they're made of, how far apart they are, what the engine is made out of, how big it is, what kind of propulsion it uses. If you think about it there are a million little variations that would still end up with you having "a thing that travels along rails that transports people or goods over distance" same issue with coding.

That also makes it hard to understand other people's code many times because the essence of what their algorithms are doing can be hard to distill down just by looking at it, you have to work with it a bit to understand the idea behind it.

In addition coding really has two differing facets to it: efficiency and ease of use.

-Efficiency is really how fast or with how little memory some code can complete. Now arguably you don't want to worry about this all the time because that leads to micro optimization, spending all your time trying to make something run faster that arguably doesn't affect the gameplay experience that much. An example is saving. Saving happens infrequently by nature, if the game takes 5 seconds to save all your data and you spend many hours redoing the code to make it save in 3 seconds, did you really help that much? Percent wise you increased it by quite a lot but do you think people will care that much if the game takes 3 seconds to save vs 5? They probably won't unless saves happen constantly.

-Ease of use is something people push here a lot. It is designing your code so that it is easy to work with and expand, so that it isn't coupled tightly to other code and thus can be swapped out easily. We stare at code all day so making it easy to understand and easy to expand is nice, but the important thing to realize is that it being easier to read doesn't help the performance at all(generally.) Main advantage to this is that as a codebase gets larger you run into the issue of scale. Adding new features can take exponentially more time and changing existing things is slow too because you have to basically redo a lot of the wiring in your house.

##### Share on other sites

Just to tune in on the whole Unity vs. Unreal thing.

If you don't intend to compete in the highest of ends, don't worry too much about the power of Unity. It can do pretty much everything Unreal can, given you have the expertise or the money to upgrade some of the stock systems.

As an example, the stock terrain engine in Unity is seriously dated. You still can create a goodlooking game with it with a capable artist, but you will certainly hit certain ceilings without modifications... BUT: there are already a ton of VERY capable third party assets in the store to upgrade the Terrain System. Using a thirdparty terrain shader (for example RTP), and a thirdparty grass and tree system (for example Infinigrass), you get already a terrain system that you would have to struggle quite a bit with the Unreal Material node system to get a comparable result.

Now, This will cost you some 100$'s of dollars for all the improved systems you need, and you probably loose some % of performance because these systems are not built into the engine core, whereas the Unreal stock systems are (but of course messing around with the Unreal Terrain shaders leaves room to mess up performance again). You COULD develop your own systems in Unity just fine given time and skill, but I guess this is not what you want to waste your time on. The Performance thingy is really up to question... will it affect your game? Do you REALLY plan to push the hardware with your game? Should it be the next Witcher? I doubt it. Even if you ramp up your team, can you realistically expect to hire the 20+ team members needed even for small scale AAA effort? Or will your rather just hire a single artist, and maybe a programmer, and have to make do with much simpler graphics which will not push the engine just as hard? Don't get me wrong, Unreal 4 is a really fine engine, just as is Unity since they bounced back from their rough start in the Unity 5 release cycle. If you make the switch, and get along with the "Unreal way of doing things" (which is very Blueprint centric, and C++ centric at all unless you happen to have a lot of Unreal C++ expierience already), you will be just as happy using Unreal as you most probably are using Unity. Just don't make the switch expecting Unreal to be the magical silver bullet that does everything for you, and more. Its not. You get better stock systems, and POTENTIALLY more power at the highest of ends when pushing the limits on graphics and stuff like terrain streaming. You pay for it with a very strict way of doing things, having to rely on Blueprint a lot, having a less intuitive and more cluttered editor than in Unity. And having less options in many areas (they didn't have a forward renderer option when I last checked, though epic was working on it). And if developing for mobiles or some of the more exotic platforms, Unity usually has you covered with build targets, and usually is more often used on these platforms than Unreal. So really, you will most probably not gain MUCH, unless you are currently developing on a shoestring budget and are not ready to pay for assets in the Unity asset store that could upgrade some of the more dated aspects of Unity, AND are really hitting the ceiling of what the Unity stock systems can do. The Unreal stock systems will usually let you do way more, for free. Another thing to keep in Mind, IF you would switch mostly for futureproofing, is the pricing models. Unitys is basically a fixed cost as soon as you hit a certain income threshold with your game, per seat (sadly now you have to pay a sub, but Unity still gives you the option to end the sub and keep the license after a certain sum has been paid). Unreals on the other hand is a 5% royality you pay after you hit a certain income threshold. You can get around this AFAIK by buying a commercial license at some point, though how expensive these are nowadays IDK. Most probably still targeted more towards big AAA studios, thus 100k$+.

But really, just download Unreal 4 and give it a test run. Its free! It only costs you some time to get into it, but IMO that is time well invested... for one you will learn more about how engines work in general, and you will now make a better decision on which engine to use for which project, and why.

I did it, and came back to Unity after 6 months. Unreal 4 just isn't for me. I can get the same Power from Unity with the help of some upgraded systems from the asset store, and I am positive that I can work around some of the performance lost because of the engine or the less integrated systems with some optimization at the end. I work way faster with Unitys way of doing things whereas in Unreal everything felt like a struggle to me.

Never underestimate the ergonomical aspect of different engine editors. If you can work much faster in the editor of an engine, that can outweight an engines lack in power in many cases. Especially when you know you will have no use for that additional power for your project.

In the end I came back to Unity with a new appreciation for the Engine, which I still think has many weaknesses. But it has its strengths where it matters for me, and I think I work faster in it than in any other engine. And this is what matters most to me, not some theoretical future proofing that might never be necessary.

Might be the total opposite for you. Maybe Unreal Engine 4 just clicks for you, and you find out you work faster in it than Unity. In this case, you will be happy you have made the switch now, and not waited for another 6 months.

But maybe you also find Unreal to be not to your taste. In which case the theoretical upgrade in power and stock system quality might not matter anymore, and you will come back to Unity with a renewed sense that this is the right engine for you.

In either case, investing some months into learning Unreal will be a very good investement of time, even if your game makes no progress during this time, and you have to learn many things from scatch again for Unreal. Your knowledge will grow anyway.

##### Share on other sites
Kylotan

Yeah, it is surely a challenging subject to self-teach, but I must to what I must to accomplish my goals. Maybe ink and paper books are what I need. The tutorials are helpful, but so far I can't help but think "I don't think I would have done it that way."

I'm going to read through Game Programming Patterns, this looks to be a fantastic resource. Thank you so much for posting that.

Knowing the terms "persistence," "serialization," and "game states" are all very helpful. It's hard to know what to Google when you're starting fully from scratch, so these terms even so common to you are like a rosetta stone for me.

Satharis

Your railroad analogy is perfect. It's like how different drummers play different things to the same bass line.

Yeah I get that, everyone has such a different way to accomplish even simple things like character movement and loading menus. I've been doing different tutorials so I can learn a variety of ways to think, and figuring out how all the scripts talk to each other has been the most helpful part for me so far.

I'm not so worried about minute efficiency. The game I am making is not likely to be heavy on the system, it's mostly going to be dialogue and character interaction, with random and triggered battles being the most intense thing the game does.

Ease of use is important to me as I intend to take on crew when the project is ready to demo. I've noticed what you mentioned about scale already in tutorials. I decided to add a new stat to character sheets and I had to edit my leveling scripts, my saving scripts, my base item properties scripts, etc. It was more work than I expected but I think once all the nuts and bolts are working on character movement, leveling and items, I can focus on triggering dialogue and story events without having to revisit that stuff much. Here's hoping.

Gian-Reto

I am of the mind to always be ready to compete in the highest of ends. I believe Unity is adequate, but if my game is well-received I don't want to regret having made unnecessary compromises to get done just a little more quickly. Third-party assets appear to be a great option, and I have no issue paying for them, they're just a little expensive to purchase without trying before my game is even functional, considering I may switch platforms.

Since my game is mostly character interaction in real-life environments like inside of buildings and out in the woods, I worry about the realism. Most of what I am doing right now is just scripting characters and working on their interaction. I think the actual character scripting, dialogue, game events, etc. are going to be largely similar on either engine, but I think the user experience for Unreal will be better as far as realism. The distribution for Unity is the only thing I know it does better.

What does terrain streaming mean?

I'm happy to hear that you can get good realism from Unity. I have been working in unity so far, and I like it, but I haven't been able to make any of the test environments stand up to other games. I'm sure it's largely due to my skill level, but I worry that I might wind up with less realistic gameplay on Unity.

Your final point was exactly the thought I needed to consider. If I learn both I will know better which I prefer. Thank you for your advice.