Sign in to follow this  

Idea Organization

This topic is 4337 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hey everybody, This is really a topic directed at developers that have completed many games and have a good amount of development experience under their belt. Here goes. I've recently decided to start writing games again and I've gotten myself re-aquainted with SDL and C++. I've tried breaking this game into small pieces and working on them seperately but no matter how far I break it down, I always make it more complicated. The general idea is a 4-player online top-down shooter. I know the complexity involved with this project, and this is what upsets me. I know how to implement each part, but bringing online play and top down shooter can get tedious. It's completely necessary to break this down for it is a big project. Just to give you an example of how I've been organizing it... Breakdown Tile Engine Player->Weapon->Projectile Networking I know this is broad, and I think that's my problem. I'm really looking for advice on the "before work" that HAS to be done before a game. Help =P EDIT 1: I'm not really looking for a reference to a design document. Looking for more of a conceptual organization of thought. toXic

Share this post


Link to post
Share on other sites
I'd recommend you think about the key data that your game manipulates - not models or textures, but player positions, states, health, stuff like that. Which machines in the system will be responsible for handling what kind of information, which machines in the system need to know which bits of information, and how is the data going to be transferred between the machines?

Stuff like tile engines are actually relatively tangential - they're as key to the game as visualizations are to playing music in Windows Media Player. The important thing is the underlying model.

On a related note, have you looked into much middleware? A package like RakNet might make your task a lot easier as it handles all the object synchronisation across the machines on the network.

Share this post


Link to post
Share on other sites
Glad to hear you mention RakNet because that was actually what I was planning on using.

Are there any specific techniques or structure you use to start to plan out how the machines within the game will work together, or basically how they will work?

I noticed last night that if I actually got the conceptual design of a class out on paper, it was a lot easier to write the actual code that way than if I just had the concepts in my head and wrote from there directly into the source.

Thanks for the advice thus far.

Share this post


Link to post
Share on other sites
Class diagrams and suchlike can certainly help. I'd also recommend reading up on design patterns: Gamma et al, "Design Patterns: Elements of Reusable Object-Oriented Software" and the Wiley series on software design patterns are books I've found particularly useful (I'm working my way through the Wiley "Patterns for Concurrent and Networked Objects" by Schmidt et al at the moment). They should give you some ideas for parts of your app.

One thing I cannot stress enough is establishing clear requirements from your software. "Four-player online top-down shooter" is better than many people start with, but you need to establish your target machine spec, support for things like game controllers, collision/physics requirements, and sound requirements, to name a few.

Share this post


Link to post
Share on other sites
I'll definately check those out.

I'm beginning to learn the importance of planning and replanning for actually starting to develop the source. I've written countless "mini" games on the fly and I always end up with a messy, half-done bundle of code.

Clearly defining and deciding how different parts of the game should act and react to the user are my top priority for this next game. I'm really trying to get in the habit of producing solid, reworkable code.

On a *slightly* off-topic note; I've been thinking of the network portion of this game and I have come up with a few ways I could do what I need to do. I'm just unsure as to which is the best.

I was wondering what would be the best way to get data to and from the server. Would I make a machine that would gather all the information that I want the server to do calculations on and manipulate, and also send one big packet out... Or would I give each object in my system (player, projectile, etc) the ability to send it's own information in many smaller packets out to the server and have the server redistribute it accordingly...

Just thinking to myself, I believe sending one big packet out would be more efficient, but my experience in network game programming is limited.

Share this post


Link to post
Share on other sites
Quote:
Original post by toXic1337
I'm beginning to learn the importance of planning and replanning for actually starting to develop the source. I've written countless "mini" games on the fly and I always end up with a messy, half-done bundle of code.
In which case you may also want to look into the practice of "Refactoring," which is changing the structure of code to be cleaner without changing its behaviour. Having a messy, half-done bundle of code is fine if you then proceed to convert it into a clean, half-done bundle of code, and then make it a clean, fully-done bundle of code [smile]

Quote:
On a *slightly* off-topic note; I've been thinking of the network portion of this game and I have come up with a few ways I could do what I need to do. I'm just unsure as to which is the best.

I was wondering what would be the best way to get data to and from the server. Would I make a machine that would gather all the information that I want the server to do calculations on and manipulate, and also send one big packet out... Or would I give each object in my system (player, projectile, etc) the ability to send it's own information in many smaller packets out to the server and have the server redistribute it accordingly...

Just thinking to myself, I believe sending one big packet out would be more efficient, but my experience in network game programming is limited.


Given X groups of N bytes of data, it's more efficient in terms of bandwidth to send one X*N-byte packet than to send X N-byte packets, because each packet gets some bytes added to it (the packet header).

However, that doesn't mean you have to go with the former option. You could easily take a bunch of small packets and "pack" them into a single large one, maybe with things like compression applied.

What you might be lacking is knowledge of a "message-passing architecture." It's a fairly simple premise. A message is a recipient ID, message ID, and hunk of data. A dispatch or mailman is a system that maintains a list of available recipients and the 'RecieveMessage' method on each one, such that when you give the dispatch a message, it can pass it to the correct recipient's RecieveMessage method.

Share this post


Link to post
Share on other sites

This topic is 4337 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

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