First Java Game: Ideas & Tips

Question

I started learning java last week. ( I took one C class last year.)

Now I need to create/code a simple game. Here are the directions, followed by my questions:

---

You get to decide what kind of role-playing game you wish to have. It must either be a top-down view game, or a side-scroller game. The player is to do something: kill things, find things, avoid things, etc. Whatever it is requires that things are to move. The problem is that you don't know how to do this using Java. For now, we will use a text-based game. You must use characters to represent the different things that are moving. Since it is character-based, you have character positions and lines. You can think of each possible character position as a pixel. You can decide how big your "screen" is by defining how many character rows and columns there are to be. Then you write that many characters per line and that many lines each "turn" of the game. A player should be able to pause the game, stop the game and start a new game, or just exit the game. All of this, including playing the game will require keyboard input. You won't be able to use the mouse, yet.

Statistics: You must keep track of something - players hit points, money acquired, things acquired, experience acquired, etc. This doesn't have to affect how the game gets played, at least not yet.

Some Object-Oriented Requirements You are to have at least 5 classes in this assignment: Player, Game, Application, a class for things that move, and a class for things that don't move. You may want to have other classes, or use inheritance. Having 3 subclasses of a single superclass does not count as 4 classes. That is one class.

The Game class is to contain the rules for playing your game. It is to manage the game while in progress. Your application class is responsible for getting everything started. You may want to prompt the player for their name, etc., then start the game. Prior player data is to be read from a file. When a player is finished playing, you are to save their current data, along with any other prior player data, to a file.

---

---

1) I haven't played a game like this in many years. (it was probably something like pacman at age 7.) What do you recommend I try to implement? What would be doable/easy and teach me?

2) Any tips/things I should know or consider before getting to work? Any advice?

Answer 1

This is so simple that learning is the essence. Hence just go ahead and do things and learn from them. StackOverflow is for actual programming problems, so when you have an actual programming problem with code, feel free to ask.

Answer 2

I'd say go for pacman: it's rather easy to implement and will tech you the same Java concepts as any other kind of game (the difference is that more complicated game will require you to use more complicated algorithms to do stuff, but if your main goal is to learn the Java language that is not your primary objective).

The only thing I would suggest you is to go with an Object Oriented mentality from the start. If you only have programmed in C the major difficulty you'll encounter will be switching from the procedural way. So try to use classes, interfaces, inheritance, polymorphism, maybe throw in there some dynamic behavior using reflection... That is to say if you want to learn the Java language you should experiments with the Java way of programming.

Answer 3

Game development in java is very simple. Your game definition is somewhat detailed, that's a good start. You might want to check-out David Brackeen's book, it's quite in-depth.

Answer 4

I would recommend to read a book in parallel. So a book which teaches you how to make a good game code structure and teaches you something about object oriented development.

Answer 5

The instructions are a bit miss-leading. The whole first paragraph is something I would ignore to start with. This is because it's talking about the user interface, which is something that is not as important as the engine behind it. In reality all the UI will be is a display of the current state of your game engine and a way to collect input for the next set of actions the engine is to perform. Hence why I say ignore it to start with.

Next I'd get out an old fashioned piece of paper and with a Java programming guide book, start to sketch out ideas for the basic classes you will need and the possible data items and functions (methods) each will have. This is not a final design and doesn't have to be complicated. Just read up on designing and writing classes and sketch out what you think you need, keeping it as simple as possible. It might take a few rounds to help clarify it in your head. Some basic things to look into first are interfaces vs concrete classes, and java api collection classes. Remember, keep it simple and keep one basic principle in mind - each class should do only one thing. I.e. a Creature class should only contain information and functionality in relation to a creature, a score class should only store and manage the players score etc.

Once you have a paper outline that works for you (remember it only needs to be a basic starting point), then pull out the IDE and code the classes. You will find as you do this that you will change the design, add more methods and data, etc. That's ok, it's a natural part of the process. When this starts happening and you are reshaping things, look up "re-factoring".

Once you have some very basic code in place, look up "Unit testing". This gives you the ability to run some test on your code to test out the functionality. You can also test out error situations and setup various scenarios for your game engine to play with. Notice at this point we still have not discussed the UI. This is because it's possible to develop and test your complete game engine without any interface at all. Unit testing is designed for expressly this purpose. It lets you concentrate on the engine rather than be distracted by the UI.

By now you will have a good idea of where you are going and can make the decisions about the style of UI you want. Because you now have a working engine, designing and writing a UI will be vastly simpler to do.

Answer 6

OK, there are actually 3 important parts:

1. The Game Design, it's better to draw everything out on paper before starting to code ANYTHING, because this way you'll spend way less time on refactoring your code because you didn't think of X or Y beforehand.

2. The Engine, this will take a lot of coding in the beginning, since all the FPS limiting stuff etc. is not as easy as it looks, hell even taking keyboard input CAN give one a lot of problems when there's no way to toggle autorepeat off, talking about crossplatform? Forget it, at least under Linux it sucks.

3. Actual layout of the code, don't go all the way to make everything inherit from one giant base class. It's better to have multiple base classes with distinct functionality, there might be even thing where you don't want to go with a class based approach at all, like effect, a ManagerInstance which handles all the effects at the same time would be way easier, it would just have methods to create different types of effects and then handle them in one big "loop".

As how to get started, I've got some basic engine code lying around over at my GitHubs, you may wanna check it out as it can give you some insight on how much engine code you'll have to write:
http://github.com/BonsaiDen/Bonsai-Game-Library