Choose a language; I'd recommend C# or Python normally, but in this case you should probably choose the same one your classes are going to teach you. Learn basic programming. This will likely involve making programs in a console-based, text IO format for some time. The simplest game you are likely to be making early on is a "guess the number" game in a text console environment, which can be done with a few simple programming constructs and iterated on fairly well.
Josh PetrieMember Since 11 Jun 2003
Offline Last Active Private
- Group Moderators
- Active Posts 7,128
- Profile Views 14,063
- Submitted Links 0
- Member Title Moderator - For Beginners
- Age Age Unknown
- Birthday Birthday Unknown
Expert Community Member
Outstanding Forum Member
Blog post contributor
- Website URL http://joshpetrie.com
Posted by Josh Petrie on 24 February 2014 - 01:20 PM
Posted by Josh Petrie on 22 February 2014 - 06:57 PM
Legacy code isn't always bad. It's just old. Changing old just because it's old isn't a good idea, especially on shipping products. For example, the code base of Guild Wars (and Guild Wars 2) doesn't use the standard C++ library for containers, et cetera. All the containers are hand-rolled. This was done (among other reasons) because in the formative years of the code base, the standard library wasn't very well implemented. The modern standard library is much better, and quite powerful, and while sure it would be nice to rip out all that old code and replace it with standard stuff... why? The existing code works and is tested, and introducing a change (especially on that scale, but not just on that scale) has a risk of breaking the functionality.
Why take such a risk for no demonstrable benefit? Until there is a demonstrable benefit (and again, being "new" isn't one), taking that risk is usually a poor business and engineering decision.
Even legacy code that is bad carries that change risk. Bugs are routinely discovered in code that we've shipped; sometimes we don't fix them immediately because the ramifications of the change need analysis even if the change makes the code better from an engineering standpoint.
When you work on large projects with serious business implications, not every decision can be based on pure engineering.
Somebody mentioned Halo earlier on; Bungie still uses that very same code base in Destiny, and it's in the new Halo games as well. Much of has evolved over time but there are definitely files that retain much of the original code or comments from, for example, Aleph One's code (though you may need to go back a fair few years since the project has diverged).
There's little point (and lots of cost) to rewriting everything from scratch every time a studio starts a new game. It already takes man-decades of work to ship a AAA commercial title these days. We cannot afford to increase that.
Posted by Josh Petrie on 22 February 2014 - 06:44 PM
I guess a possible plan would be: 1. C# and unity (Make several games.) 2. learn Lua for Cry engine.
Should I learn more languages?
P.S how do you make your own game engine? what is commonly used for this?
Posted by Josh Petrie on 22 February 2014 - 06:39 PM
One programming language (GML) to master
True of Java (or any other one programming language) as well. Further, good programmers know many languages.
- Not exactly resume material (if you're looking into developing professionally)
If there are memory or other system-related issues, debugging might be pretty tricky
I'm not entirely clear what you mean here.
If you want to be a programmer in the games industry, you're going to need to know how to program. Probably in C++. But if you're just a hobby developer who wants to make games quickly, something like GameMaker can be great if you can make your games within its constraints and you don't really care about learning other languages like C++, Java, C#, Objective-C, or what have you.
You can make pro and cons lists for days. But what really matters is what your goals are.
Posted by Josh Petrie on 19 February 2014 - 10:55 AM
Using some engine built on those frameworks should offer you higher-level services and allow you to get something more "game-like" up and running quicker. If that is your primarily motivation, I would take that approach.
Posted by Josh Petrie on 03 February 2014 - 10:21 PM
This sort of thing is generally considered "bad" (using a ternary operator to wholly replace an if-statement):
(grade >= 60) ? printf("Passed!\n") : printf("Uh-ohhh...\n");
Generally, you should prefer an if statement to the ternary operator if the operands to the ?: are verbs or complex expressions with side-effects (as they are above: printing).
The second example is a more acceptable use of the ternary operator:
puts(grade >= 60 ? "Passed!\n" : "Uh-ohhh...\n");
Posted by Josh Petrie on 03 February 2014 - 10:15 PM
However I have zero expirence with programming and little expirence with art design on computers. I do play a handful of games from triple A titles like bf4 on pc to indie games like insurgency standalone and rising storm.
You should work on getting some experience with either or both of the first two topics. Making games is fundamentally different from playing them; while it's generally a nice perk that you are interested in playing games a hobby, it's not going to get you a job.
Through research I found many people to have worked long hours starting off as things like game testing were the pay is bad and the labour is intensive,
The industry has a reputation for being tough, but it's not a universal truth. You don't have to settle for extreme hours of unpaid overtime (and you shouldn't; when you do you only contribute to the problem). You also don't have to start in QA (and I don't generally recommend it), and it is not necessarily any easy to use QA as a stepping stone than it is to just get the job you actually want right off the bat (that is generally an exaggeration passed off as reality by clueless gaming press).
how easy it is to find a job, pay, hours of work, enjoyable, stressfull, and is it a longterm career that is worth looking into, what education do I need.
It depends. If you are good, it's easy to get a job. If you are smart and self-confident (and not wholly risk-averse), the hours are normal. Whether or not it's enjoyable a stressful is very subjective, but it's certainly a viable long-term career path.
The education you'll want to get depends on your area of interest. If it's programming-related, you'll probably want a computer science degree. Art, probably some kind of art degree. Et cetera.
also a side note Is would it be good to start small and purchase game maker and create a 2d platformer, me and my freidn are interested in making a game like spelunky and possibly finding a way to sell it.
It is always a good idea to start small, and always a good idea to work on and finish game projects. It's highly educational and can eventually give you some awesome portfolio pieces. And maybe even make you some money along the way.
Be careful about spending money outright though; if a tool has a trial version, make sure you try it out completely before paying. You can make games without paying a single penny, so don't throw down your hard-earned money until you know you need (or want) to.
Posted by Josh Petrie on 03 February 2014 - 10:07 PM
This has been asked and answered several times over on this forum; please use the search functionality available in the upper right.
Posted by Josh Petrie on 07 August 2013 - 08:58 AM
This is no longer really relevant to beginners, so I'm going to close it (unless some other moderator wants to reopen it and move it to a more advanced forum).
Posted by Josh Petrie on 25 July 2013 - 09:22 AM
Legacy code, and lots of it.
Why is there so much legacy code for C(98) and C++(pre tr1)? Why not VB6, Java 1.2, .NET 1.1 or other popular languages or platforms of past years?
In ~20 years, sure we will probably call things like SDL legacy and sure people will still be slating C++ against their new language of choice and yet C++ will still be going strong, SDL will still work and everyone would have long forgotten .NET, C# and XNA.
Washu was talking about the game development industry, predominantly the professional portion of it. There is almost no "legacy code" for VB6, Java, or .NET because it is almost never used for shipping professional games. Additionally, C++ is much older than any of those technologies.
You have a highly amusing view of the future.
Posted by Josh Petrie on 23 July 2013 - 09:23 AM
When I learned about Object Oriented Design for my first courses in Java, I sat down and read a book about Java for about 5 months. Then it finally clicked and all the theory I had read over time about how OOD works, suddenly made sense and I could pretty much utilize it all from the get got. It was the same concept I wanted to apply to learning Data Driven Design.
The thing is that despite a similarity in names, object-oriented design and data-driven design are different classes of concept entirely. The former is more structured an idea than the latter. I'd also challenge your assertions regarding your understanding of OO at that point in time, because many academic programs focus entirely on the wrong parts of OO and without using it extensively on real software, you don't really build up a true, "battle tested" understanding. One can acquire a passable understanding of a concept through books and other references, but until you really start using things in practice you have no idea how much you don't know you don't know.
I just really hate the notion of starting to code something and have no one by my side to consult with over it. Which is why I like getting taught by teachers rather than reading books or courses on the internet. If I make things wrong from the get-go and learn nothing I feel I've wasted my time.
You really need to disabuse yourself of this notion. Making mistakes is a critical part of learning and if you try to avoid it, you're only holding yourself back. Build games, and when you have questions or get stuck, you can ask people on the internet. Stop being afraid of doing it wrong. Everybody has, everybody will continue to do it wrong and make mistakes -- professional engineers who have been building games for ten years still make them happily.
You are holding yourself back by not trying to train yourself out of that pattern.
Posted by Josh Petrie on 23 July 2013 - 08:54 AM
As I said on GDSE, you are massively overcomplicating things. Data-driven design just means you keep your code and your data separate, and you allow the code to be directed by the data instead of the other way around. Simple things like loading configuration information from text files put you on the path to data-driven design.
Your problem appears to be that you are suffering from design paralysis because you're trying to take in the entire scope of everything that could be considered data-driven design at all once, including complete existing implementations, so you can rebuild it yourself. This is bound to result in frustration and failure. You need to start small, and build systems that you need for your games. Reading other people's code can be interesting, but often lacking in a lot of critical detail about the why of various decisions that can easily lead you astray.
Your dream goal is to have an engine on-par with AAA titles. That's great, but the way you're going to get there is not to explore a bunch of code other people have written that leverage data-driven techniques. You're going to get there by writing games. Don't worry about "making the engine very abstract so you can write many different games on it" to start with. You will evolve your code there eventually: for now, focus on smaller goals.
Pretty much the only piece of technology you need in place to start with is a way to actually load structured data from files. You can find great third-party libraries for parsing XML or JSON. For example, I use picojson often in C++. You may optionally want to have a serialization layer that uses the external library to turn data files into C++ structures, but for small projects I would not necessarily build that layer to start with. Wait until you have unburdened yourself of this design paralysis that plagues you right now.
Every time you build a new gameplay feature, take note of the inputs to that feature that control how it behave. Consider what is gating every conditional statement and while loop in that feature's code, and ask yourself "does it make sense that I'd want to tweak or change this?" If the answer is yes, consider how to put it into data.
Focus entirely on that concept for now, and finish a single simple game with it. Then, as you move on to another game, take stock of your existing code and see what is immediately re-usable, and what might be re-usable with some refactoring. Start to build that second game, and refactor the components you need as you need to increase their generality. Additionally, with your next project, pick a new aspect of technology to focus on. First you essentially focused on "loading data from files," so perhaps your second project would be the right time to start adding a more powerful serialization layer between the data and the code (so you're not just passing around XML node pointers or JSON objects into your feature code). Or, perhaps it's time to look into how you could implement a system that automatically reloaded data as it was changed.
By refining your code through projects with limited scope and concrete goals (a simple game), focusing each time on a small set of technology improvements, you will find yourself well on your way to having a reusable engine codebase. If you try to get there mainly by studying other people's code and one day sitting down and building the bulk of your final goal... you'll almost certainly fail.
Posted by Josh Petrie on 22 July 2013 - 01:21 PM
He doesn't seem to want your help or advice, so I'd suggest that you leave him alone to waste his own time if he so choses.
Posted by Josh Petrie on 20 June 2013 - 10:03 AM
I've got step-by-step instructions on how to create games on my website www.MarekKnows.com.
You'll want to start simple by first figuring out how to render an image on the screen. Then figure out how to move it, and then add some game logic. Start simple with something like Pong and work your way up.
Which seem to be behind some kind of complicated paywall / download credit system? This post reads too much like an advertisement for my taste. Please refrain from such content-free posts in the future.
Posted by Josh Petrie on 17 June 2013 - 09:17 AM
I would like to avoid using Windows Forms Designer; I would prefer to learn how to write it properly myself.
There's nothing "improper" about using the forms designer; it's there for a reason, and it can be an incredibly useful time-saving tool. There are places where it's not a great idea to use it, and that's fine (this probably isn't one of those places), but when you do avoid it you don't have to replicate the code it generates like you appear to have done. It's not usually necessary. In this case you've severely over-complicated things.
- Make a new C# Windows Forms application.
- Add a new UserControl.
- In that UserControl's constructor, subscribe to the KeyDown event: KeyDown += MyEventHandler (and implement MyEventHandler).
- In the default form created for you by the application template, drag and drop an instance of your user control from the toolbox to the form.
- Run your application, press a key.
In the default VS 2012 template, this should work fine. You don't need to muck about with your own form subclass, or with storing a static instance of that form within your user control (in fact that's a terrible idea). You're doing a fair bit of really weird / bad things in that code you've posted; I didn't go through all of it but that's probably the reason your events aren't firing correctly. You don't even appear to be calling Application.Run so your Windows event pump probably isn't running correctly.