Best Practices - Studying

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Best Practices - Studying

      I wanted to make a post that could help myself but also anyone else who may be feeling overwhelmed with learning new materials. I've been reading and working on small applications in my spare time and have a game design all written out and everything planned. Now the only hard part is learning to work with a game engine, there is so much at once to tackle that it's nearly feeling impossible.

      My plan is as follows:
      • Start with DirectX portion of GCC4 and initialize a window
      • Layout elements on paper that I wish to add
      • setup the input portion from GCC4
      • Add events for clicks to make sounds


      I'm trying to have some structure to my learning and feel that with the above approach I can tackle them in stages and learn how GCC4 operates, not just from reading the book. While the book is awesome, I want to get hands on with it!

      Please give me input, advice, or even share how you deal studying. For instance how do you tackle new API's, what's your method of learning?

      Thanks!
      Gaddam
      You may call me char 71 97 100 100 97 109.
    • Hi kaykry,

      Thanks for the welcome back appreciated, I still need to do Tetris! I've completed the book for the most part and have been fiddling with TPW. It's so interesting to see all the systems communicate with each other.

      I'm still hopeful that others will chime in with study tactics that help retain information.

      Thanks!
      Gaddam
      You may call me char 71 97 100 100 97 109.
    • For me I cannot retain information without reproducing the pattern in my own coding, I don't mean copying from a book into a cpp file, I mean understanding the code and from the ground up building it from concept alone (with maybe some algorithms I don't need to memorize copied).

      When I make code my own in this way and see it working, I can proudly say at that point that

      a) I have understood the concept and principles of what I am reading/being taught

      b) I have taken these concepts and built a working example of how they work

      c) If I am able to redo this pattern a couple of times I know that not only does it work which signifies I haven't made a mistake in understanding the concept, and that I can reproduce it and add it to my toolbelt of solutions
      PC - Custom Built
      CPU: 3rd Gen. Intel i7 3770 3.4Ghz
      GPU: ATI Radeon HD 7959 3GB
      RAM: 16GB

      Laptop - Alienware M17x
      CPU: 3rd Gen. Intel i7 - Ivy Bridge
      GPU: NVIDIA GeForce GTX 660M - 2GB GDDR5
      RAM: 8GB Dual Channel DDR3 @ 1600mhz
    • mholley519 I appreciate your reply, and it was something I hadn't considered before. I've done a few C++ books and completed the end of chapter exercises, but to actually repeat and try to build it without a helping hand is something I will certainly be focusing on from here on out!
      You may call me char 71 97 100 100 97 109.
    • I hope it works well for you, I started doing it when I was taking courses at the GameInstitute, I thought I would learn something by monotonously rewriting Win32 Initialization and Direct3D device enumeration in order to understand it. When it came down to it I needed to understand the core concepts, just writing it out wasn't helping at all.
      PC - Custom Built
      CPU: 3rd Gen. Intel i7 3770 3.4Ghz
      GPU: ATI Radeon HD 7959 3GB
      RAM: 16GB

      Laptop - Alienware M17x
      CPU: 3rd Gen. Intel i7 - Ivy Bridge
      GPU: NVIDIA GeForce GTX 660M - 2GB GDDR5
      RAM: 8GB Dual Channel DDR3 @ 1600mhz
    • The three most common mistakes I see are:
      1) Reading too much rather than doing something.
      2) Biting off more than you can chew.
      3) Not finishing projects.

      Those three things will kill you.

      I talk about the first point a little at the end of the "A Game of Teapot Wars" chapter. You simply can't expect to read a bunch of books on a particular subject and emerge as an expert. You have to actually do the thing you're trying to learn. Artists call it pencil mileage. The theory is there to help guide you in the right direction and keep you from falling into common pitfalls, but no matter how well Mike and I explain things, we can't turn you into game developers. You have to write a few million (yes, million) lines of code first. You have to make mistakes, you have to try to build something, you have to succeed in some ways and fail in others.

      As for the second one, I can't tell you how many times I've had new developers tell me about their awesome MMO they're going to make. These guys rarely get beyond the rendering-a-box-in-the-world stage because, despite all of your great ideas, game programming is REALLY hard and takes a REALLY long time. This is especially true for beginners. For example, it took Kaykry about a month to get Tetris going. I could probably write it in a long evening if I put my mind to it, so could Mike. Do you really think someone at the same level of experience would make an MMO? Probably not. You have to learn to walk before you can fly. That's why I always suggest Tetris as the first project.

      The third thing is often related to the first two. You have to actually finish something. I hope Kaykry posts his Tetris project to this board so you can see it. It's a complete, finished product. I've read so many posts from people on other boards talking about some technique they use in all their games, yet when you probe them, you find that they only have half-finished projects. They can't complete anything because something else comes up, or they have to rewrite everything, or they can't solve some big problem. Game programming is about solving big problems and about making it work. Architecture and perfect technique is all well and good on paper, but there comes a point when you just have to make it work and get it out the door.

      In conclusion, you have to actually make a game from start to finish. Don't try to make something big; start small and build up from there. Make sure you actually finish it. That's really important. Remember, if you're applying for a game development job, the first things I'm going to look at are your personal projects.

      -Rez
    • I've heard that in general it takes seven years to truly master a skill - that's like all the time you spend in high school and college combined, doing a single thing, and there's still one year to go!

      That's why it is so important to follow Rez's advice and finish projects that you start. If you focus on too many things a once, and never see anything to its conclusion, you won't master the skill.

      But there's also another thing too - and that is by pushing through something that is difficult, rising to the challenge and completing it, you'll gain something that will become a foundation for every challenge afterwards: self confidence.

      Even if you tackle something beyond your current skills, you still can be satisfied that you had the courage to make the attempt, and not sit on the sidelines. Readjust your target, reinforce your skills, and try again when you are ready.

      Those two traits - the willingness to take difficult tasks head on, and the tenacity to try again after a setback, will take you places you never thought you could go.
      Mr.Mike
      Author, Programmer, Brewer, Patriot
    • Rez thank you for that, I've actually readjusted my learning style because I want to achieve something and not just know everything in theory which is how I fell at the present time.

      Mike thank you for that reply, it really made me reflect on my own personal goals, growth, and how I want to achieve what I start. I've done this in the past with wanting to learn Web Development and create an online based game. I got the materials for learning HTML, XHTML, CSS, PHP, and MySQL. I didn't know anything about programming and then I started to dive in. It took me around 6 months to produce a game that fully functioned from start to finish.

      I know I have the ability to absorb the information, but this experience is completely different. I've put into place everything I've learned in the book and have goals setup, before I just went along and did what I could when I could. But I want it to feel more professional and have set standards, I just need to be more flexible with myself as to avoid the overwhelmed feeling that currently surrounds me.

      Thanks for each of your replies!
      You may call me char 71 97 100 100 97 109.
    • Thanks kaykry!

      I'm tempted to look but I'm going to see what I can come up with first, I will visit that link in the future If I can't seem to get started and need a simple boost! I've spent most of the day going back into the basic learning books, I've been going to the end of chapter exercises and completing them.

      I'm doing better than I thought I would, but if I get a hiccup I'm going to stop and cover the material until I have a good solid foundation and then move forward.

      I don't want to rush anything, I want to take my time and make sure I really understand what's happening with the code!
      You may call me char 71 97 100 100 97 109.
    • Originally posted by kaykry
      rez is correct about my experience with Tetris. Here is the link if you wanna check it out:

      I also consider my Breakout clone to be a finished product, at least as far as I'm going to take it:

      Both of those took longer than I initially thought they would. There are just a lot of minor details that keep coming up along the way. You're also dependent on other people if you want art and music.


      Jeez kaykry, you distracted me from my work. Got me playing tetris instead of doing what I should be doing. Tisk tisk. Obviously not my fault for downloading and launching it--I'm the victim here!

      Joking aside, I do have a real question. Your blocks game is very impressive :)! I looked at your source code to get an idea of how you approached making it. I think I've picked an appropriate starting game (pong is about as easy as it gets), but I feel as though I'm picking a bad approach. Basically I'm trying to make my game engine as sophisticated as the one in GCC4 (e.g. fully portable to another game I make afterwards). However I'm starting to think this was a dumb choice. Looking at your code, it looks like you chose to approach it from a more straightforward manner that's less portable. Is this a more appropriate starting method? I'm feeling overwhelmed at the moment trying to include all the extra cool stuff like XML and LUA. I should probably just drop the extraneous stuff.

      P.S. Awesome music and art! Did you get friends to help you out with that? Or did you use some other means to get the art/music? A friend of mine released a game on XBLA; he hired a musician off Craig's list to make the music for him (pretty cheap apparently). Seems like a decent idea to me.

      The post was edited 1 time, last by geshi ().

    • geshi - one of the pieces of advice that I hear all the time over on Gamedev.net is to "make games not engines." However, that does not mean you should completely throw good design and engine architecture out the window.
      The general idea is that you should implement sections of your engine as you need them while building your game project.

      For instance, I started out wanting recreate the DirectX tutorials. So I created my application layer, and a simple renderer to create the basic window.
      The next step was to display a triangle in the window, so I created a basic scene graph and a test triangle node.
      After that I wanted to get the spinning cube DirectX sample going with multiple cubes, so I implemented my actor-component hierarchy. During this I realized that it would be nice to define my data outside of my c++ code, so I implemented TinyXML2 and a resource loader system.

      I think you see where i'm going with this. I currently have a 3D world with a Kinematic controlled player character that interacts with a dynamic bullet physics environment rigid bodies such as platforms and bouncing balls. However, I have no sound system at all because I haven't needed that yet.

      At it's core, a game engine is simply the re-usable pieces of your game project. Thus the phrase, "make games not engines".
    • Kl1X,

      That really simplified everything for me, that's my current plan. I want to keep things very simple and starting out with that approach has made doing tasks possible and much easier. After awhile you'll know your engine and be able to quickly do things.

      Gaddam
      You may call me char 71 97 100 100 97 109.
    • Originally posted by Kl1X
      geshi - one of the pieces of advice that I hear all the time over on Gamedev.net is to "make games not engines." However, that does not mean you should completely throw good design and engine architecture out the window.
      The general idea is that you should implement sections of your engine as you need them while building your game project.

      I agree 100% with this, ESPECIALLY when you're just starting out. I see a lot of beginners fret about making the perfect engine. I've been doing this for 16+ years and I still have made the perfect engine. It's certainly better than the one I made 10 years ago, or even 5 years ago. But it's hardly perfect.

      Concentrate on making games. The engine will come when you get sick of writing the same thing a dozen times.

      The best advice I've read is that if you think you might be interested in this game programming thing we do, lock yourself in your room and make twenty games. Yes, twenty. Not two or three, not a dozen. Twenty. And finish all of them. When you're done, you'll either want to do this for the rest of your life or you won't. You'll also have a good start to an engine.


      I've found that it's really easy to start a project and really difficult to finish one. If I were you, I would just focus on what's needed to finish your game. Otherwise, you could find yourself in a never-ending cycle of trying to improve things. Based on what I've heard, it's important for a beginner to have a portfolio of completed game projects.

      Yes, it is. You need to actually FINISH those 20 games. I will download your game and play it. I do that for each and every candidate that I interview. If they don't have a complete game, they walk in the door with one bad mark against them. I often times don't even bring them in for an interview, especially if they're junior.

      I interviewed three people last week. One candidate brought his laptop with a working game. I played it right then and there, giving him feedback the whole time. I spent five minutes looking over one candidate's code and gave her a mini code review, telling her things that I liked and didn't like about her code. Then I asked her specific questions about how she would change things or how she would tackle a particular problem. I pretended to be a designer and changed her game design, asking her how she would handle it. She even had UML diagrams to show me.

      Having a completed project is probably more important than the degree you have, at least in my eyes. Every interviewer is different.

      In fact, this gives me an idea for a cool challenge. I'll write it up in a new post though. Stay tuned!

      By the way, that girl I told you about? She's on the hire list.

      -Rez
    • Thanks for the advice everyone! I greatly appreciate it! At first I started *too* simple, then I felt like I jumped from level 0 to level 10 (at least in my head). This level 10 is feeling impossible, so I'm glad to know I should definitely be kicking it down quite a number of notches.