Jump to content
  • Advertisement
Sign in to follow this  
JavaProgrammer7

Java Game Design

This topic is 4084 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

Hello, I am trying to learn how to design games before I code them as past experience has lead to a very simple game taking too long to complete. I am trying to draw up a set of Use cases for my next game (a tetris clone) but I having trouble defining the actors. I have read many examples in books such as modelling a bank which would have obvious actors such as cashier, manager, customer, supervisor, employee etc. For this game, I can only think of one actor which is Player. Would a class that extends Thread be an actor (i.e for moving the current block down the screen). Is UML sufficient enough to model a game design? Whats the best methodology to use for designing a game? Waterfall? Extreme Programming or something else. Thanks

Share this post


Link to post
Share on other sites
Advertisement
I find that object oriented design is nice, when used sensibly. Don't go overboard and try to have a perfectly OO system, because it can be more difficult. At least that's my very humble opinion.

What I usually do, is I have one main class, usually built off a JFrame/JApplet, that does things like create the window, handle events, and has the update/render game loop in it.

Each general grouping of game objects I make a new class for, like I'd have a Ship class, an Asteroid class, and a Missile class, if I was doing an Asteroids clone. Each one of these is going to have render/update functions, that will be called each frame from the main game loop. They might also have special event handling code that will be called from the main program event handler. Then they would have any other code that would be important for their interaction with another object, like the ship would have a function called fire_missile(), or explode(), and the asteroids would have ones like spawn_two_smaller_ones(), stuff like that.

Share this post


Link to post
Share on other sites
Personally, I find the implementation of design patterns to be useful in game design/programming. I think you should look into design patterns and it may help with overall game design. This is just my opinion as I used my knowledge of design patterns to write Pacman in MFC (which is no easy task).

Prior to any design patterns knowledge, I also wrote Tetris in MFC but it didn't go very smoothly and the final outcome was less than stellar.

Share this post


Link to post
Share on other sites
I'd say you should just finish the game by all means necessary, instead of thinking up some kind of design. Thinking about designs to much can lead to a trap which prevents you from completing something because your design isn't right or your code doesn't follow the design enough etc... Believe me that can happen, and you can be stuck in it for many years. Also if you skip the design process and just try to finish the game you will learn alot of things along the way, that will make it alot easier to design your code in the future. I don't recommend you start designing before you got some heavy-ass coding experience...

I suuggest you finish that tetris game and then design it.

Share this post


Link to post
Share on other sites
it's sorta common for beginners to over personify the class concept. while seeing them as actors can be useful at first, that context can be somewhat limiting. it is also useful to also think of them as simply data structures who can provide service functions. in my opinion, design patterns are great to read, but really just serve to get the ball rolling...as you start nitpicking your personal way of crafting the bits of your game a mold of your own should emerge.

[Edited by - auric on April 20, 2007 12:38:54 PM]

Share this post


Link to post
Share on other sites
Best? O__O

I got nothing... But what I do is similar to the whole actors business...

For any game, I may think about all the things I need and them push them around accordingly... for example, you will need an input controller. Pretty much every game needs one of these. Build one, get it out of the way. Make it perfect if you want. But it's a utility class of sorts. Not part of the main game, but can be a nice plug in to the game. Make a bunch of these... the useless ones will fall by the way side, and the usefull ones will be used again and again.

Then you do have your "actors"... well, you got a piece which rotates and moves. Which is affected by "gravity" and constrained by the "drop well". Then you got a mish mash of shapes that collect at the bottom of the well, the "junk pile", who has a job of figuring out when to eliminate lines and get pieces added to it. Things add to the score actor... a next piece actor... a sound and music actor that can be called on in the event that something happens...

With games, I find that every "actor" needs a draw method... even if it's a debug type of thing. The FPS counter comes to mind.



Then again, I just call my actors classes, and I'm off to the races...

Share this post


Link to post
Share on other sites
Quote:
Original post by ggp83
I'd say you should just finish the game by all means necessary, instead of thinking up some kind of design. Thinking about designs to much can lead to a trap which prevents you from completing something because your design isn't right or your code doesn't follow the design enough etc... Believe me that can happen, and you can be stuck in it for many years. Also if you skip the design process and just try to finish the game you will learn alot of things along the way, that will make it alot easier to design your code in the future. I don't recommend you start designing before you got some heavy-ass coding experience...

I suuggest you finish that tetris game and then design it.


I agree with most of this. I would start out throwing the game together. This is usually a pretty fun process. Then, as you get to a functioning point (IE background displayed, sprites working, player input working, etc.), refactor and clean up the code. Again, this is an exciting phase, as you see it start to come together. Focus on naming convensions and consistent naming across classes/functions.

I've recently had trouble starting projects because I get bogged down in creating the perfect design. It will almost never happen, the design should be an ongoing process.

I've also recently had to do a lot of restructing of some old code I wrote. This was much easier to get into. I started out improving areas of the code; But, I never got bogged down in redesigning the entire program. I've made a lot of progress, enjoyed doing it, and feel good about what I've ended up with. And, an improvement usually inspires the next improvment. I've taken the approach that I am going to upgrade the program in small steps, rather than in one big swoop. Which, ironically, is how I created the program in the first place. I started out creating a proof of concept, and added to that, as needed.

There's also stuff you won't know in the beginning. For example, what return value will you use for a function? Initially I used DWORD values defined in #define statements. This seemed a good choice at the time, but in debugging all I got was a return value of 7. I had to go find the #define statements and look up 7. But, when I change the return value to an enum, Visual Studio actually displays the name of the enum. This saves me a step in debugging, and isn't any worse than a DWORD return value.

[Edited by - cdoty on April 20, 2007 11:51:04 AM]

Share this post


Link to post
Share on other sites
I think you're going to have difficulty applying the method of use cases to games. Really, there is only one use case: The gamer sits at his computer and plays the game. What you should perhaps borrow from this method is instead writing the story of what the gamer does. He double-clicks your icon, and gets a start menu, with maybe some music. He clicks on "start game" (well, for Tetris you may want to skip this step) and enters level 1. He moves blocks back and forth. And so on.

The objects inside your game are not actors in the sense that use cases speak of, so don't try to apply what you've learned about use cases to them. What you should do instead is figure out what objects you need. For Tetris, basically, you only need blocks. Reading keyboard input, displaying the game board, music, high scores - all this is just scaffolding; the entire game logic is contained in those blocks. So you should start with the blocks, and figure out what sort of scaffolding you need. The most basic would be a display and a keyboard input.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!