Jump to content

  • Log In with Google      Sign In   
  • Create Account

BLM768

Member Since 30 Aug 2012
Offline Last Active Oct 18 2013 01:09 PM

Posts I've Made

In Topic: Is there a shorter way that does the same thing

16 August 2013 - 07:09 PM

Is it okay to have 26 cases using switch? Or do I just have to live with it?

 

Aside from a lookup table, using a switch statement is probably the most efficient option. The compiler might actually rewrite the switch statement to use a lookup table, but it's not required to. However, using a lookup table would require a lot of boilerplate unless the switch statement is just mapping key codes to character values, which doesn't seem to be the case, so I'd go with the switch statement unless this code became a major bottleneck (which is quite unlikely).

 

Edit:

 

Looks like Álvaro got to it before me.


In Topic: Advice for 2D game structure

10 August 2013 - 01:05 PM

I'm not sure whether you're using OpenGL or DirectX, but in either case, you might be able to take advantage of instancing.

 

Here's a good article on OpenGL instancing:

http://www.gamedev.net/page/resources/_/technical/opengl/opengl-instancing-demystified-r3226


In Topic: OOP Design

10 August 2013 - 12:53 PM

first question would be, do you want to go with an oo type design, or something else like components, modular, etc?

 

you're using c++, so all options are open. 

 

as you seem to be discovering, traditional methods of c++/oo design of games can have issues.

Component-based and object-oriented approaches are not mutually exclusive. A good component-based design is likely to implement object-oriented (or at least object-based) principles, and vice versa.

 

Looking at this game from the component-based perspective, there are two main components: the game world and the screen. The game world has the job of simulation, while the screen (or at least the IngameScreen) has the job of drawing a game world. Since the IngameScreen is responsible for drawing a specific world, make the world a member of the IngameScreen. That way, the IngameScreen has access to everything in the world, and the screen doesn't need its own list of game objects, which would just be duplicating data and wasting memory.

 

If the idea of making the game world a member of the IngameScreen doesn't feel quite right conceptually, you could also pass the world as an argument to IngameScreen's drawing method.


In Topic: Revew my pong clone: game and code!

28 July 2013 - 11:55 PM

This code's not bad for a first project; it's organized reasonably well and is pretty easy to read. As far as structure goes, you'd need only a few tweaks to make it more solid:
 
The functions that manipulate the ball and paddles could be moved into the classes as methods, like so:
 

class Paddle
{
public:
	int x, y;
	int width, height;
	BITMAP *paddleSprite;

	void moveUp() {
		y-=5;
		if(y < 0)
		{
			y = 0;
		}
	}

	void moveDown() { /* ... */ }
	void draw() { /* ... */ }
};

Then instead of calling moveup(paddle1), you would call paddle1.moveUp().
 
You could also take advantage of the similarities between the paddles and the ball. They are both game entities with coordinates, width, height, and an image, so you can pull those similarities into a base class:
 

class Entity
{
	int x, y;
	int width, height;
	BITMAP* sprite;

	void draw()
	{
		blit(sprite, buffer, 0, 0, x, y, width, height);
	}
}

//Has all the fields from Entity plus whatever we add here:
class Paddle: Entity {
	//moveUp(), moveDown, etc.
}

class Star: Entity {
	void rotate() { /* ... */ }

	//etc., etc.
}

I can think of a few more things you might want to tweak, but I'll leave you with that for now because it's getting late, and this post will probably take a little while to "digest" if you're not already familiar with methods and inheritance.


In Topic: Extremely frustrated trying to find the right engine/language/api/whatever

17 July 2013 - 01:17 PM

Can you give an example of Java being quite verbose? I'm curious.

The main example I've found is with I/O; to send an object on a socket, I had to get the socket's output stream object, then create a ByteArrayOutputStream, wrap that in a DataOutputStream, serialize the object to the DataOutputStream, convert the ByteArrayOutputStream to a byte array, and dump the byte array into the socket's output stream. Apparently, this is "proper, idiomatic" Java code. It has a lot of nice conceptual separation, but the separation is too fine-grained and leads to allocation of piles and piles of wrapper objects in some cases.

 

Admittedly, I'm no Java expert, though; someone with more experience might have found a more concise way of doing it.


PARTNERS