For Cocoa Game developers

Moderator
Posts: 508
Joined: 2002.09
Post: #1

"When you dream, there are no rules..."
Quote this message in a reply
Member
Posts: 283
Joined: 2006.05
Post: #2
Thanks... that inspired me to start work on this:

[Image: CCSS.jpg]

I'm getting a bit stuck with all these classes and so on, but I'll persevere.
Quote this message in a reply
Member
Posts: 257
Joined: 2004.06
Post: #3
Looks purty. What is that? Shogi?

The brains and fingers behind Malarkey Software (plus caretaker of the world's two brattiest felines).
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #4
Not Shogi (it has a 9x9 board, no colors, pieces that indicate direction, etc.) I'm guessing it's some kind of Chinese equivalent, but I'm interested too Smile
Quote this message in a reply
Moderator
Posts: 3,571
Joined: 2003.06
Post: #5
Yeah, that looks pretty interesting Maximile, what is it?
Quote this message in a reply
Member
Posts: 283
Joined: 2006.05
Post: #6
It's Xiangqi, or Chinese Chess. I couldn't find a good Mac version, so I thought I'd have a go at making one. It's really a very cool board game.

Now I just have to make all of those pieces do the right things. I'm pretty new to OO programming, but eager to learn, so I thought it would be a good idea to have one class for "piece", which contains all the drawing code and a few simple rules, and then a class that inherits from it for each type of piece which contains all the code about legal moves. Does that sound like a reasonable way to go about it?
Quote this message in a reply
Moderator
Posts: 3,571
Joined: 2003.06
Post: #7
maximile Wrote:Does that sound like a reasonable way to go about it?
No.

Graphics and game logic should be kept completely separate, broadly speaking. The graphics should follow the logic, not be integrated with it.

Take modern chess games for example -- which seem closely related to your game. There are many chess `engines' out there which consist mostly (if not entirely) of logic and some simple input and output mechanisms with virtually no graphic representation; mostly to be operated from the command line. Then, OTOH, you have graphical game engines which can launch those engines as a separate sub-process (so to speak) and interact with them to know where to place the pieces on screen. The chess engines can be run completely from the command line, but the visual chess games can't do anything but look pretty all by themselves. They have to work together to make a conventional end product. Take Big Bang Chess for example: It's a great game all on its own, and looks super-duper impressive and smart and everything, but all it's really doing is presenting a face for gnuchess underneath, which is freely available and actually does all the heavy lifting (no offense to the Big Bang Chess programmers ;-) ).
Quote this message in a reply
Member
Posts: 90
Joined: 2006.11
Post: #8
AnotherJake Wrote:No.

Graphics and game logic should be kept completely separate, broadly speaking. The graphics should follow the logic, not be integrated with it.

This apply even if I make other types of games? :s All the programs I have made so far ties graphics && logic together. (eg... drawing code in a method of classes...)

How do you seperate them? You have a function that fetches all the data in your objects and draw them seperately? But that'd slow it down a little... Because when I draw the code, it also process the game logic simultaneously. If I seperate them like that then it would take more loops....
:S

Very nice chess game there! (I am a Xiangqi player myself... Smile)
Quote this message in a reply
Moderator
Posts: 3,571
Joined: 2003.06
Post: #9
leRiCl Wrote:This apply even if I make other types of games?
It should, yes. Logic and drawing are very common to keep separated. The most common logical way to do this is to have an `update' method and a `draw' method. Every visible object will have geometry data which is affected by the logic in some way, and drawn in another. The object's update method does not care at all about how the object is drawn, it simply determines where it's at and where it's supposed to be, etc. Whereas the draw method does not care at all about where the object is or what it's doing, only what it's drawing parameters are, such as rotation, scale, geometry, etc. The two need not have anything to do with each other. In fact, the draw method could/should be centralized and generic so-as to handle drawing of all objects of a particular type. IOW, drawing code need not even be contained within the objects themselves, but rather all by itself, off in some other remote module, perhaps even another program entirely!
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #10
Yes, this is absolutely the number one rule to follow to get your game design working out nicely. It's basically just the game version of the MVC (model-view-controller) OO design pattern.
Quote this message in a reply
Moderator
Posts: 1,560
Joined: 2003.10
Post: #11
While having a 'draw' method as part of the same class as the logic has its limitations, in practice, it's worked perfectly for me in any reasonably simple game. If you're not doing something that actively necessitates separation, it may well be wasted effort to try to do it. Call me unprofessional or a bad coder or whatever all you like, but I'm speaking from practical, real-world experience.
Quote this message in a reply
Moderator
Posts: 3,571
Joined: 2003.06
Post: #12
Well, a game is just like any other program in that respect -- you can do it however you like! Hehe, it's not like MVC is a religious edict handed down by the programming gods or something. Doing it that way doesn't scale well though, and can present problems later on.

Here are some example situations to add to the discussion:

- What if you wanted to multi-thread your application? The logic (the controller) and the drawing code (the view) could easily share the objects' data (the model) and be threaded without much issue.

- Then, as another example, what about if you wanted to draw all your objects using a new shader? If all the drawing code is in one place and generic then it'd be a simple five minute matter of updating just that code and testing it. If all your drawing code is wrapped up in each individual class, that could take many hours, if not days to do.

- What if you wanted to use some special feature that only works on newer machines but would like to retain the older method for older machines? Here it would be nice to just add a single conditional branch in the centralized code base to add the feature, rather than in every single class.

- What if you wanted to port your game to another platform that uses a different graphics API, such as, oh I don't know, DirectX... Again, central drawing code base, relatively easy change (hopefully).

- What happens if your current graphics API changes and breaks your game? Again, if it's all generic, centralized drawing code then it would likely be easier to change a few lines rather than hundreds, if not thousands of individualized lines.

And the biggest advantage to centralized drawing: Write less code!

Again, this is all not to say that you'd be a bad programmer if you didn't do it this way, but there are many advantages to it. Smile
Quote this message in a reply
Moderator
Posts: 1,560
Joined: 2003.10
Post: #13
What if you don't need to do any of that for the game you're writing?

Again, I fully understand the benefits of that approach, but when they're not actually applicable, I don't see the point. This is probably just my minimalist approach to coding talking, but I generally try not to design for "what-ifs". The scope of a project obviously has everything to do with this... There really isn't a one-size-fits-all solution. You can always try to make a solution that would be appropriate for a large-scale game project fit a much simpler one, but in my experience, that usually results in wasted effort... that is, unless you happen to already have the code written from another project, and can simply copy and paste and make a few tweaks.
Quote this message in a reply
Moderator
Posts: 3,571
Joined: 2003.06
Post: #14
It's not a matter of not `needing' to do it.

Not to be a contrarian, but I'm not sure you understand the approach I am describing. MVC *is* minimalist, and not overkill. It *is* actually a one-size-fits-all approach. If I were to design a small (tiny even) sprite game, I would make classes for each type of avatar which would only change their respective data, but not draw. I would then make one single class to draw them all using the data that the avatar classes had managed. That class would be all of about fifty lines. That's minimalist! It's easy! Being as how I've done it both ways (yours and mine), I have come to learn that MVC is *far* easier than distributing drawing code in each class. Admittedly, it might take a bit to wrap one's mind around, but it's well worth the effort Smile
Quote this message in a reply
Sage
Posts: 1,403
Joined: 2005.07
Post: #15
AnotherJake Wrote:It *is* actually a one-size-fits-all approach.

I am really skeptical that any single design pattern could "fit all".

Sir, e^iπ + 1 = 0, hence God exists; reply!
Quote this message in a reply
Post Reply