A good way of programming?

  • Thread starter Thread starter Hans Kamp
  • Start date Start date
H

Hans Kamp

I am programming an easy game (not with a commercial purpose, just with
learning purpose), but I doubt whether the following way of programming is
proper or advisable.

The main form (BugEaterForm) that has a module, has the following objects:
- Snake, for drawing and being controlled;
- Player, with player information, such as name, score, number of lives;
- PlayField, containing the matrix on which you are playing;
- BugEaterForm.

But I think I don't have a neat way of realizing the communication with each
other.

For example, if the snake must be moved, or it eats a candy or it is dying.
The trick is passing the classes as a parameter in the constructor of the
other class.

For example:

currentplayer = new Player(gnf, playPanel, timeleftPanel, playField,
timerSnake, timerBonus, "Hans Kamp", scoreLabel, livesLabel);

all this stuff must be passed, because the player and objects that are
dependent of the player must have the ability to do something with the
controls and other variables in the above constructor.

The constructor Player is defined as:

public Player(GetNameForm gnf, Panel pp, Panel tlp, PlayField pf, Timer s,
Timer b, string playerName, Label sl, Label ll)
{
...
playerSnake = new Snake(pp, pf, this, s, b);
...
}

The constructor Snake has 5 parameters. It is defined as:

public Snake(Panel playP, PlayField pf, Player p, Timer s, Timer b)
{
...
playfield.setCell(panel, snakeHead.X, snakeHead.Y, Field.SnakeHead);
}

And setCell needs access to the object PlayField (by playfield) so that the
snake can be drawn initially. But the snake has to do several things, for
example:

- repositioning. It needs access to PlayField;
- completing a level. It needs access to timers on the main Form (stopping
and starting a timer), access to a player (adding bonus to the score,
incrementing the live and level with one, and setting the bonus points to
4000), access to the playfield (redrawing the field);
- removing the snake. It needs access to playField;
- dying. It needs access to the timers, to the player, to playField;
- moving. It needs access to the playField;
- processing keys (being controlled by the user).

The player has the following tasks:
- drawing the time left bar. It needs access to the timeLeftPanel;
- displaying the number of lives. It needs access to the livesLabel of the
form;
- displaying the score. It needs access to the scoreLabel of the form.

The playField has the following tasks:
- drawing a cell (it needs access to the playPanel);
- setting a cell;
- getting a cell;
- redrawing a new level play field (it needs access to the playPanel);
- drawing walls (access to the panel);
- drawing candies (access to the pane).

For the whole source code (related to the above text), see

www.hanskamp.com/csharp/WinForm.cs

What do you think? What is the best way of organizing the communication
between the objects?

Hans Kamp.
 
Hans, Game Engine design is a big topic, but let me offer up a few things.
(BTW, I wasn't offering commercial services in my previous post. Games4 and
BrainFreeze are both going to be community companies and not a massive money
making machines.)

First, modularize everything so that it is independent of the other pieces.
What do I mean by this? Well first off, create the game so that it can play
by itself without showing off any graphics. This generally means creating
an object that can be set-up to play the game using different parameters,
providing methods to step forward through each tick of the game (every game
has a logical timeslice), and finally some end state variable that lets
callers of the engine know when it is complete.

With the *engine* done you need to abstract the process of input. Generally
you can use a Queue of action objects. In your game runner (the engine
host), whether it be WinForms, console, web page, whatever, you can then map
user input to these generic actions and then put them into the games queue.
This has an added benefit. Your game also achieves a natural AI interface
(an interface through which AI can provide typed input to the game in order
to play). Each AI player can simply use the same interfaces as a real
player. You also gain the ability to easily take network messages right off
the sockets and plop them down into the engine for remote play.

The last process is going to be deciding what data is available. This is
important, you'll need to relese enough data for the graphics engine to
actually render itself. Sometimes the graphics engine is completely
separate and sometimes it is heavily integrated with the game engine host
since it will be responsible for providing input UI. Between calls to
Advance() or NextTick() or whatever you called the game engine advancedment
method, you can render your scene by getting the state of the engine.

By modularizing in this fasion you can work on little pieces of your game.
In the end you can actually upgrade only the portions that you want to. If
you are slick with the way modules work together you can even interface the
entire thing and do dynamic binding in a config file so you can swap modules
out. The best place for this is AI so that users can change the AI classes
they are playing against.
 
<shamelessPlug>

Talking of games in C#, I'm working on a clone of the old BBC Micro game,
Repton 3 which has been cleverly renamed as Repton.NET. Took me hours to
think of that title! ;) For those who don't remember the BBC Micro, Repton
was a Boulderdash variant.

Anyway, details of the project are at
http://www.edcourtenay.co.uk/CategoryView.aspx?category=Repton.NET, and the
GotDotNet workspace is at
http://www.gotdotnet.com/Community/Workspaces/Workspace.aspx?id=908ed5a1-e09e-414b-92fb-df17a36fd0a0.
I'd love to have other developers involved in the project.

</shamelessPlug>
 
Dont forget Hungry Horrice or Horrice goes Skiing on the C64 :D I got all
those originals. MasterTronic then codemasters where the biz leaders then,
and Epic with its Summer Games and Games collection. Just do not redo those
Joystick wigglers like Daily Thompsons Declathlon. God no please. No more.
 
Mr.Tickle said:
Dont forget Hungry Horrice or Horrice goes Skiing on the C64 :D I got all
those originals. MasterTronic then codemasters where the biz leaders then,
and Epic with its Summer Games and Games collection. Just do not redo those
Joystick wigglers like Daily Thompsons Declathlon. God no please. No more.
Click to expand...

Ahh yes, the Horace games - classics! I wasn't aware they'd ever made it to
the C64; IIRC, they were all originally written for the Spectrum by
Psion/Melbourne House.
 
Ed Courtenay said:
<shamelessPlug>

Talking of games in C#, I'm working on a clone of the old BBC Micro game,
Repton 3 which has been cleverly renamed as Repton.NET. Took me hours to
think of that title! ;) For those who don't remember the BBC Micro, Repton
was a Boulderdash variant.

Anyway, details of the project are at
http://www.edcourtenay.co.uk/CategoryView.aspx?category=Repton.NET, and the
GotDotNet workspace is at
http://www.gotdotnet.com/Community/Workspaces/Workspace.aspx?id=908ed5a1-e09e-414b-92fb-df17a36fd0a0.
I'd love to have other developers involved in the project.

</shamelessPlug>
Click to expand...

Quite interesting (BTW, I don't know why your message would be so
shameless). Also interesting is the use of DirectX and full screen.

My system meets the requirements that you mentioned on your website, before
being able to play the game.

I didn't succeed to have access to
http://www.gotdotnet.com/Community/Workspaces/Workspace.aspx?id=908ed5a1-e09e-414b-92fb-df17a36fd0a0.

Hans Kamp.
 
Back
Top