C++ Snake Game – Change Coordinates or Spawn New Object for Fruit?

cgame development

I've decided to lean SDL and make a Snake game. I have gotten to coding the spawning of a fruit, which the snake eats to get longer. Every time the snake eats the fruit, the fruit needs to change to a random position on the screen. I can either simply change its coordinates to new random ones, or I can trash the old fruit object (that has been eaten by the snake) and make it point to a new object with new coordinates. Which one is more efficient? Here is some pseudo-code, for reference:

Option 1:

if (snake_eats_fruit) fruit->changeCoordinates();

Option 2:

if (snake_eats_fruit) fruit = new Fruit(); // fruit's constructor sets random coordinates

So should I keep the same object and change its coordinates, or make a pointer to a new object with different coordinates? Thanks!

Best Answer

The first option is probably faster. With the second one you have, at least, the additional memory allocation task.

Anyway this is a good example of premature optimization: performance shouldn't be a concern for this kind of operation.

The snake eats a fruit just occasionally. Between two meals there are a lot of other (complex) events that take place and the action of changing the position of fruit is negligible.

Some aspects you should consider are:

do I need explicit memory allocation? (new Fruit()).

It can be the source of memory/resource leaks and it can be slower (e.g. Why should C++ programmers minimize use of 'new'?).

If you really need dynamic allocation use a smart pointer

with the second option can easily create a dangling pointer

Fruit *fruit = new Fruit();
Fruit *fruit2 = fruit;

// Snake eats fruit.
delete fruit;
fruit = new Fruit();

// now fruit2 points to something which is not valid anymore

Related Solutions

C++ – Is This Observer Pattern Variant an Improvement?

Your idea was already invented 10 years ago by Herb Sutter. See this article: http://www.drdobbs.com/cpp/generalizing-observer/184403873, it contains a full explanation.

So the answer is

yes, it is an improvement over the original GOF variant of the pattern
no, it is not better than every other known implementation of the Observer pattern

Also note that what you suggested here is the "standard observer implementation" in functional languages or languages with functional elements where events/event sinks are typically implemented in a comparable way (for example, in C# using delegates).

C++ Object-Oriented Design – Separate Classes for Building and Using an Object

What you consider FooBuilder and Foo is actually part of a well-established Builder pattern. The other approach you mention with creating a Foo instance based on an existing instance is called a Prototype pattern. Both of these are well-known object creation alternatives and several books (most notably "Design Patterns", aka GoF) have been written describing them. (not sure I'm clear on your second mutable example, so comparing #1 to #3 here)

Each pattern obviously has its own advantages and drawbacks and only you can decide which one is better for your specific situation. For example, I would typically use builders when there's a lot of different ways of initializing Foo. For example, right now I'm working on a query builder class and many clients use it differently to build query objects. Different clients want different fields to be returned, some clients want only last 10 rows, some want sorting while others don't. Builder is perfect as it can look something like this:

qb = QueryBuilder()
query = qb.fields("name", "address")
          .sort("zip", "asc")
          .limit(10)
          .build()

So multiple setters, each returning instance of the builder itself so you can daisy-chain basically serve as a very flexible constructor. Making one class a friend of another class has it's time and a place and potentially this could be one of those places.

Alternatively, you could define Foo as having one constructor that takes a rather complex set of params, or potentially you could define another class FooData, that FooBuilder could initialize and pass into Foo creation. Then again, maybe Foo and FooBuilder being friends in this case isn't such a bad thing. Just keep in mind that when one class is a friend of another one, you are expanding encapsulation boundary, which could be just as bad as putting more and more code all within one class (i.e. more code knows about internals)

At the end of the day, you could be thinking and considering all these different options and it will all boil down to 60/40. If there's no clear winner, you can always let a coin pick the winner and just go with it. Most likely either one of the design choices would work just fine and by going through the motions and seeing your code in action you will learn valuable lesson for future. Sometimes when I have design decisions and can't decide between A and B, I could end up picking B and then if I ever come across a similar situation I would intentionally pick the other choice. The work in either case gets done and I get the software to do what I want, but you get a ton of benefit of actually seeing your decisions in action and being able to compare the two working approaches, rather than just discussing and thinking about them.

Best Answer

Related Solutions

C++ – Is This Observer Pattern Variant an Improvement?

C++ Object-Oriented Design – Separate Classes for Building and Using an Object

Related Topic