Jump to content
  • Advertisement
Sign in to follow this  

[Theory]Tree Diagram Method of Learning: Easier to learn how to create games?

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

I propose a method of learning how to create games for a specific language, under specific rules given by the language and by the SDK we are to use, while not using hard-to-understand concepts.

Specific Language: C/C++
Specific Rules: Using the C/C++ syntax
SDK (Don't know how to say/describe it): Simple DirectMedia Layer (SDL)
Simple Concept: Lazy_Foo's Tutorials.
Normal Concept: SDL Documentation.

Currently, I'm used to SDL for a bit, thanks to Lazy_Foo's tutorials. In fact, it was the tutorials that lead me to think about how we can learn what we wanted to to learn.

Lesson 1: Creating a game.

We know that a game is a loop, doing most of the work within it. So, we could split one cycle of the loop into some groups.

So, we go like this:

It's not accurate, but at least I can get the picture across. I know I skip the initialization part of the game, but I just wanted to jump to the point.

We would to continue creating what's inside the group.
For example, for the loading group, we would use SDL_Load for BMP format files.

And so on...

If the SDK is changed to DirectX, it'll be split up into a lot more stuffs. And there will be a lot more groups.

It's like this, a walkthrough of Virtual Villagers 3: The Secret City. If you look at the spoilers underneath each banner, you'll see how it gives you hints and stuff easily.

However, it's not like MSDN Library, where it does a tree diagram method, without separating the more basic and common stuffs with the intermediate and advanced levels, and it's like a wall of text.

Do you think it's easier to read something like that above, or do you think we should start from the basics and then slowly move upward a notch, one at a time?


What I'm trying to say, is that we should start teaching others starting from the Game Loop Structure. We could teach other basics while teaching the game loop structure, when we are required to do so and understand the prerequisites.

We should use simple vocabulary, for non-English speakers, but willing to learn the programming language.


On second thought, skipping the theory, why am I thinking that the SDL Documentation is hard for me to read and understand, but Lazy_Foo's tutorials are easy to read and understand? What is the key main difference between these two?

What are the key differences between this and the DirectX information in the MSDN Library? Do they just skip the basics and intro of the Win32 and stuffs, and they just jump straight to the topic the readers really wanted? What tutorials out there that readers really wanted to read?

It's a question I just pondered upon...

Share this post

Link to post
Share on other sites
My problems with tutorials: they get straight to the point, so I can make that particular stuff, but no more. The most tutorials I've seen so far (not much, but some) didn't explain the background. So Joe copies the code like a monkey, and if the code needs to be modified later (a new feature 2 months later), Joe is stunned.

For example I have a NEHE-like display list font thingy, then I want to measure the string in pixels, and I have no freaking idea why is it so off. Because I don't have the slightest idea what the initializing stuff really do. So a lot of times I have to dig myself into the topic in the same depth, as I could have done it in the first place.

I'm not against tutorials, but some of them do more harm than good. Setting-up-stuff is good, but when tutorials start to show solutions to particular, non-API/hardware related stuff, I think it's not good. Okay, I can't express it, but there are lots of posts on gamedev.net, that show how many crap tutorials are out there, and how harmful they are.

As to the graph thing you posted:
It's nice, but I guess the game loop is not a good example. These are really trivial stuff, I think there's not much to teach about it. One can discover these oneself with one's first program (hmm, I hate genders in grammar).
I'm not even sure what you are trying to say with the diagram method stuff.
If you make mistakes in the design, this tree graph won't prevent you to make those mistakes.

Graphs are good for presentations or if used when they are really useful. Using graphs/draft is a must with trigonometry/geometry/physics/etc problems (interestingly most people don't know this...).

And another thing: I believe, that there is no "game programming". There is programming. Games have art, meshes/textures/whatever, but they are programs just like any other programs.

Okay, this post is pretty much nonsense.

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!