Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 04 Nov 2005
Offline Last Active Jan 05 2015 04:02 PM

Posts I've Made

In Topic: the public syndrome

20 January 2014 - 05:58 AM

It makes sense for the monster to check the player’s shield when it attacks, because that’s what the monster is doing in the simulation. It makes sense for the player object to have a shield object, because that’s exactly the situation you intend to represent. You could have a public member function on the player for getting a read-only view of their equipment—then monsters could use those methods to answer questions like “Does the player have a shield, and is it wooden?” but wouldn’t be able to alter that information in unstructured ways.


An interaction like this can be modelled in many ways. It’s up to you to start with something plausible, and alter it when you see the need to. And you can’t really predict the choices you will make in the future, so it doesn’t make sense to write much more than just what gets the job done well in the present and is easy enough to change later.


OOP is a class of architectural philosophies, not a consistent theory with specific or consistent rules, so there is no “right answer” here. You just have to develop a sense of design aesthetics over time. One good way to do that is to have other developers review your code and point out areas for improvement. But I would say correctness by construction is a very strong guideline.

In Topic: the public syndrome

19 January 2014 - 07:28 PM

An object should be correct by construction, and its public API should only produce valid states as well.


If you have a Point class with two public fields X and Y, that’s fine as can be—there are no invalid Points, so there are no invariants to preserve, and the fields can be exposed directly. Whereas if you have a Heroine object with Health and Shield fields, then it does not make sense to expose these directly, because code could place the heroine in an invalid state by killing her even though she has a shield. That’s why people recommend methods like “heroine.takeDamage(monster.strength)”.


The other thing to consider is that if you use immutable objects—that is, treat them as values representing the state of an object, not as the state itself—then as long as objects are correct by construction, they cannot ever be in an invalid state because they will never change after construction. That can make it significantly easier to reason about what your code is doing and ensure its correctness.

In Topic: Game Engine, How do I make one

04 December 2013 - 03:00 AM

My question is what really is a game engine and how do you make one?


A game engine is a system for making games—an application, or more commonly a library, providing services such as audio & video output, controller input, timing, physics, and so on. How do you make one? You don’t. If you want to make a game, you should make a game. You will not accomplish that goal, nor really improve as a software developer, by creating middleware without specific goals and requirements in mind.


Just pick an engine (or less—a basic graphics+audio+input library such as SDL is fine) that’s compatible with your style of thinking and/or your preferred programming language. Use it to make something. If you encounter limitations, take the time to understand and work with them. Working under constraints will help you think more creatively. Keep a diary of these situations and maybe next time try a different engine.


You can learn a lot by making an engine—about systems programming, graphics, audio, input, API design, and infrastructure in general—but it’s best to fight on a single front. Want to make a game? Take advantage of the work that others have done. Interested in engine design? Do it as a learning exercise. And anyway, you can learn all of those skills in other ways, incidentally, in the process of creating useful software.

In Topic: unique_ptr

12 September 2013 - 10:16 PM

unique_ptr owns the object that it points to. move() can be used to transfer that ownership to another unique_ptr. You will find that after your call to move(), vFoo.front() will be a null unique_ptr; ownership of the object has been transferred to p using its move-assignment operator.

In Topic: An enum made of structs

17 April 2013 - 08:07 PM

Why not just declare objects?


// Move.h

extern const Move

// Move.cpp

const Move TACKLE(...);
const Move GROWL(...);
const Move HYPER_BEAM(...);


If you need these in a table (e.g., to refer to them by integer ID), then you can build that separately.