what skills and knowledge should a programmer have? (creating arkanoid clone)

Non of those are of any use unless you have a solid foundation in problem solving, programming in general, and data structures & algorithms using a variety of methods/paradigms.

I'm quite serious, doing things like wasting your life learning all the intricacies/idiocrasies of C++ first just because that is what is currently being used in the games industry means absolute nothing, you'll end-up with a narrow view on solutions to problems.

So i strongly suggest you read these books:

• How to Design Programs AKA HTDP (free online)


• Structure and Interpretation of Computer Programs AKA SICP (free online)


• Concepts, Techniques, and Models of Computer Programming AKA CTM (not free)

I don't care if you feel this is stupid or not the route you want to take, these will give you a very solid foundation, learning things like C++ can be done later that should be the last thing to be concerned about. We already have enough poorly written software using poorly chosen or inappriopriate tools such that we don't need anymore.

After you've done that then i suggest probably getting a book on data structures & algorithms.

[Edited by - snk_kid on March 20, 2006 5:39:16 AM]

I would like to add something that many don't consider, but is VERY important. That is 'being able to work in a team' and 'being able to communicate and share your thoughts in a understandable way'. There is way too many programmers out there that is hardcore-developers, but just cannot work properly as a team, because they can't communicate properly what they do.

I agree with Thex0. In fact, most companies look at your ability to work in groups before they even see your skills. It is important to no end, that you can work well with groups, communicate and recieve instruction. More so than if you can write a linked lost from scratch. That can be taught, how you interact in a team is something you have developed over the course of your lifetime.

Afterwards, your understanding of problems and how to approach them, regardless of syntax. I have been asked to solve questions, the details and workings of which I had no idea about, those asking the questin wanted to see how I thought and approached the problem rather than the conclusion I reached.

Finally, you should have a general understanding and familiarity with, in this case, C/C++(or any other language you may be working with, after all, the diference between them is merely syntax, the concepts are all the same. Know how data structs work, know how to manage memory, know all the things inherent with most programming projects. Knowing how to create sound and video is good, but can be learned quickly or even done from tutorials. Know the basics and how things work behind the scenes and you will be fine.

Also, knowing how to create technical specifications, document, comment correctly, and maybe even design(UML) would be superbly helpful.

Hope I helped.

Tang

What snk_kid and Thex0 said. :D


Don't waste your time on specifics like the ones the OP mentioned

Same as what the others said.

Communication and problem solving are far more important than understanding what you have listed. You will always be learning so that is important too.

If I know how to communicate, problem solve and learn then I can learn anything needed for a particular project. Every project is different and requires me to learn something new. So being able to learn/find info by myself via the web or a book is very important. If I have questions then I need to communicate with others either workmates or people on forums. Then I need to be able to problem solve when things don't work as I expect them to with the project.

I mean so what if I don't know Java or collision detection (only an example). I can pick those up pretty quickly but if all I know is C++ and collision detection and I can't pick things up quickly then I am going to struggle as a developer.

Oh and after communication, problem solving and learning then comes a solid foundation in general programming concepts. The stuff snk_kid linked to looked good.

Greig

Getting to know the various api's that you work with could prove very beneficial. Learn how to read through the official docs and it will make your error correcting more effective.

I have to defend myself here.

I like to stress out that what skills a GAME PROGRAMMER should have to DEVELOP A GAME.

Yes I agree on the point that is set forth. Communication. Learn to learn. And basic programming. I already have basic skills in programming. Like C++ and Data structure. Know how to create a program. But to create a game, what are the basic skills?

The single most valuable skill you can have, especially as a programmer (games or otherwise), is problem identification.

Learn how to recognize what you are really setting out to do. Learn how to specify the requirements and restrictions of your goals. Learn how to discover what it takes to accomplish those goals. Specify the problem first, then try to solve it. The difference between failure and success usually lies in how well you understand the nature of the problem you are trying to solve.


What kinds of games are you looking to make? The skills needed for Flash gambling games are utterly different from those required for, say 3D platformers, and yet again different from those required for strategy games.

Know your problem first. Then find a solution. It isn't practical to try to learn all the solutions first, then pick problems.

Quote:

Original post by Zyberant I have to defend myself here.

Well you don't need to defend yourself, i do admit to being abit aggressive/pushy/etc/etc but that was intensional because i thought that way it might get it into your head, don't take it personally if you did then i apologize but that wasn't my intent to offend you personally.

You can either take or ignore advice given but you should take them into serious consideration because they generally reflect people's past-experiences which you maynot have and observable behaviour of those who are less-experienced.

My adivce should help you not go the hard, long, and painful route and learn afterwoods like many of us do because we never knew when we started out.

Quote:

Original post by Zyberant I like to stress out that what skills a GAME PROGRAMMER should have to DEVELOP A GAME.

That is an overally general question that has no good answers because it depends on the game, most commercial large-sized games are created by teams of programmers who take on domain-specific areas like graphics, sound, AI, game-play, engine-development, etc, etc. You don't typically get game developers who do everything (but might help out in different areas now and again) or are good at everything because it's domain specific knowledge that takes many years to learn and that is on top of a everything before.

However there are things you can learn that all games developers should know regardless of domain-specific areas unfornately some of the things they should know the majority do not.

To begin with your core, foundation or whatever you want to call it should be solid. You should be varied, meaning have a wide range of problem solving skills using a number of well established techniques via different paradigms (especially different paradigms) and different models of computation like stateful or stateless programming, concurrency/parallelism etc, etc. That is what those books i linked to will give you i recommend at least reading the first 2 books.

If you're wondering why this matters, well it matters because you'll learn to know how to apply knowledge and use the right/appropriate tools for the job and not just throw C++ or OO at the problem or reinvent wheels.

Those books will give you a solid foundation, after which you can learn all kinds of things but some other things you should generally know for game dev are:

• Calculus (very useful but probably not necessary for all areas)


• Discrete maths (very useful but probably not necessary)


• Some linear Algebra (vectors, matrices, tensors, etc) (this is typically a necessity)


• Maths, maths and more maths (the more you have the more you can do)


• Physcis (Mechanical Physics mostly the rest is just useful to know)


• Scientific Computing (Numerical Analysis).


• Computer Architecture


• Some Computational Complexity Theory


• Data structures & algorithms


• Programming in the large (the above books help here)


• Concurrency/Parallelism Theory and/or Practice using different models not just the typical ones


• I'll probably add more later

From there you pick a specific area you're most interested in and then specialize in it like graphics or AI.

Quote:

Original post by Zyberant I already have basic skills in programming. Like C++ and Data structure.

This isn't really a solid foundation, a book specifically on C++ is not going to give you a solid foundation, it's not going to give a range or a varied level of skills.

Most games are not even programmed in just one language, there programmed with multiple languages, one core and one or more scripting languages.

Like i said before just because the games industry are currently using C++ doesn't mean much. Infact 5-10 years using C++ will become less practical/fessible because it's not really an appropriate tool for large-scale massively concurrent/parallel applications on game consoles with +20s, +100, +1000 multicore processors in large-scale distributed environments. Anyways my point is you need to know and be familiar with different models of computation so you are ready and know when to apply the right tool, by learning very different languages you'll learn some of these models of computation.

Quote:

Original post by Zyberant Know how to create a program.

What about programs in the large? those books above should help you out in that department too.

[Edited by - snk_kid on March 21, 2006 6:30:37 AM]

Thanks for your extensive reply snk_kid. :). Also thanks to all the repliers.

I understand that you have taken another route to your experience in game development.

Well I mean I am not here to read 5 books about mathematic before beginning programming a game. Getting your hands dirty will learn you some tricks that can not be read. This is the practical approach vs. the theoretical approach.

I also believe that even though you have to split the game up in different area, you need a lead programmer that know a little of everything. He is in the end the one going to put it all together.

So given that I am the lead programmer for the next arcade game like akanoid what GAME ELEMENT do I need to know? I am narrowing the question a little here.

Problem specification is a vital skill.

You've narrowed things down, which is good - but that's only the first step. The next thing you need to do is specify the problem. Write out a complete list of the rules of the game you want to make (say an Arkanoid clone). Every time you see a rule, think about how to break it down and express it in code. Repeat this until you have a detailed plan of how the code should work. If you ever find an area that you can't translate to code, that's something you need to learn about - learn it, and then come back and do more code.

If you're going to be a lead programmer, or even just a sole programmer, you have to learn how to attack a large problem like building a game. You have to develop the skills to divide something up into areas of functionality, then figure out how to implement that functionality. If your first project has too many unknowns, pick something smaller and simpler instead - but something that will still force you to learn some techniques and technologies.

Learning how to specify problems and plan out the development of code is probably the single most important skill you can have. The only way to develop it is practice - you have to do it. Even if you're not the lead on a team, your lead is probably going to give you a chunk of functionality to implement, and expect you to either know how to do it, or learn how. If you yourself are the lead, it is mandatory that you can do such planning so you can direct and coordinate the rest of your team.

So you've made a good first step. Now, set out the complete rules of the game you want to make, and try to identify (at a high level) how you would do each thing. If you don't know, don't hesitate to ask - we're here to help you learn, after all. Post that up and we'll see how you're getting along [smile]

Indentifiing and specifiing the problem and make a plan! Thanks I keap that in mind.

Also I will try to make a complete rules of the game.

Here is an overview of what should be in the game.


The rules of Arkanoid :

Arkanoid is a computer game. The game is played inside a box where a ball is bouncing around inside. The ball can bounds on some bricks and the boxes three sides,(left, right and top). The last side (bottom) of the box is empty. But is guarded by a player control bar using to keep the ball from exiting the box. To do this the player let the ball bounce on this bar.

The player have limited attempt to keep the ball from exiting the box. The player controlled bar is now call a bat. The player uses the mouse to control the bat.

Onces the ball hit a brick, the brick breaks and disappear. Some brick have to be hit multiple of time before disappearing. Also some bricks can not be broken. When all the brick that can disappear, disappear then the player have won the level.

There can be many level. Each level has a predefine box containing a setup of bricks. The goal of the player is to break all the bricks in all the level.

The game will have a hiscore that record the points that the player have made. Point will be given for each brick is broken and some time bonus also for that level.

Extras:
When some bricks are broken some gadget can fall down. The player can catch these gadget using the bat. Gadget change the way the game behave. Like the speed of the ball is altered, or the player gets a bigger or smaller bat. Some Gadget just give bonuses to the score.

To make the game more interesting a few bots are wandering around randomly. The ball can hit these bots and the bots dies and disappear, and the ball change direction too.

Resume: I have talk about how the balls behave inside the box. How the level is setup. How the game is played and won, or if not (won) how there is a hiscore to measure onces game.



From here i probably start indentifiend the object of the game like box,bat,bricks,ball, player etc. and setup some relationship of the objects. This will give an overview of the game. And also the objects here can later on be use for the games classes. After this I actually start programming. Deviding the workload into these part: "1. program the core game". "2. add graphics", "3. add sounds", "4. adjust the game" and hopefully it is finished.



To ApochPiQ: What do you think? I guess I need to specified the game element more.

There's quite a good article called Game Development Harder than you think, it covers a lot of the skills required.

Quote:

Original post by Zyberant Here is an overview of what should be in the game. [...]

Good start, you're starting to break down the game into a series of problems that can be solved.

I'd probably set that out a bit neater, but that'll come to you with practice. You seem to have most of the rules covered, as well as the objects you'll need. If I were doing the same, I might set it out as follows:

--------------------------------
Arkanoid:
Setting:
Arkanoid is a ball game played within a rectangular area which is closed on the top, left, and right. The upper region of the play area is filled with a number of bricks which may be in varying positions.

Player:
The player is represented by a 'paddle' which resides at the bottom of the play-field. The player is able to move left and right but not up or down. Movement of the paddle is controlled by the mouse.

Items:
-Bricks (destroyable):
Destroyable bricks have a number of 'hit points' (HP), and are destroyed when this number is reduced to 0. Bricks are stationary objects within the play-field.
-Bricks (obstacle):
Obstacle bricks are stationary objects within the play-field, and cannot be removed.

Objective:
The player's objective is to attempt to clear all removable bricks from the level. Each brick the player removes will yield a number of points which are added to the player's score. If the player is able to remove all removable bricks, they will advance to a new level with a different layout.

The player will lose a life if the ball passes thier paddle and leaves the bottom of the play area. If all lives are lost the game is over, at which point the player will be presented with thier score.

Rules:
- The ball will bounce off of any objects it touches using a basic line of reflection.

- If the ball touches a brick (destroyable), that brick will have it's HP reduced by 1. If the HP of any brick is reduced to 0, that brick will be removed.

- If all removable bricks are gone from the level, the level is completed.

- If the ball leaves the play-field, the player loses a life. Once all lives are lost the game is over and the player's score should be presented.
--------------------------------

I've left out bonus items and bonus points based on time, but you can see I've described things in a neat and organised way. You can see there what the play-area should be like, how the player is presented, what objects are needed, and what rules need to be applied. You could also use some diagrams to make things clearer - this can be especially useful if you're describing the problem for someone else, which may at times happen.

You did a good job actually, just try to group things that go together and try to make sure it's easy to figure out - you might write out something like that for yourself and then leave it for a while before moving on, so you'll want to be able to figure it out again later. You also might be preparing it for someone else, in which case they'll need to be able to understand it as easily as possible. You certainly don't have to do it the same as I did (and there's a good chance I've missed some things aside from what I left out on purpose, I've been awake for far too long [lol]), just make sure it's set out so you can understand it. For simple projects you'll be able to do this without writing anything down once you get used to it btw, but it's good practice to write something down while you're learning.


So now you've got a breakdown of the rules of the game and what objects you need. What else did ApochPiQ say?

Quote:

Originally posted by ApochPiQ Every time you see a rule, think about how to break it down and express it in code. Repeat this until you have a detailed plan of how the code should work.

Think you could have a go at that? Your breakdown of the rules was pretty good, now you need to figure out how you would turn them into code - you don't neccesarily want to write code immediately, but might start off with a general overview of what needs to be done. I often figure out what functions and datastructures I'll need, but don't actually put any code in those functions to begin with.

For example, take one of the items we described earlier:

Quote:

-Bricks (destroyable): Destroyable bricks have a number of 'hit points' (HP), and are destroyed when this number is reduced to 0. Bricks are stationary objects within the play-field.

How am I going to describe those in code? One way I could do it is using a struct, with integers for an x and y coordinate within the level, and an integer for the number of hitpoints, which could look like this:

struct destroyable_brick {int x;int y;int hit_points;};

Perhaps you could have a go at doing that for the other objects? You might have a different idea for how you could implement that destroyable brick as well - there are definately other ways of doing it (you could use a class...). I'm sure if you give it a shot you'll be able to figure out how to represent the objects, so how about the rules as well?

Quote:

- The ball will bounce off of any objects it touches using a basic line of reflection.

Can you figure out how you'd represent that rule in code?


Hope this is helpful. [smile]

The data structure of Arkanoid:

Looking through the nouns in the two problem specification. I come up with the following important objects. This method is how I did a Tetris clone.

gamegame objective, game is over, game is won (probably a property of game)play field, box, rectangular area, play areabox sides :left, right, up, bottom (property of play field)upper region, layout, a setup of bricks (property of play field)bricks, destroyable bricks, obstacle bricksbrick position (property of brick)playerpaddle, bar, batmouselevelgoal (property of game)hiscoreplayer score (property of player)point,  bonus point, time bonus (property of brick)botlife (property of player)objects (generalize of brick, paddle, play_field)basic line of reflection

Note some of the objects have different names. But they describe the same. These are put on the same lines.

I arrange it:
The object that can be seen in the game are :
BALL, BRICKS, PADDLE, PLAY_FIELD, HISCORE, BOT, GADGET

The less obvious objects are listed here they are often containers:
GAME, PLAYER,LEVEL

The objects that I don't know what to put up with are here:
BASIC LINE OF REFLLECTION ( this is more like a function)
MOUSE

Data structure:BALL : float x , float y, float radius.BRICK : float x, float y, float x_size, float y_size, int hit_points,  bool destroyable,  int point;PADDLE: float x, float y, float size;BOT: float x, float y, float radius, int hit_points, int point.GADGET:float x, float y, float radius, int point.PLAYFIELD:  list of bricks,  float left , float right,  float top, float bottom;SCORE: int points, char name[4] .HISCORE list of score.PLAYER: int score, char name[4].GAME: player m_player, list of levels, hiscore m_hiscore.LEVEL: playfield m_playfield. ball m_ball, paddle m_paddle, list of bot, list of gadget

Description of the data structure.

The base object or class (which I will call here) is GAME. It contain the player data and a list of levels and the hiscore. The level are actually the gameplay of the game. It contain all the visual objects in the gameplay, like ball, bricks, paddle, bots, gadgets.

Moving object like BOT and GADGET have a radius . It could have been a bounding box.

Most of the visual object have a x and y position and a radius or size that describe its size. Some object that are breakable have points and hit_points.

The PLAYFIELD have a left, right, top, and bottom these are the coordinates for the sides of the playfield.

The PAYFIELD have a list of bricks. This is a very quick way to describe the content of the playfield. I notice that depending on how you define the list it affect the gameplay and the core programming of the game. If the list is a two dimension array like the original Arkanoid this will give a different gameplay than if the bricks can be places any where. I think i choose the array method it is simpler and simpler to make a level for.

Next will probably be defining the rules.

Very good work! That's exactly the kind of approach you need.

What you've got at this point is a very good plan of the nouns of the system - the elements of the game and their properties. As you mentioned, the next step is to define the rules, or more precisely the verbs - how each element interacts.

Once you have the elements defined, and the interactions between them, you're actually about 75% done with the hard part of the project. Writing the code to fill the design should be pretty straightforward, since you've already defined clearly the properties of each element and how they affect each other.


As you may have been discovering, sometimes you don't actually need to "know" as many things at the beginning as you might think. As you design, you'll automatically find solutions and ideas that you are familiar with. Sometimes you may find an area that is not familiar (say, collision detection) and then you know what you need to learn. To use the collision detection example, you might find out that you don't have a clear way to tell when the ball has hit a block. You now know the specific problem you need to solve, and you can then ask specifically for help on that problem. Even if you don't know the term "collision detection," you know enough about what you want to do that someone can probably tell you the term very quickly, and that will help you find more resources.

Basically, by learning how to specify problems and plan your solutions, you always make sure that A) you only have to learn things you need to know, and B) you know precisely what you need to learn, which makes it much easier to actually find what you need.


Keep it up - believe it or not, you've already got a good start on the single most important skill you can have. Learning never ends, especially in programming, and especially still in game programming. Knowing how to learn, and, more importantly, what to learn, will put you at a good advantage.

Thanks for all the replies and input.

The creation of the Arkanoid Clone have now this homepage:
http://www.geocities.com/zyberant/index.html

This page below continue the rules analysis of the game.
http://www.geocities.com/zyberant/arkanoid_page3.html

If I make any progress or stuck to a problem. I will post message here a gamedev.