Visual Basic Backgammon Game project HELP

So this is in relation to my A Level NEA.
Right now I'm just trying to make a basic backgammon game in console application. The board would be represented by (lets say) a single-dimensional array, etc.
I'm pretty bad at programming so I'm kind of f'ed for my A level. Any help with the VB Backgammon would help thanks.

Also any advice on making backgammon on Unity.

Reply 1

winterscoming

Have you started out by writing out your objectives and analysing the rules of backgammon? You can't write a program to get a computer to do something, unless you already fully understand the thing you're trying to get it to do yourself.

If you haven't already, start out by writing a clear, specific, unambiguous, objective, detailed list of all the rules of how your backgammon game is going to work from a user's point of view step-by-step down to individual inputs and explaining precisely what all of your inputs and outputs actually mean.

You need to decide things such as:

•

What should the program look like when it first starts up? i.e. what is the very first thing the user sees on the screen?

•

What thing(s) should the user expect to input when they're at the first screen?

•

Afterwards, what will the program look like? Are there different possible outcomes? What should the user input next?

•

What happens when the user types something in incorrectly?

•

Will the program display a 'board'? What will that look like? Will you be using different symbols and/or colours to represent different things on the screen? What symbols/colours? what will they represent? Will users see messages appear? if so, where?

•

What inputs/commands will the user(s) type in order to play the game? What are the valid and invalid commands/inputs?

And on another note - make sure you put Game rules in your objectives too e.g.:

•

What happens when a user puts down a piece?

•

What constitutes a valid or invalid move?

•

When does a player move / which player goes first?

•

What happens if a player can't move?

•

How does a player win/lose?

•

What are the draw/stalemate conditions?

At the very least you should write out a list of objectives which describe a 'minimal' working program which is actually able to do 'something', even if that 'thing' doesn't actually follow any - for example, you could begin with a program which simply allows users to place tiles anywhere on the board and worry about your rules/logic later

It's actually a good idea to keep your user-interactivity code/logic completely separate from your game/program logic -- write these into separate classes/methods if possible -- i.e. if you have any classes/methods which do any kind of "game logic", then make sure those classes/methods do not handle any kind of Console Read/Write statements. you'd benefit from keeping those core game/logic methods to be entirely data-driven and completely agnostic to your console I/O, or any files, etc. (The basic principle is "separation of concerns" -- i.e. a function or class should do one thing and do it well rather than being a melting pot of everything)

I'd strongly recommend writing methods which "do" one thing where the "thing" a method is doing can be summarised neatly in the name of the function/method. for example, you could have a "DrawTheBoard" method, whose purpose is just for drawing the board on the screen.

Or maybe you could even write a 'Screen' class whose sole purpose is to contain various methods which simply write different things to the console screen, handling different colours, and updating the console cursor position. -- this would be a good way to keep all of that fluff away from your core program logic.

Similarly, you could consider another separate class which is responsible for handling the command-line inputs from the user and interpreting those into things which more closely resemble the objects/values for your game.

Also consider carefully how you'd model the data in your game and try to make sure that you avoid unnecessary duplication or storing unnecessary data (e.g. don't store "redundant" values which are easily re-calculated from calling a method).

You mentioned using an array to represent the board in-memory, which is a good start, but perhaps you could go better than that and think about Object Orientation and Encapsulation to wrap your board array inside its own class alongside all of its closely related methods which handle the game's board logic?

Make sure you fully understand any maths/logic that you'll be using for your game - for example, what steps are you going to perform to make sure a user's move is valid? It may help to think in terms of 'rules' -- it's fine to have multiple rules; in fact, you may even find that a program filled with lots of small, simple rules in separate functions is much easier to write.

Lastly, remember the golden rule of programming (and many other things) which is K.I.S.S. (Keep-It-Simple,Stupid) -- https://en.wikipedia.org/wiki/KISS_principle If you can keep things simple, then you will find everything gets easier.

•

Don't write long monolithic functions with tonnes of complex, nested loops and "if" statement all mashed up like a big ball of mud.

•

If you find yourself using loads of big, complex boolean statements then split them up.

•

Avoid copy-pasta code which repeat the same logic with different data - Try generalising repeated code into small, re-usable functions. -- Don't Repeat Yourself - https://en.wikipedia.org/wiki/Don%27t_repeat_yourself

•

Avoid using "global variables" (public static variables) because those lead to "spaghetti" logic -- global variables and private class variables are easier to follow.

Try these video tutorials for some explanation of the VB.NET language and how to use various keywords/features, as well as the terminology used: https://mva.microsoft.com/en-us/training-courses/visual-basic-fundamentals-for-absolute-beginners-16507?l=jqMOvLKbC_9206218965

Also, Microsoft's documentation on MSDN is pretty comprehensive - https://docs.microsoft.com/en-us/dotnet/visual-basic/getting-started/

Sometimes you'll find C# examples on Microsoft's site where there's an option to switch to VB.NET -- it's usually a dropdown in the top-left corner - this is especially true when you're looking at things like examples for how to use the various built-in functions and libraries - e.g. String, List, etc - e.g. this page has a language dropdown menu in the top corner for all the List examples: https://docs.microsoft.com/en-gb/dotnet/api/system.collections.generic.list-1?view=netframework-4.7

There's a bit of a lack of good online resources for VB.NET Programming online unfortunately, but if you have any resources for C#, then you can automatically convert those into VB.NET using this clever Visual Studio plug-in

•

https://marketplace.visualstudio.com/items?itemName=SharpDevelopTeam.CodeConverter

VB.NET and C# are "sibling" languages, which, despite having different syntax/grammar rules are identical under-the-hood -- Microsoft built a whole family of programming languages which all do exactly the same thing and run on top of exactly the same runtime/framework -- so a snippet of code which works in C# will always have a 100% identical equivalent in VB.NET and vice-versa. This is really handy because it means that if you ever find an example of someone solving a problem in C#, then the visual studio plugin will convert it into VB.NET for you :smile:

There's tonnes of VB questions/examples here too -- if you get stuck with a particular part of the language, then try searching for various key words or method/class names on StackOverflow: https://stackoverflow.com/questions/tagged/vb.net
(Again, if you find the question you want on Stackoverflow answered in C# then it'll probably be almost the same in VB.NET -- you can use the tool to convert it)

(edited 5 years ago)

Reply 2

winterscoming

As for writing it in Unity3D, You won't be able to write VB directly into Unity -- to be honest, if you're uncomfortable with programming, then the amount of messing around you'd need to do is probably going to cause you a lot of trouble. It's not worth doing. If you want to use Unity then realistically your best option is to write it in C#.

Otherwise, you're going to have to complete most of the same tasks that you'd be solving for your console app so most of your core logic would be the same. Of course, with Unity you wouldn't be using Console.WriteLine or Console.Read statements, nor would you be doing funky things with the console cursor position or console colours; you might have fewer commands and use more 'mouse clicks' instead. But I'd imagine the overall complexity would be the same or higher in Unity because the UI framework in Unity is likely to be more complex than the complexity of console read/write.

If Unity interests you, then it'd be worth looking at tutorials for Unity for drawing your board, handling your keyboard/mouse inputs, and maybe finding some tutorials for 2D turn-based games in Unity for something similar (e.g. there might be a noughts-and-crosses a.k.a tictactoe game tutorial online somewhere)

On the other hand, if you get the structure your console app in the right way, then all of your console input/output stuff should be far away from your core game logic, and it'll be a matter of writing a different UI for your game, but essentially reusing all of the same logic -- if you're able to do that, then it means you've been successful in de-coupling (separating) your core game logic away from the console/keyboard I/O and user interactivity logic.

(edited 5 years ago)

Reply 3

eren230

Wow firstly thanks so much, reading this just gave me lots of ideas of what I will be doing for the game, I'm kind of a lost cause for this A-level but I want to still try as hard as I can. In relation to the Unity project I will be doing it in c# I will just be trying to learn c# as I go following Unity tutorials of other board games etc.

My programming skills are quite poor, and adding OOP will be quite challenging for me so any advice on where i can implement OOP would be pretty helpful. Right now I am just trying to make a simple backgammon game where there may be bugs and errors but once I have the simple foundation I can then proceed to build up and fix it.

As for my board, it is going to be represented in a one-dimensional array (for now, hopefully) and I wanted to make build up on that and make it more advanced...Again any advice as for the implementation/programming would be greatly helpful.

Just a note, as someone may have a better solution, my program uses negative numbers to represent the white checkers, black checkers represented by positive numbers and so on.

Thanks a tonne !

(edited 5 years ago)

Reply 4

winterscoming

Original post by eren230

Realistically I'd think that a large chunk of your backgammon game for Unity will essentially use a lot of the same logic as your backgammon game in the console (and you can auto-convert between C# and VB). Your only difference is having a Unity-based UI with graphics and input events, compared with a text-based UI which uses the console cursor position and 'raw' command-line inputs. Ideally, your UI/front-end for the game would be dumb, stateless and simple without containing any backgammon logic beyond the minimum necessary to render the board/counters/messages.

Also don't forget that a large chunk of your marks are for your report/write-up, so you make sure you're putting the time and effort into your objectives, analysis, tests, UI mockups, design, etc. -- even if your game doesn't quite work as well as you'd hoped, or there are bits missing, you can still do well on the project. Don't throw away easy marks!

Original post by eren230

My programming skills are quite poor, and adding OOP will be quite challenging for me so any advice on where i can implement OOP would be pretty helpful. Right now I am just trying to make a simple backgammon game where there may be bugs and errors but once I have the simple foundation I can then proceed to build up and fix it.

Generally speaking, OO is nothing more than a way of organising and structuring your code (although it involves knowing a few basic language mechanics like classes, methods and object creation - but this is bread-and-butter stuff which shouldn't take long to pick up).

The purpose of OO is to make things simpler by breaking things down into smaller pieces, and organising those smaller pieces together by grouping them up in such a way that makes sense when it comes to looking at the code and understanding what's happening.

From an OO point of view, it often makes sense to split core logic away from anything which reads/writes to the console, for example - if you decided to write a method which draws the current state of your board on the screen, then that might sit in the same class as another method which writes messages to the user.

In a non-OO procedural program, you would probably break everything down into lots of small, stand-alone functions, which each "do" a single thing. Those would probably just be scattered around with no particularly logical way of grouping them together.

OO thinking is all about identifying individual things which naturally belong together and creating a grouping (class). A class usually has a name which relates it to something that you'd be able to relate to in the problem you're solving - for example, your backgammon game might involve concepts like your Screen, Command Line, Game Board, Player, Player Move, Input Command, Game Rule, etc. That's not to say all of those concepts should necessarily be represented as classes, but it's a starting point which might help you figure out how you might group your methods and data together.

.
Ideally you'd make sure that each method has a small, single, well-defined purpose or responsibilitiy - for example, drawing the board, or writing a message to a user, or parsing an input from a user, or placing a counter on the board, etc. It's always preferable to try to do this and have a program filled with lots of very short, simple functions/methods, than to write large monolithic functions which are a melting pot of everything. This frequently means writing more lines of code, but the code itself should end up being much simpler, easier to understand, easier to work with, easier to debug, etc.

It can help to look at the purpose/responsibility of your methods and find similarities in purpose - for example, multiple methods whose purpose is to read or modify the same list/variable, or multiple methods whose purpose is to affect the things you'd see displayed on the screen. Those are candidates for grouping together in the same class, and the class is likely to be named after the similarity (e.g. a 'Screen' class for methods whose sole purpose is to write to the screen)

A common "pattern" is to create 'view' classes whose responsibility is for the appearance and layout of the screen, and the presentation of data/messages. Then making sure that any classes responsible for 'core logic' have absolutely no logic related to the screen, appearance, presentation or layout, nor any mechanics for reading/validating user input, etc.

Lastly, OO programming is very much about thinking about writing functions which relate to the real-world things your program is trying to achieve, and how your functions look from the "outside" perspective of the parts of your program which actually use those functions. In other words, being able to write code which exposes what the program is doing in terms of the real-world behaviour (relating to your game rules/objectives in this case), while hiding the nitty-gritty low-level detail of how the program actually does those things programmatically. (This is an important OO concept called abstraction - i.e. selective ignorance).

You can write higher-level code that orchestrates everything together in a way which looks simpler, more natural and more expressive . For example, you might end up with code which looks like this (C#):







Player currentPlayer = game.GetNextPlayerTurn();
screen.PromptForMove(currentPlayer);
Move move = commandLine.ReadMove(currentPlayer);
Board board = game.GetLatestBoard();
bool isMoveValid = board.CheckValid(move);

if (isMoveValid) 
{
    game.UpdateBoard(move);
    board = game.GetLatestBoard();
    screen.Redraw(board);
}

The important part of the code above is that there's a sequence of methods which do not care "how" any of those functions actually work; there's simply a workflow of steps, all of which would probably make sense to someone who understands the concepts in the game. Each step may actually involve some more complex low-level logic dealing with lists, arrays, and console.write or console.read commands; but abstraction is all about hiding away that stuff. All of that low-level detail is hidden away behind individual functions. The higher-level code above only really cares about the concepts related to the game, so its responsibility is making sure the game steps happen in the right order, rather than worrying about low-level or external stuff about lists, data, board calculations, the console window, input devices, etc. .

Original post by eren230

As for my board, it is going to be represented in a one-dimensional array (for now, hopefully) and I wanted to make build up on that and make it more advanced...Again any advice as for the implementation/programming would be greatly helpful.

That seems sensible to me. One-dimensional arrays often turn out to be simpler to work with than a 2D array for most things, so I can't really think of any reason not to do this.

The main advice I'd give would be to think about using a class to create a logical grouping between your board array and the game-logic methods which read or modify its contents. For example, if you needed a method to check whether a square on your board is adjacent to one occupied by another piece, or a method to check whether a square on your board is already occupied, then it could make logical sense (from an OO point of view) to bundle those methods inside the same class, and to make your array a member of that class.

Original post by eren230

Just a note, as someone may have a better solution, my program uses negative numbers to represent the white checkers, black checkers represented by positive numbers and so on.

Again, that seems sensible to me - I can't really think of any reason not to do that. There'll always be dozens of different ways to solve problems like this - you'll rarely find a 'right' or 'wrong' ways to represent data as long as they work for you and they make sense.