Some pointers required for new programmer
Author
I have limited programming knowledge i.e. quite good at VBA and dabbled with very basic Java, VB3 and other bits and pieces. Struggle lots to get my head around OO programming though.
I decided that I wanted to do something with VB 2008 Express and I have an idea to program an obscure board game that I want to solve (i.e work out an 'always win' strategy). Although the game is four-player, it is relatively finite, which is why I think the job can be done.
Some questions
Is there any advice anywhere on getting started programming such games?
I can encapsulate a 'board position' in an object. I think that I should have a 'move' method, which would update a board position. However I do it, I'm going to have loads of 'board position' objects that I'll need to store somehow. Should I just store them in an array or a collection or write them to a database?
I'm struggling to find an article on 'game tree programming' for more than two players so I'm making it up as I go along. At each turn there could be up to five possible moves but most of the time only one or two are actually possible. I thought that I would store 'game over?' and 'move sequence' properties as part of my 'board position' then when a 'game over' position is reached, I'll replay all the moves except the last one and continue from there. I figured that by using this method, I would eventually play out every possible version of the game. Does that sound like a sensible approach?
I'm doing so much 'thinking' and 'planning' and I haven't written a single line of code yet but I don't want to invest a load of time doing it in a certain way only to discover later that I've got it all wrong...
Any guidance or words of wisdom would be very much appreciated.
Many thanks.
RS
Quote:I don't want to invest a load of time doing it in a certain way only to discover later that I've got it all wrong...
Quote:Any guidance or words of wisdom would be very much appreciated.Stop being afraid. Try something. Reflect on mistakes later.
Quote:Original post by oler1sQuote:I don't want to invest a load of time doing it in a certain way only to discover later that I've got it all wrong...Quote:Any guidance or words of wisdom would be very much appreciated.Stop being afraid. Try something. Reflect on mistakes later.
I second this advice. You wont learn if you don't try. I was this way for a long, long time, up until recently. Now I'm just having a go, and getting surprised about what I'm achieving.
I third it.
And an other advice (I'm thinking of putting it into my signature): use paper and pen too, they are always forgotten as developing tools.
And an other advice (I'm thinking of putting it into my signature): use paper and pen too, they are always forgotten as developing tools.
FOURTHED!!11!one~
I assume position is just a set of coordinates? You can define your own object, but I think you might as well use a build in class like a point or 2d vector. I don't see any reason to add methods to such a primitive structure at this time.
Just keep them in memory for now, having to interact with a database is only going to make things more complicated. You probably need some sort of container that can grow in capacity, so a collection or list should work. There might be an optimal data structure for you case, but I wouldn't bother with optimizations like that initially.
Perhaps it is a good idea to start with a simpler problem, like two player Tic Tac Toe? That way you'll get some experience with VB.Net and develop a feel for what's needed for the more complex four player problem.
Depends on how wide and deep this tree of moves would become. It wouldn't work for chess I'm afraid, but this brute force mechanism might be feasible for your problem. It's impossible to tell without knowing the actual game, but in general the problem with exponential growth is that things get big quickly. ;)
But you don't want to spend all this time thinking and planning before implementing only to discover it doesn't work in practice. I don't think you should regard them as two completely separate phases in a project. Think, try it out, observe it doesn't work, think again, adjust your design, feel happy about the improvements, think about extending the functionality, write some more code, get coffee, realize your code is a bloody mess, feel depressed, clean up your design, fell happy again, have a bright idea, implement it, find out things are running too slow, optimize the bottlenecks, read a paper on genetic algorithms, get more ideas etc...
Quote:I can encapsulate a 'board position' in an object. I think that I should have a 'move' method, which would update a board position.
I assume position is just a set of coordinates? You can define your own object, but I think you might as well use a build in class like a point or 2d vector. I don't see any reason to add methods to such a primitive structure at this time.
Quote:However I do it, I'm going to have loads of 'board position' objects that I'll need to store somehow. Should I just store them in an array or a collection or write them to a database?
Just keep them in memory for now, having to interact with a database is only going to make things more complicated. You probably need some sort of container that can grow in capacity, so a collection or list should work. There might be an optimal data structure for you case, but I wouldn't bother with optimizations like that initially.
Quote:I'm struggling to find an article on 'game tree programming' for more than two players so I'm making it up as I go along.
Perhaps it is a good idea to start with a simpler problem, like two player Tic Tac Toe? That way you'll get some experience with VB.Net and develop a feel for what's needed for the more complex four player problem.
Quote:I thought that I would store 'game over?' and 'move sequence' properties as part of my 'board position' then when a 'game over' position is reached, I'll replay all the moves except the last one and continue from there. I figured that by using this method, I would eventually play out every possible version of the game. Does that sound like a sensible approach?
Depends on how wide and deep this tree of moves would become. It wouldn't work for chess I'm afraid, but this brute force mechanism might be feasible for your problem. It's impossible to tell without knowing the actual game, but in general the problem with exponential growth is that things get big quickly. ;)
Quote:I'm doing so much 'thinking' and 'planning' and I haven't written a single line of code yet but I don't want to invest a load of time doing it in a certain way only to discover later that I've got it all wrong...
But you don't want to spend all this time thinking and planning before implementing only to discover it doesn't work in practice. I don't think you should regard them as two completely separate phases in a project. Think, try it out, observe it doesn't work, think again, adjust your design, feel happy about the improvements, think about extending the functionality, write some more code, get coffee, realize your code is a bloody mess, feel depressed, clean up your design, fell happy again, have a bright idea, implement it, find out things are running too slow, optimize the bottlenecks, read a paper on genetic algorithms, get more ideas etc...
The best way to learn is to just try it the way you think it should work. To plan things out a little, but don't overdo it.
You'll probably do it wrong, but that's OK, there's no better way to learn.
Remember, making a game is an iterative process, you're (wall, almost) always going to have to go back and redo/modify things, no matter how well you put them together the first time, so don't be afraid to do something wrong, just learn from it.
Now some original advice, here's the two things I wish I had done when I first started:
1) Pick a naming convention and stick with it. Don't name one variable int globalVar1, and another int gGlobal_var2. It doesn't really matter what convention you use, just pick one and stick to it(this will save you some headaches).
2) Leave plenty of good comments. Take an extra 30 seconds to write two sentences describing what a function does if it is even the slightly bit confusing. You'll appreciate it later.
You'll probably do it wrong, but that's OK, there's no better way to learn.
Remember, making a game is an iterative process, you're (wall, almost) always going to have to go back and redo/modify things, no matter how well you put them together the first time, so don't be afraid to do something wrong, just learn from it.
Now some original advice, here's the two things I wish I had done when I first started:
1) Pick a naming convention and stick with it. Don't name one variable int globalVar1, and another int gGlobal_var2. It doesn't really matter what convention you use, just pick one and stick to it(this will save you some headaches).
2) Leave plenty of good comments. Take an extra 30 seconds to write two sentences describing what a function does if it is even the slightly bit confusing. You'll appreciate it later.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
