Are Game Engines like Torque2D designed for novices like me?
by Carter H Gabriel · in Torque 2D Beginner · 10/22/2013 (7:53 am) · 17 replies
To be specific, I will list my skills, talents, and weaknesses:
Novice Programmer. I have absolutely no problem creating programs in higher level languages like C#. Anytime I have set out to finish a program for a specific goal, I have succeeded no matter the task in C#. I feel very confident in my ability to program and create games, because I can program. I am new to game development and game programming, far more than programming itself.
However, in C++, I do not feel anywhere as near as confident. I struggle with the constant problems dealing with Char Arrays and Strings. I stay up all night long until morning break, failing to fix compiler issues, Out of Value strings, and Out of Scope variables. I love C++, but lately I feel as though a simple program to open files, read them, and copy the strings into variables is beyond me. I never learned formal programming, but have completed several books on game development and a few books and an entire course on C++ programming.
I feel as though I am a failure, due to how difficult programming is for me sometimes. Headaches like missing a ";" or forgetting to use two instead of one , is not a big deal. It's when I try to do somethign so simple, such as access windows files or input/output of txt files for game data, that I feel my brain melt. In C#, this is usually so simple, but in C++, I experience my full newbism.
Yet I've worked with Unity3D before I knew how to program. I basically learned that to make a game with a game engine, you indeed need to know how to program, and how to engineer game logic. That to truly make a complete game, even with high level game engines, you basically need to be a professional programmer.
I do not feel as though I have it in me right now to learn an entire scripting language, only to realize I should have stuck with C++ or gone with programming with C#. Either way, I have been use the SFML library. I even got networking to work, so I feel confident in making my game multiplayer.
My game, specifically, is basically just the "server" part of multiplayer games. It's likened to a text based MUD. I need something to prevent what I often feel is absolutely ridiculous, such as how difficult handling strings can be in C++, or how hard it can be to do i/o for txt files with barely any data in them.
Are game engines for me? Or is there a higher level language than C++ that will resolve what often cause me to lose an entire nights work with no solution in site? I feel like giving up, because my research in google on my latest problem seems to be a compiler issue with CODE::BLOCKS and a crashing debugger with no fix in sight. How the heck can I fix an issue that would give a pro a headache, when I am such a novice?
Novice Programmer. I have absolutely no problem creating programs in higher level languages like C#. Anytime I have set out to finish a program for a specific goal, I have succeeded no matter the task in C#. I feel very confident in my ability to program and create games, because I can program. I am new to game development and game programming, far more than programming itself.
However, in C++, I do not feel anywhere as near as confident. I struggle with the constant problems dealing with Char Arrays and Strings. I stay up all night long until morning break, failing to fix compiler issues, Out of Value strings, and Out of Scope variables. I love C++, but lately I feel as though a simple program to open files, read them, and copy the strings into variables is beyond me. I never learned formal programming, but have completed several books on game development and a few books and an entire course on C++ programming.
I feel as though I am a failure, due to how difficult programming is for me sometimes. Headaches like missing a ";" or forgetting to use two instead of one , is not a big deal. It's when I try to do somethign so simple, such as access windows files or input/output of txt files for game data, that I feel my brain melt. In C#, this is usually so simple, but in C++, I experience my full newbism.
Yet I've worked with Unity3D before I knew how to program. I basically learned that to make a game with a game engine, you indeed need to know how to program, and how to engineer game logic. That to truly make a complete game, even with high level game engines, you basically need to be a professional programmer.
I do not feel as though I have it in me right now to learn an entire scripting language, only to realize I should have stuck with C++ or gone with programming with C#. Either way, I have been use the SFML library. I even got networking to work, so I feel confident in making my game multiplayer.
My game, specifically, is basically just the "server" part of multiplayer games. It's likened to a text based MUD. I need something to prevent what I often feel is absolutely ridiculous, such as how difficult handling strings can be in C++, or how hard it can be to do i/o for txt files with barely any data in them.
Are game engines for me? Or is there a higher level language than C++ that will resolve what often cause me to lose an entire nights work with no solution in site? I feel like giving up, because my research in google on my latest problem seems to be a compiler issue with CODE::BLOCKS and a crashing debugger with no fix in sight. How the heck can I fix an issue that would give a pro a headache, when I am such a novice?
#2
10/22/2013 (8:48 am)
Why do you use Torque2D? 
#3
Yes, it's complex. Yes, it's large. Yes, it takes a good 3 months (full time) to get comfortable and familiar with.
Still totally worth it. It was worth 20 times its original price just in time saved creating a game engine from scratch - just ask around. Making a full-featured 2D game engine is several months work for a team, let alone a single programmer. If you think learning to use T2D takes a long time just imagine having to write it from scratch....
10/22/2013 (12:30 pm)
Because it's powerful. Because the source code is available. Because the community is knowledgeable (if a little grumpy). Because it originated in a AAA quality game (Tribes/Tribes 2).Yes, it's complex. Yes, it's large. Yes, it takes a good 3 months (full time) to get comfortable and familiar with.
Still totally worth it. It was worth 20 times its original price just in time saved creating a game engine from scratch - just ask around. Making a full-featured 2D game engine is several months work for a team, let alone a single programmer. If you think learning to use T2D takes a long time just imagine having to write it from scratch....
#4
10/22/2013 (2:50 pm)
Quote:Are game engines for me?Game engines are definitely for you, unless you fancy the idea of doing a lot more low-level C++ file IO programming! The point of a game engine is to do that for you, as well as other mundane tasks like rendering, so you can worry about gameplay code.
Quote:My game, specifically, is basically just the "server" part of multiplayer games. It's likened to a text based MUD.On the other hand, if you don't need all the stuff game engines do for you like rendering and scene management, then they'll just add to the complexity of what you're trying to achieve.
Quote:Or is there a higher level language than C++ that will resolve what often cause me to lose an entire nights work with no solution in site?Yes - it's called C#. Or Python, or Ruby, or Haskell, or basically any other modern popular language - they're almost all higher-level than C++. Why do you feel the need to work in C++ in particular? Don't get me wrong, I think it's a good language to have working proficiency in, but I would no longer choose it to work in for my day-to-day activities if I weren't working on Torque 3D.
Quote:I do not feel as though I have it in me right now to learn an entire scripting language, only to realize I should have stuck with C++ or gone with programming with C#.IMO, as a competent programmer, you should try and learn lots of different languages. Not just because they might be useful, but because the more languages you learn, the easier it becomes to pick up more languages. Once you learn a few languages you start to see the similarities between them (paradigms, algorithms) and the differences (often design decisions). Don't be too afraid of TorqueScript - it's not all that different to C without pointers.
#5
Perhaps the best solution is to write the server in C#, and do the graphical client in Torque2D.
Even better, maybe write a server editor or server GUI in torque2d.
To answer your question with my entire programming life story, I actually began with a tutorial in Python, then game programming with Java, switched over to C# (where I learned quite a lot, and created my first real program which grabbed 35,000 files based on parameters, renamed them all, and sorted them in thousands of folders. I was really happy I did something as awesome as that for the first time. It is still the best accomplish I've finished in programming), and then started working on XNA. Of course, I tried Unity3D inbetween Java and C#, which is where I learned the C# syntax. I left Unity3D when I realized that it requires you to already know game programming, as the community and articles tend to exaggerate how easy it is to make games with it. I figured if I had to learn programming anyway, to start with a real programming language and not a game engine.
I guess I glossed over the idea of using C# without XNA, to create my game. Instead, I was relying on XNA- and had a few headaches with it, a flickering problem that people said was very common with a solution that was a bit over my head at the time, and I absolutely hated the content pipeline.
I realized I need to learn the basics better, I took two courses in C++. It was a game programming course, but primarily just dealt with the basics of programming and C++. I completed the course, falling in love with pointers (I forget why, but I loved the idea of handling memory myself! And I did something I couldn't do in C#, which I also forget. This is when I recreated the entire "Isometric Game Programming with DirectX 7" book engine in SDL and then switched SDL with SFML.)
I kind of went on a "Wow, C++ really is the best!" kick. I even created my own custom XML parser for my complex spritesheets. I worked with SDL for awhile, until I realized it was much lower level than I thought it was. Took me awhile, but when I realized it couldn't even flip an image, I knew I wanted something higher. I stayed with C++ and SFML.
It wasn't until recently, that I began to have really big problems with some i/o functions, dealing with strings and char array parameters. I ran into a specific problem which caused me to want to cry on the inside, lol, after taking an entire night to "learn" how to fix problems myself. I discovered it was a bug in my compiler due to the version I was using, and I wasted all that time on code that should have worked perfectly.
That's when I realized I was in over my head with C++, and decided "Maybe that I know a lot more, going back to Unity or Torque2D would be a good idea now."
I am still deciding whether or not to make my game what is ultimately a MUD server first or not. My plan was to create what is essentially a multiplayer standalone server that is nothing more than a console and game logic. Then create the client, which is the graphical representation based on the data sent by the server.
Thanks to Richard, I am actually going to go ahead and do some more research on Torque2D and Unity3D, and most likely decide on T2D. If I don't need it, I'll take your advice and use C# for the server, and use T2D for the client. After all, my game is very "instanced" in that a player will only ever be in a single scene (small area) at a time, entirely based on what the server says the scene should be.
If I had only listened to this man's advice, I would have saved myself a lot of headaches. I cannot emphasize the correctness of this article for any newbie reading this:
www.gamefromscratch.com/post/2011/08/04/I-want-to-be-a-game-developer.aspx
I have made some bad decisions, basically doing the opposite as he suggested, and I am grateful I at least learned a lot and practiced programming while I made them. But I sure wish I stuck with Torque2D or C# when I had the chance.
I wanted to share my experiences so far, to help anyone who may be starting out where I was. Learn from my mistakes! I'll also go ahead and share some of what I've got so far, and what I've been working on lately.
10/22/2013 (11:34 pm)
Thank you for your answers.Perhaps the best solution is to write the server in C#, and do the graphical client in Torque2D.
Even better, maybe write a server editor or server GUI in torque2d.
To answer your question with my entire programming life story, I actually began with a tutorial in Python, then game programming with Java, switched over to C# (where I learned quite a lot, and created my first real program which grabbed 35,000 files based on parameters, renamed them all, and sorted them in thousands of folders. I was really happy I did something as awesome as that for the first time. It is still the best accomplish I've finished in programming), and then started working on XNA. Of course, I tried Unity3D inbetween Java and C#, which is where I learned the C# syntax. I left Unity3D when I realized that it requires you to already know game programming, as the community and articles tend to exaggerate how easy it is to make games with it. I figured if I had to learn programming anyway, to start with a real programming language and not a game engine.
I guess I glossed over the idea of using C# without XNA, to create my game. Instead, I was relying on XNA- and had a few headaches with it, a flickering problem that people said was very common with a solution that was a bit over my head at the time, and I absolutely hated the content pipeline.
I realized I need to learn the basics better, I took two courses in C++. It was a game programming course, but primarily just dealt with the basics of programming and C++. I completed the course, falling in love with pointers (I forget why, but I loved the idea of handling memory myself! And I did something I couldn't do in C#, which I also forget. This is when I recreated the entire "Isometric Game Programming with DirectX 7" book engine in SDL and then switched SDL with SFML.)
I kind of went on a "Wow, C++ really is the best!" kick. I even created my own custom XML parser for my complex spritesheets. I worked with SDL for awhile, until I realized it was much lower level than I thought it was. Took me awhile, but when I realized it couldn't even flip an image, I knew I wanted something higher. I stayed with C++ and SFML.
It wasn't until recently, that I began to have really big problems with some i/o functions, dealing with strings and char array parameters. I ran into a specific problem which caused me to want to cry on the inside, lol, after taking an entire night to "learn" how to fix problems myself. I discovered it was a bug in my compiler due to the version I was using, and I wasted all that time on code that should have worked perfectly.
That's when I realized I was in over my head with C++, and decided "Maybe that I know a lot more, going back to Unity or Torque2D would be a good idea now."
I am still deciding whether or not to make my game what is ultimately a MUD server first or not. My plan was to create what is essentially a multiplayer standalone server that is nothing more than a console and game logic. Then create the client, which is the graphical representation based on the data sent by the server.
Thanks to Richard, I am actually going to go ahead and do some more research on Torque2D and Unity3D, and most likely decide on T2D. If I don't need it, I'll take your advice and use C# for the server, and use T2D for the client. After all, my game is very "instanced" in that a player will only ever be in a single scene (small area) at a time, entirely based on what the server says the scene should be.
If I had only listened to this man's advice, I would have saved myself a lot of headaches. I cannot emphasize the correctness of this article for any newbie reading this:
www.gamefromscratch.com/post/2011/08/04/I-want-to-be-a-game-developer.aspx
I have made some bad decisions, basically doing the opposite as he suggested, and I am grateful I at least learned a lot and practiced programming while I made them. But I sure wish I stuck with Torque2D or C# when I had the chance.
I wanted to share my experiences so far, to help anyone who may be starting out where I was. Learn from my mistakes! I'll also go ahead and share some of what I've got so far, and what I've been working on lately.
#6
The player travels like in Fallout 1 & 2's world map. In fact, I accidentally recreated Fallout's world map traveling system, down to the grid and graphical representation and passing of time, almost identically. This was totally an accident, as I had never played Fallout until after I created how my travel gameplay worked.
There is the "Zone" of Kwaynos, City of Men.
www.cartographersguild.com/attachments/regional-world-mapping/58503d1382104255-%...
Here is the Halfling zone, "The Riverlands"
www.cartographersguild.com/attachments/regional-world-mapping/58504d1382104292-%...
These are the misty hills which separate the Halflings from the northern Goblins who live on the hilly-edge of "The Iron Mountains" (an entire mountain Biome) and harvest gold. Those greedy little snotlings!
www.cartographersguild.com/attachments/regional-world-mapping/58505d1382104331-%...
To the west of Kwaynos, and towards the Riverlands, are The Hills.
www.cartographersguild.com/attachments/regional-world-mapping/58610d1382509973-%...
Inbetween the Hills and the Riverlands, lie a currently unnamed, creepy forest.
www.cartographersguild.com/attachments/regional-world-mapping/58611d1382510007-%...
10/22/2013 (11:42 pm)
The game is actually an adventuring type of RPG, with a lot of procedural generation instead of actual content or storyline. The game world, however, is a truly massive world (about the size of Australia IRL). However, the player covers great distances in gameplay, and a large part of the game IS this traveling. I am inspired most by "The Hobbit", Tolkien's work, MMO's and video games from the 90's, and Game of Thrones. I feel as though "the journey" is where the most fun lies, so I want the entire game to BE that journey. Adventures through a massive world, with goals and quests that are never the same twice.The player travels like in Fallout 1 & 2's world map. In fact, I accidentally recreated Fallout's world map traveling system, down to the grid and graphical representation and passing of time, almost identically. This was totally an accident, as I had never played Fallout until after I created how my travel gameplay worked.
There is the "Zone" of Kwaynos, City of Men.
www.cartographersguild.com/attachments/regional-world-mapping/58503d1382104255-%...
Here is the Halfling zone, "The Riverlands"
www.cartographersguild.com/attachments/regional-world-mapping/58504d1382104292-%...
These are the misty hills which separate the Halflings from the northern Goblins who live on the hilly-edge of "The Iron Mountains" (an entire mountain Biome) and harvest gold. Those greedy little snotlings!
www.cartographersguild.com/attachments/regional-world-mapping/58505d1382104331-%...
To the west of Kwaynos, and towards the Riverlands, are The Hills.
www.cartographersguild.com/attachments/regional-world-mapping/58610d1382509973-%...
Inbetween the Hills and the Riverlands, lie a currently unnamed, creepy forest.
www.cartographersguild.com/attachments/regional-world-mapping/58611d1382510007-%...
#7
10/22/2013 (11:44 pm)
Oh my apologies. This is my main account, but I had lost the password and got lazy and created the Carter One, lol. Apparently when I switched to FireFox it had me already logged in.
#8
Actually, he was right about two things - programming is programming. But his take is wrong; programming in any language is still programming. You have to use the language to solve your problem. The syntax is different and sometimes it even limits your options from a design perspective, but the task is the same. I usually write "programs" that encompass C++, Lua and shell scripts to accomplish a single task. This lets me use C++ to define the sequence of events but the other tools are used as needed to define how each event plays out.
Fighting with driver issues has nothing to do with programming - though you apparently found out the hard way that it can fool you into thinking it does.
Fallout's early map mechanics are logical and it makes sense you would probably design something almost identical - I did it myself in '96.
The best thing you can do is the third thing he got right - just do it. Get to work. Stop beating around the bush. Jump in with both feet and don't you dare look first! You'll learn a ton just by doing. Start with small things that will give you results and build up your knowledge.
Now get out there and make cool stuff!
10/23/2013 (6:53 am)
The guy is in that article (www.gamefromscratch.com/post/2011/08/04/I-want-to-be-a-game-developer.aspx) is right about one thing; You shouldn't start with C++, you should start with Assembly. If you don't know how the software interacts with the hardware you don't know what your program is doing.Actually, he was right about two things - programming is programming. But his take is wrong; programming in any language is still programming. You have to use the language to solve your problem. The syntax is different and sometimes it even limits your options from a design perspective, but the task is the same. I usually write "programs" that encompass C++, Lua and shell scripts to accomplish a single task. This lets me use C++ to define the sequence of events but the other tools are used as needed to define how each event plays out.
Fighting with driver issues has nothing to do with programming - though you apparently found out the hard way that it can fool you into thinking it does.
Fallout's early map mechanics are logical and it makes sense you would probably design something almost identical - I did it myself in '96.
The best thing you can do is the third thing he got right - just do it. Get to work. Stop beating around the bush. Jump in with both feet and don't you dare look first! You'll learn a ton just by doing. Start with small things that will give you results and build up your knowledge.
Now get out there and make cool stuff!
#9
Programming is just problem solving. The choice of language is just a choice in how you want to "explain your problem." Once you are proficient, you can branch out and try to solve the same problem using different approaches (paradigms and design patterns).
For example, your problem might be making a tool that can read all the files in a directory and present them via a GUI. If you choose C#, you can go with the simplistic Win Forms. Once you solve the problem using C# and Win Forms, you can then try to solve it differently using WPF. This allows you to learn a new pattern (MVVM).
Programming is all about progression. Learn to sit up, crawl, walk, run, jump, and so on. Learning to code before having a child taught me good things take time and patience. High frustration with a greater reward, and it never stops.
10/23/2013 (7:20 am)
Well said all around Richard. I always appreciate and respect your programming discussions. I'm going to steal the smallest portion of your post to sum up my general opinion:Quote:You have to use the language to solve your problem.
Programming is just problem solving. The choice of language is just a choice in how you want to "explain your problem." Once you are proficient, you can branch out and try to solve the same problem using different approaches (paradigms and design patterns).
For example, your problem might be making a tool that can read all the files in a directory and present them via a GUI. If you choose C#, you can go with the simplistic Win Forms. Once you solve the problem using C# and Win Forms, you can then try to solve it differently using WPF. This allows you to learn a new pattern (MVVM).
Programming is all about progression. Learn to sit up, crawl, walk, run, jump, and so on. Learning to code before having a child taught me good things take time and patience. High frustration with a greater reward, and it never stops.
#10
10/23/2013 (3:31 pm)
Quote:You shouldn't start with C++, you should start with Assembly.Eh? What about this line:
Quote:If you as a beginner pick assembly in this day and age, you did something wrong, extremely wrong!Oh, do you mean he was right about not starting with C++? I dunno, I happen to agree with the article on this point ;P.
#11
And completely wrong about assembly. It's the best (albeit most unforgiving) way to learn basic programming concepts, hands down. And you learn to understand the hardware in a way that only a handful of people do these days. I'm not saying "become a master of assembly language programming," I'm saying "learn to do some basic things with it so that you grasp basic techniques and get a feel for the 'metal'."
When I was learning this stuff there weren't a lot of options, and if you wanted to do really cool stuff it was C or assembly - just look at Doom and Quake....
If you find yourself thinking you have to actually do any real work in assembly then yes, you have probably taken a wrong turn (or you make custom hardware drivers for very specific applications - or maybe write compilers).
10/23/2013 (5:03 pm)
Yes, he was right about not starting with C++.... lolAnd completely wrong about assembly. It's the best (albeit most unforgiving) way to learn basic programming concepts, hands down. And you learn to understand the hardware in a way that only a handful of people do these days. I'm not saying "become a master of assembly language programming," I'm saying "learn to do some basic things with it so that you grasp basic techniques and get a feel for the 'metal'."
When I was learning this stuff there weren't a lot of options, and if you wanted to do really cool stuff it was C or assembly - just look at Doom and Quake....
If you find yourself thinking you have to actually do any real work in assembly then yes, you have probably taken a wrong turn (or you make custom hardware drivers for very specific applications - or maybe write compilers).
#12
Programming isn't about understanding the hardware. Being a great programmer is (to some extent) but IMO the hardware is too complex to dump on a beginner. People have trouble understanding while loops - I suspect their chances of implementing one with a branch aren't great. People have trouble understanding 'x = x + 1' - I supspect using an accumulator is going to be even more painful.
Additionally, writing simple programs in assembly and understanding how their performance works is almost useless in understanding what will actually affect the performance of a large complex application. Knowing assembly doesn't teach you about algorithmic complexity, interaction between several cache layers, IO delays, multithreading, etc.
My view on this is somewhat informed by people like Bret Victor, who say things like this:
And also there's the massive caveat that I'm not aware of statistics on different approaches to teaching programming (i.e. starting with Python versus starting with assembly). It'd be interesting to see if there've been studies done.
TLDR: Assembly is important for pros, not for beginners. In my strident opinion ;).
10/23/2013 (8:19 pm)
I'm worried we're diverging from the subject, but since the OP is talking about learning different languages, I'll keep on. IMO, all programmers should definitely experience assembly at some point, but I think it's a terrible place to start.Programming isn't about understanding the hardware. Being a great programmer is (to some extent) but IMO the hardware is too complex to dump on a beginner. People have trouble understanding while loops - I suspect their chances of implementing one with a branch aren't great. People have trouble understanding 'x = x + 1' - I supspect using an accumulator is going to be even more painful.
Additionally, writing simple programs in assembly and understanding how their performance works is almost useless in understanding what will actually affect the performance of a large complex application. Knowing assembly doesn't teach you about algorithmic complexity, interaction between several cache layers, IO delays, multithreading, etc.
My view on this is somewhat informed by people like Bret Victor, who say things like this:
Quote:Alan Perlis wrote, "To understand a program, you must become both the machine and the program." This view is a mistake, and it is this widespread and virulent mistake that keeps programming a difficult and obscure art. A person is not a machine, and should not be forced to think like one.Which brings us back to the point that programming is problem-solving. Assembly doesn't teach you how to solve problems, it teaches you the specific details of a hardware model.
And also there's the massive caveat that I'm not aware of statistics on different approaches to teaching programming (i.e. starting with Python versus starting with assembly). It'd be interesting to see if there've been studies done.
TLDR: Assembly is important for pros, not for beginners. In my strident opinion ;).
#13
<edit>
I should have been clearer in my original statement above - when I said "basic things" in assembly I meant basic useful things. Iterate file lists, make a highlighting text menu, make a "pocket calculator," that sort of thing. Naturally "Hello World" in assembly is pointless in understanding the machine.
Always try to understand your tool before you start using it - a computer is a tool like any other, and the better you understand it the less frustration you will experience when trying to use it to its fullest.
Of course, my perspective is definitely very different from Daniel's - he's right, I just disagree on this point. 35 years ago it was tough for a junior high school student to get a C compiler and I was lucky to get my hands on the Big Mac macro assembler for the Apple ][+.
Everyone learns differently, so I suppose we can agree on "understand how you (personally) learn best before you start to learn programming." Your most important tool is between your ears, after all.
10/23/2013 (10:30 pm)
I suppose my main point was - regardless of where you start, stick with it. If you stop you'll never finish....<edit>
Quote:People have trouble understanding 'x = x + 1' ...probably aren't worried about algorithmic complexity just yet and an accumulator is the perfect illustration of "add one to self." ;p
Quote:"To understand a program, you must become both the machine and the program."I agree with Daniel that this is a pretty silly statement - but learning assembly isn't learning to "become the machine," it's learning to understand it. Your first week of shop class is basic hand tool use and safety rules - to me, learning assembly is like that. Trust me, you don't want to use a chainsaw until you understand how it works.
I should have been clearer in my original statement above - when I said "basic things" in assembly I meant basic useful things. Iterate file lists, make a highlighting text menu, make a "pocket calculator," that sort of thing. Naturally "Hello World" in assembly is pointless in understanding the machine.
Always try to understand your tool before you start using it - a computer is a tool like any other, and the better you understand it the less frustration you will experience when trying to use it to its fullest.
Of course, my perspective is definitely very different from Daniel's - he's right, I just disagree on this point. 35 years ago it was tough for a junior high school student to get a C compiler and I was lucky to get my hands on the Big Mac macro assembler for the Apple ][+.
Everyone learns differently, so I suppose we can agree on "understand how you (personally) learn best before you start to learn programming." Your most important tool is between your ears, after all.
#14
10/24/2013 (4:34 pm)
Quote:regardless of where you start, stick with it. If you stop you'll never finishDefinitely, both are great advice all round. I think I've probably covered as much as I can on this topic! I'll leave it at that :).
understand how you (personally) learn best before you start to learn programming
#15
10/25/2013 (5:04 am)
Just to throw in my two bits: I've had all of a basic youtube tutorial series on C++ (thenewboston's tutorials are good for absolute beginners), then I jumped into Torquescript and have some nice working prototypes now. I'd say Torque2D MIT is very good for beginners. :)
#16
I must say, I have learned a lot.
0) I paused my multiplayer fantasy rpg, to do a simpler starflight treky pixel art game. Smaller project, but still a large one.
1) I learned that I love C#, and working with C# & SFML.net was awesome. I am a big fan of C# and a big opponent of using C++ for 2D game dev (what I believe to be an archaic language for game development, since most 2D games don't need to be so low level). I have no opinion over 3D game dev, so I have no knowledge or opinion on C#/C++ for 3D work. I just hate C++ for 2D game dev. Love C# for everything, including software dev.
2) I chose Unity3D because of 4.5 (2D updates) and asset store. I regret my decision to not choose T2D or C#/SFML.net. Unity3D has some horrific rendering bugs- and IMO that is unacceptable seeing as how a game engine's highest priority is to render graphics correctly. Having flaws in an engine's basic functionality is unacceptable. Some have been fixed in 4.6, but still...
I regret thinking the asset store was a good idea as well. As if it is not confusing enough to do things Unity's way (as opposed to your own way, or spending time fixing Unity's flaws) but you lose the benefit of knowing how everything works yourself, multiplied! Not only do you have to do things Unity's way, but any asset you buy- you have to do things in that Author's way. It's like working with a team of programmers- which sucks, because you gain none of the benefits since you're working alone and buying third party assets. Also, the idea of giving Unity $1500 (pro license) when I could have used T2D or SFMLnet for FREE $0, just kills the cheapskate inside of me.
3) I hate making GUI's, I hate designing GUI's. I just plain hate GUI's. They are the most time-consuming, frustrating things to do. Even with Unity's new GUI update (which is pretty awesome compared to its horrific legacy GUI) it still takes too much time. I assume that GUI's would take me a lot of work and frustration no matter what engine or framework I used. I just suck at making them quickly. My imagination just isn't fit for GUI design either.
4) I love adding content to the game.
5) I like programming in C#, irrelevant of Unity3D. I actually have C# scripts in Unity which do not inherit monobehaviour, so they could be used in any C# engine or C# framework.
6) I LOVE procedural generation. I programmed for 8 hours straight creating a procedural universe, without debugging or testing it the entire time I programmed. First run...was flawless. Exactly as I wanted, with very little tweaking required to balance things out. I assume I am both a natural and a lover of this type of programming, although I did return to the code to add more features- which was also really fun! Then I tied it all together using Unity and its design philosophy, and that was pretty fun seeing it come alive as well.
7) Despite not being an artist, I get a lot of compliments on my pixel art. HURRAY!
8) Getting a real artist on your team helps free up time to program. Plus real artists know all about color theory and artistic knowledge (something I am entirely ignorant on)- so that's always a plus.
9) Publishers want ridiculous amounts of money to do what I hypothesize is actually very little for your game. (Someone wanted 40-50% to basically (poorly) advertise my game. Something I could do myself by hiring a marketer or paying for advertisements myself.) Although it was kindof cool that they were willing to pay me (probably a tiny bit) to continue to make the game, almost like a real job, hahahaha :P
10) Link to my game, currently in prototype phase: http://forum.unity3d.com/threads/a-unique-starflight-y-game.227695/
09/01/2014 (1:01 pm)
It has almost been a year since I posted this.I must say, I have learned a lot.
0) I paused my multiplayer fantasy rpg, to do a simpler starflight treky pixel art game. Smaller project, but still a large one.
1) I learned that I love C#, and working with C# & SFML.net was awesome. I am a big fan of C# and a big opponent of using C++ for 2D game dev (what I believe to be an archaic language for game development, since most 2D games don't need to be so low level). I have no opinion over 3D game dev, so I have no knowledge or opinion on C#/C++ for 3D work. I just hate C++ for 2D game dev. Love C# for everything, including software dev.
2) I chose Unity3D because of 4.5 (2D updates) and asset store. I regret my decision to not choose T2D or C#/SFML.net. Unity3D has some horrific rendering bugs- and IMO that is unacceptable seeing as how a game engine's highest priority is to render graphics correctly. Having flaws in an engine's basic functionality is unacceptable. Some have been fixed in 4.6, but still...
I regret thinking the asset store was a good idea as well. As if it is not confusing enough to do things Unity's way (as opposed to your own way, or spending time fixing Unity's flaws) but you lose the benefit of knowing how everything works yourself, multiplied! Not only do you have to do things Unity's way, but any asset you buy- you have to do things in that Author's way. It's like working with a team of programmers- which sucks, because you gain none of the benefits since you're working alone and buying third party assets. Also, the idea of giving Unity $1500 (pro license) when I could have used T2D or SFMLnet for FREE $0, just kills the cheapskate inside of me.
3) I hate making GUI's, I hate designing GUI's. I just plain hate GUI's. They are the most time-consuming, frustrating things to do. Even with Unity's new GUI update (which is pretty awesome compared to its horrific legacy GUI) it still takes too much time. I assume that GUI's would take me a lot of work and frustration no matter what engine or framework I used. I just suck at making them quickly. My imagination just isn't fit for GUI design either.
4) I love adding content to the game.
5) I like programming in C#, irrelevant of Unity3D. I actually have C# scripts in Unity which do not inherit monobehaviour, so they could be used in any C# engine or C# framework.
6) I LOVE procedural generation. I programmed for 8 hours straight creating a procedural universe, without debugging or testing it the entire time I programmed. First run...was flawless. Exactly as I wanted, with very little tweaking required to balance things out. I assume I am both a natural and a lover of this type of programming, although I did return to the code to add more features- which was also really fun! Then I tied it all together using Unity and its design philosophy, and that was pretty fun seeing it come alive as well.
7) Despite not being an artist, I get a lot of compliments on my pixel art. HURRAY!
8) Getting a real artist on your team helps free up time to program. Plus real artists know all about color theory and artistic knowledge (something I am entirely ignorant on)- so that's always a plus.
9) Publishers want ridiculous amounts of money to do what I hypothesize is actually very little for your game. (Someone wanted 40-50% to basically (poorly) advertise my game. Something I could do myself by hiring a marketer or paying for advertisements myself.) Although it was kindof cool that they were willing to pay me (probably a tiny bit) to continue to make the game, almost like a real job, hahahaha :P
10) Link to my game, currently in prototype phase: http://forum.unity3d.com/threads/a-unique-starflight-y-game.227695/
#17
To me C++, Java, and C# share many traits - the most frustrating of which is the need to figure out how to get the "libraries," "packages," or "assemblies" that you want into the program you're writing so you can use them.
I am uncomfortable working in Java, but I don't hate it. I use the tool best suited to the job - sometimes that is Java (in the case where you're building a tool for a third-party program and that's the only API you're given, for instance). The same goes for the others. It's better to have many tools at your disposal, after all.
09/01/2014 (1:45 pm)
I still don't know why you hate C++ - it is very similar to C#.To me C++, Java, and C# share many traits - the most frustrating of which is the need to figure out how to get the "libraries," "packages," or "assemblies" that you want into the program you're writing so you can use them.
I am uncomfortable working in Java, but I don't hate it. I use the tool best suited to the job - sometimes that is Java (in the case where you're building a tool for a third-party program and that's the only API you're given, for instance). The same goes for the others. It's better to have many tools at your disposal, after all.
Torque Owner Richard Ranft
Roostertail Games
Since you're a fairly experienced programmer, perhaps you should consider using a different tool. If CODE::BLOCKS has a bug that is holding you up, use a compiler that doesn't have that bug. On Mac OSX I know that XCode compiles Torque 2D just fine for Mac and iOS. On Windows the preferred compiler is Visual C++, and Visual C++ Express Edition works perfectly if you don't want to shell out the dough for the Professional Edition.
Limiting yourself to a specific tool is not a really good idea anyway - you should spend some time experimenting with other tools and IDEs because you might be missing out on something really cool....
String handling in C++ is really simple (not like C at all unless you really want it to be) - look into the Standard Template Library, specifically the String template class. The STL has a ton of tools that will help in a vast range of use cases and you can always specialize the template if you need to optimize later.
So my advice - don't ever give up. Nobody likes a quitter! But seriously, if you dream of making games and you give up on your dream what do you have left? I have spent the last 32 years studying games, programming and game programming. 32 YEARS. I have yet to release a commercial game on my own. Keep at it - games and simulations are by far the most complex software on the planet and the target is moving faster than in almost any other field. Games incorporate aspects of dozens of software fields and they're usually cutting edge, pushing the envelopes of speed and realism. Of course it's hard.