Game management
You are going about it entirely wrong.
Nobody starts a game thinking, “Okay, this game will have design patterns in it.” They happen along the way once you have amassed enough experience to spot where they belong.
You are rushing things. You can’t learn object-oriented design in a month or likely even a year.
Besides, it’s not as if there is an answer to this anyway. Would it be helpful to tell you that there is usually a “CGame” (or similarly named) class somewhere in most games? That’s about all most games have in common.
Learn to program, then worry about the little details.
L. Spiro
I asked for an example game ...Even if it is small.if you can give me rather than saying that i need to learn OOP...and by the way these are not "little details"..they are big
I just want to ask how to do game management..I mean in terms of classes and their relation..what should be done should i use design patterns or something..i just want to get the ability to think in terms of management..Today i was writing a basic TIC TAC TOE game and tried to think in terms of OOP but i dont know whether i was doing right or wrong.I just did some paper work..i want help.An example game would be helpful and also if there is some good book out there then do tell me also...
You won't go far wrong with these...
http://en.wikipedia.org/wiki/You_aren't_gonna_need_it
http://en.wikipedia.org/wiki/KISS_principle
http://en.wikipedia.org/wiki/Don't_repeat_yourself
As you work on more advanced games you will find that you need to do more design up-front. But that comes with experience.
Start with structured programming (that means functions, loops and no gotos). Tic Tac Toe doesn't need OOP so save it for the next project.
I wouldn't look for books about game programming at this stage. Look for general programming. Anything by Herb Sutter or Scott Meyers is good, assuming you are using C++.
I agree with L Spiro and EWClay on this one. Game programming isn't where you start, but it's a nice place to end up.
When I started programming, all I wanted to do was make games, so as soon as I could render a jpg I was off and running (and crashing and burning). There's a lot of behind the scenes stuff that goes into making a game, at a very abstract level, and understanding all of the fundamentals about procedural and object-oriented programming is an absolute must.
As far as learning how to sketch out your ideas on paper, I would look into buying a book on UML, it's a fairly standard design language for object-oriented programming and you might get a sense for how larger projects are structured from the examples in the book. This is the book that I have, if you want to go that route.
While it's true that OP is putting the cart before the horse in terms of design practices I'd say that it's fully possible to start making games very early in the learning process. You just make games poorly and then move towards making games well. It's really discouraging for an aspiring game dev to hear that they can't make games. The fact of the matter is that a concussed chipmunk can make games give the proper IDE and some help pushing the buttons.runnerjm87, on 09 Feb 2013 - 15:16, said:
I agree with L Spiro and EWClay on this one. Game programming isn't where you start, but it's a nice place to end up.
@OP - You're in the right place (making a small and simple game) and it's good to consider things that will help you in the future. The pertinent advice here is that jumping into those things right now may hinder you rather than helping you. Get comfortable with the language and its dynamics. Once you feel like you have a firm grasp on the language itself just keep coding and start reading stuff habitually. It doesn't have to be a formal thing. Just feed your interest in programming. You can find articles all over the internet about design patterns and different practices. A lot of it will be overwhelming at first, so if you don't get it then just skim it. When you come to a place in your coding where the idea is relevant you'll remember reading about it and then you can go back and re-read it and it will make a lot more sense.
For now, just code and code until you don't get surprised by the language any more. Ideally you want to get to the place where the only reference you need while writing a program is the documentation for any libraries you're using. When you're not interested in picking up your C++ book any more - that's the time to move forward.
Unfortunately there's very little broad guidelines that we can give you about how to think in OOP. You need practice, and if you can manage it, find someone to review your code.
One piece of advice that I can give, is find a book. A book will have examples and hopefully exercises, like you want.
I just want to ask how to do game management..I mean in terms of classes and their relation..what should be done should i use design patterns or something..i just want to get the ability to think in terms of management..Today i was writing a basic TIC TAC TOE game and tried to think in terms of OOP but i dont know whether i was doing right or wrong.I just did some paper work..i want help.An example game would be helpful and also if there is some good book out there then do tell me also...
Instead of thinking game management, think of how you can manage your code. Is your code flexible and maintainable? Can I use this code in other project with very few tweaks?
Well you are in luck because I coded my TicTacBoard last year and still have it as a good reference so I can tell you how you can make your code reusable and how I lay out my game design.
a folder named buttonimages(that contains the images of the cross and X)
a class that setup the TicTacBoard
a class that setup the board logic
a class that is a TicTacToeButton
a class called TicTacToeMain(the entry point of your program)
On a side note, you can also added a class for Player1 and another class for Player2.
Hopefully you can see from my class description that each class sounds like it is an object hence why it is object-oriented.
This comes from experience. I must have written so many programs before I learned and adapted into the good OOP style and practice. No book can do a better job than applied experience! You will make mistakes but learn from them! Draw diagrams before coding! Question your design and bugs(this is bound to happen). I ran into so many bugs when I coded Tic-Tac-Toe despite having experience with Java. But I finished it in less than a day's time. You will struggle, but have fun with it. It is programming-the best thing you can do in front of a computer!
Best of luck with Tic-Tac-Toe!
If you want to turn Tic-Tac-Toe or other simple games into a useful exercise I suggest a few steps:
- Go ahead and start developing without caring about style and "writer's block".
- Finish your game, leaving nothing incomplete or defective. If you have trouble at this point, you need to learn about programming basics or game design, not about OO style.
- With the benefit of hindsight, improve and refactor your code to explore the right way to write it.
Getting someone experienced to review your code and teach you what you did wrong would be vastly better than relying on your insufficient knowledge. - Repeat for a major feature update (e.g. Tic-Tac-Toe with fancy graphical effects) or a new game.
Game management? If you're asking about architecture of game engine, then I would suggest you to get some book what covers the topic. However some "litlle game" developers usually just starts to code and they refactor and manage the game code during the creation process. I think it's quite heavy way to manage the game engine, but some people does it. Usually they have some minor ideas, which they start to implement to code and little by little they manage to create a whole game.
If you are new to coding and game development, the last mentioned way isn't perhaps so bad. It's good way to get to know about the development and coding. Usually you face most general issues when you start from the scratch and by using search pages and books you will get to know about the development quite fast.
Design patterns and class diagrams are quite useless, if you don't have even the most general ideas about your game. Usually it's good way to write even some really high level requirements and from there start to develope your software. Requirements -> some analysis method -> static model -> code.
