• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
freeworld

what would be the proper oop way to do this?

18 posts in this topic

Ok I feel like I'm a pretty good programmer but all my learning is self taught, so I'm trying to brush up on the "proper" ways to implement specific design patterns and other programming techniques. This situation kinda has me at a stand still scratching my head. I know how I would normally do it and for something this small it'd probably be the easiest without causing headache down the road. But I'm trying to learn so...

First to paint a picture, for the sake of this question the game is similar to 'Checkers'. Theres a game board that only two players play on. All the game pieces are the same except that they belong to different people.

What I'm wandering about is who should own the game pieces and how would interaction with the pieces be handled in all respects to OOP?

The way I would do it is the player would own the pieces and handle the interaction with the pieces. The first thing that pops out to me though is interaction between different players pieces would require each player to have some knowledge of the other players pieces. This makes me think I should have another class/function outside the player that handles player input and interaction with game pieces and just pass the whole lot of info to this controller. Am I on the right track with that?
0

Share this post


Link to post
Share on other sites
Agreed. Just a 2D array of enum values something like {EMPTY, PLAYER_A_PIECE, PLAYER_B_PIECE} could represent the board state internally and then member functions using the [url="http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller"]MVC[/url] architecture would probably work great.

This would most likely use the least resources and be the most convenient way to trigger interactions between the pieces, since all the information belongs to a single class. Edited by Khatharr
0

Share this post


Link to post
Share on other sites
I agree, - players can observe the board and act on that by moving pieces when it's their turn.
The pieces compose the state of the game on the board, but don't do anything to change it on their own.
0

Share this post


Link to post
Share on other sites
I'll agree. OOP doesn't make a whole lot of sense here.

You may find this valuable: [url="http://chessprogramming.wikispaces.com/Board+Representation"]Board Representation[/url] [Chess Programming Wiki]

Skip to the bottom and you'll find tons of great articles on the subject.
0

Share this post


Link to post
Share on other sites
[quote name='recompile' timestamp='1353035588' post='5001430']
I'll agree. OOP doesn't make a whole lot of sense here.
[/quote]

Representing each piece as an object doesn't make sense, but OOP is fine in terms of implementing the board itself. A class would be a good way to isolate the data and provide a standard means of observation and safe manipulation. The benefit, like frob pointed out, is that implementing in this way allows a 'player' to be more or less anything (local player, network player, AI, chicken with a USB port wired to its brain, etc). Edited by Khatharr
2

Share this post


Link to post
Share on other sites
[quote name='Khatharr' timestamp='1353042217' post='5001442']The benefit, like frob pointed out, is that implementing in this way allows a 'player' to be more or less anything (local player, network player, AI, chicken with a USB port wired to its brain, etc).[/quote]

Not to start a holy war, but that's not really a benefit of OOP in this case. Wrapping the whole thing in a class is just one of many solutions that afford those same benefits, and may not ultimately be the best solution.

Yeah, that'll start a holy war. I should probably bow out at this point...
-3

Share this post


Link to post
Share on other sites
[quote name='recompile' timestamp='1353035588' post='5001430']I'll agree. OOP doesn't make a whole lot of sense here.[/quote]Who are you agreeing with?
"[i]Not everything has to be it's own class in OO[/i]"[b] != [/b]"[i]OO is nonsensical here[/i]".
If everything in OOP [i]had[/i] to be a class, we'd be writing code like below, which we don't --
[font=courier new,courier,monospace]Assertion( Comparison( Adder( Integer(1), Integer(1) ).Result(), Integer(2) ).Result() ).Check();[/font]
[quote name='recompile' timestamp='1353049509' post='5001464']Yeah, that'll start a holy war. I should probably bow out at this point...[/quote]Yes, in a thread asking how to use OO design in a specific situation, you're just trying to OO-bash, poorly.

Please no one take the bait.
2

Share this post


Link to post
Share on other sites
[quote name='Hodgman' timestamp='1353051820' post='5001470']
[font=courier new,courier,monospace]Assertion( Comparison( Adder( Integer(1), Integer(1) ).Result(), Integer(2) ).Result() ).Check();[/font]
[/quote]

Smalltalk says Hi (I wonder why it never got much traction [img]http://public.gamedev.net//public/style_emoticons/default/wink.png[/img] )
1

Share this post


Link to post
Share on other sites
[quote name='Hodgman' timestamp='1353051820' post='5001470']
If everything in OOP [i]had[/i] to be a class, we'd be writing code like below, which we don't --
[font=courier new,courier,monospace]Assertion( Comparison( Adder( Integer(1), Integer(1) ).Result(), Integer(2) ).Result() ).Check();[/font]
[/quote]

[source lang="ruby"]smile if Ruby.isBeautiful?[/source] Edited by Khatharr
0

Share this post


Link to post
Share on other sites
[quote name='Khatharr' timestamp='1353070319' post='5001521']
[quote name='Hodgman' timestamp='1353051820' post='5001470']
If everything in OOP [i]had[/i] to be a class, we'd be writing code like below, which we don't --
[font=courier new,courier,monospace]Assertion( Comparison( Adder( Integer(1), Integer(1) ).Result(), Integer(2) ).Result() ).Check();[/font]
[/quote]

[source lang="ruby"]smile if Ruby.isBeautiful?[/source]
[/quote]
[source lang="c"]
is_readable? depend_on_dev() : ruby_char_saver();
[/source]
1

Share this post


Link to post
Share on other sites
I usually tend to design more in terms of state and transformations.
Think about what structure can represent each valid configuration of your game unambiguously. Then think about which are valid transformations on that data and which actor has the authority to do these.

This should lead to a nice code structure will well defined operations where classes control the integrity of the game state.

EDIT: I realized this sounds pretty vague. Maybe it is because that's the way one should design regardless of language. I guess the TL;DR version would be: Don't think of OOP as a philosophy that forces you to program a certain way. Rather, think of it as a tool set that enables you to more efficiently implement a sensible design. Edited by Madhed
1

Share this post


Link to post
Share on other sites
[quote name='SuperVGA' timestamp='1353079295' post='5001555']
[quote name='Khatharr' timestamp='1353070319' post='5001521']
[quote name='Hodgman' timestamp='1353051820' post='5001470']
If everything in OOP [i]had[/i] to be a class, we'd be writing code like below, which we don't --
[font=courier new,courier,monospace]Assertion( Comparison( Adder( Integer(1), Integer(1) ).Result(), Integer(2) ).Result() ).Check();[/font]
[/quote]

[source lang="ruby"]smile if Ruby.isBeautiful?[/source]
[/quote]
[source lang="c"]
is_readable? depend_on_dev() : ruby_char_saver();
[/source]
[/quote]

"Programmer" (n) - A person so utterly maladjusted that they can take a language as beautiful and expressive as Ruby and write something that looks like a declaration of war composed by a drunken, illiterate Klingon.

Some people's Ruby makes me want to hurt myself.
...
Or them.

lol Edited by Khatharr
1

Share this post


Link to post
Share on other sites
[quote name='Khatharr' timestamp='1353104524' post='5001656']
[quote name='SuperVGA' timestamp='1353079295' post='5001555']
[quote name='Khatharr' timestamp='1353070319' post='5001521']
[quote name='Hodgman' timestamp='1353051820' post='5001470']
If everything in OOP [i]had[/i] to be a class, we'd be writing code like below, which we don't --
[font=courier new,courier,monospace]Assertion( Comparison( Adder( Integer(1), Integer(1) ).Result(), Integer(2) ).Result() ).Check();[/font]
[/quote]

[source lang="ruby"]smile if Ruby.isBeautiful?[/source]
[/quote]
[source lang="c"]
is_readable? depend_on_dev() : ruby_char_saver();
[/source]
[/quote]

"Programmer" (n) - A person so utterly maladjusted that they can take a language as beautiful and expressive as Ruby and write something that looks like a declaration of war composed by a drunken, illiterate Klingon.

Some people's Ruby makes me want to hurt myself.
...
Or them.

lol
[/quote]

That's true. Yet have I to see a language that assures whatever is written to look beautiful.
There are war-declaring drunk illiterate klingons everywhere. :D
I do think Hodgmans example involved somewhat more levels of encapsulation, but I do get what you mean.
0

Share this post


Link to post
Share on other sites
There are no "right" ways to do OO design, just like there are no right ways to do data modeling. There are ways that let you get working code, with more or less trouble than other ways, for different values of "working code" and "trouble".

But I'm going to illustrate some code suggestions, with incomplete examples, if you'll allow me the liberty. My goal is simply to get you thinking and get your design juices flowing with some concrete starting points.

First, I'm going to assume that I'm dealing with a fixed size 8x8 chess / checkers style board, and a game with well know rules and fixed sets of pieces. Not because that matters, but because it will let me focus on certain parts of the problem first, while changing those things would require going a few levels further down the rabbit hole.
[source lang="plain"]
Player
Name

Piece
Type - { Knight, Rook, etc. }
Owner : Player

Square
Color
HasPiece : bool
Piece

Board
ClearBoard() - makes the board completely empty

AddPiece(Piece) -
RemovePiece(Location) - removed the piece at the specified location
MovePiece(Location source, Location destination) - take a piece off of source, puts on destination
- in my version I raise an error if no piece exists at source, and also if destination is not empty.
- that's because I want my "game engine" deciding if pieces can kill pieces, etc - not my board.

SquareAt(Location) : Square - returns the square requested, or throws out of range exception

EachSqaure() : Enumerator<Square> - enumerates all 64 squares
... you can write other enumerators that might be useful for your game, such as ...
EachSquareInRow(int) : Enumerator<Square> - returns the list of squares in the specified row
EachSquareInColumn(int) : Enumerator<Square> - returns the list of squares in the specified column
EachSquareForPlayer(Player) : Enumerator<Square> - the list of squares with pieces of the provided player

ChessEngine
InitializeChessBoard(Board emptyBoard, Player white, Player black) - constructs and places the white and black pieces on the board.
IsValidMove(Board, Player, Location, Location)
IsInCheck(Board, Player) : bool
IsInCheckmate(Board, Player) : bool
EachValidMove(Board, Player, Location) : Enumerator<Square> - returns each move the player can make from the selected location. returns an empty list if no valid moves exist

ChessGame
Board : Board
Players : Player[2]
Turn : int
Phase : int - 0 for white, 1 for black
[/source]
I don't have time to go any further right now ... and of course this design would change and evolve for any real-world coding exercise ... I just wanted to give you some concrete thoughts about the types of things that might be classes and their methods. Good luck.
0

Share this post


Link to post
Share on other sites
The best OOP exercise I can think of with checkers is the difference between a regular piece and king.
Chess would probably offer a lot more exercises due to the differing pieces; now you can have a (virtual) method to select the icon to draw, a (virtual) method to get the valid-moves-template, etc...

In checkers you have to force it by having a IPiece interface and implement it in a RegularPiece and a KingPiece class.


Oh as mentioned above 'moves' are a great OOP exercise - it's a proxy for Undo which is a beautiful OOP example.
You have an IMove interface that has two methods, Move and Unmove.
Then you have two stacks, the Undo stack and the Redo stack.
Whenever you make a move you create a Move instance with all the info you need to make the move then execute the 'Move'.
Then push it onto the Undo stack. If the user waps an Undo, you pop the Undo stack and 'Unmove' then push it onto the Redo stack.
(If they wap Redo, you pop the Redo stack and execute it.)
If the Undo or Redo stack is empty, grey-out the respective buttons. Edited by Shannon Barber
0

Share this post


Link to post
Share on other sites
This isn't necessarily directly applicable to your case (right now, at least), but I think thinking about [url="http://www.cs.colorado.edu/~ralex/papers/PDF/OOPSLA06antiobjects.pdf"]Antiobjects[/url] more can be very useful and constructive to good design. For example, I once made a game where there were hundreds of units doing pathfinding on a decently sized map. The "normal" OOP methodology would be to make each unit an Object of some sort and give it the ability to find a path given some information (like a game board of tiles), or make some helper class that, given a unit and a board, finds the path. Or something like that. After reading (part of) that paper, I instead made the [i]tiles[/i] of the game board Objects and [i]the tiles did the pathfinding,[/i] and the overall interface and design was greatly simplified after doing that.

Anyway, I just want to point out that when considering how do design your objects and relationships, sometimes the "better" solutions require you to think outside the box, where an Object (and its role) isn't the obvious.
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0