We are three people who are going to make a simple game in Java as a school project (University, first year). The game has to be object oriented. We don't have much time, 10-20 hours tops. None of us has any experience in game development, but we all have fair skills in Java.

We can choose exactly what kind of game, and that is where the problem lies. How high should we aim? There is a competition involved, so we do want to make the best game in the time we have. Is a 3d game unrealistic? Should we use any game-engines/libraries? What kind of functionality should we avoid?

  • 4
    \$\begingroup\$ 3D is aiming a little too high regardless of time, considering you have no gamedev experience. ;P \$\endgroup\$ Mar 29, 2011 at 19:49
  • \$\begingroup\$ sadly, I figured that :P \$\endgroup\$
    – Øyvind
    Mar 29, 2011 at 19:51
  • \$\begingroup\$ PONG! paddles, ball are there own objects, add a score. the ball hits a paddle you times the direction by -1. if the ball goes past the paddle point the other team, have the ball serve to the other player. or is that too easy?> \$\endgroup\$
    – Spooks
    Mar 29, 2011 at 22:30
  • \$\begingroup\$ I think maybe we should aim for a better, more creative concept, though an easy one to develop... \$\endgroup\$
    – Øyvind
    Mar 30, 2011 at 6:41
  • 1
    \$\begingroup\$ How about sharing your game with us? :) \$\endgroup\$
    – ashes999
    Nov 24, 2011 at 2:24

3 Answers 3


Avoid 3D, because you would need to know how to make 3D models or find good ones, you would need to know how to load such models (often an epic task in itself, sadly), and how to draw them on the screen (e.g. OpenGL or DirectX takes a lot of work for little gain, and even an engine like jMonkeyEngine requires knowledge of how to utilize the engine, along with basic 3D knowledge). Blitting 2D images on screen and moving them around is far simpler than dealing with vertices, materials, view matrices, transforms, etc. etc. I think you get the point.

Stick with the built-in Java libraries and classes: Graphics2D, ImageIO, AWT mouse and keyboard listeners, Canvas, Java Sound API, and so on. The benefits of sticking with these instead of finding some other library include: you already know them (to some extent), you know they're well tested and stable and generally make sense, online documentation and resources are abundant, and they are portable so you don't have to worry about installing extra libraries with native libraries and all that.

Build up a little library of code snippets ahead of time. These would include things like loading an image, drawing the image to a position on screen, scaling the image and other effects, playing a sound, looping background music, bounding box collision detection, drawing text. Also have a skeleton application which opens a Frame (or Applet), adds a Canvas to it, and the canvas's paint and repaint methods should be overridden, and a thread should be looping the canvas repaint method (or a timer calling it). You can learn these things if you search around for Java 2D game programming. Assuming you have access to your university's library, you should have a number of good Java game books at your disposal; check them out and skim through them for the above-mentioned snippets, and others I missed.

Practice source control and division of work with your team ahead of time. Are you going to use Subversion, Git, Mercurial, or something else? Are everyone's computers set to the same up-to-date version of Java? Create your repository, commit/push some files, make sure everyone has the repository checked out and ready to go on your system. Maybe commit a 'hello world' app and make sure everyone is able to pull and modify and commit it; and make sure you know how to handle merging (whether you avoid it entirely with good communication or pair programming, or you know how to use a merge tool). Or, if you aren't familiar with source control, make sure you figure out a solution that works; whether it's pair programming while the third person does art or sounds, or something else, just make sure to be organized from the start or you'll waste tons of time.

Bookmark links to websites which provide free media. There have been quite a number of these type sites listed in other questions here; sites like freesound are perfect for quickly finding useful media to use in your game when you don't have the time to make it from scratch. Bookmark this site of course, so you can ask a question if you get stuck on something. Bookmark forums such as the gamedev.net forums so that you can search them for answers. If you opt to use a third-party library, bookmark their website. Organize these bookmarks into folders and grab as many as possible, and make sure to share them so that all three of you have the same useful library of bookmarks. It doesn't take a lot of time to go around and collect these bookmarks and organize them by type/subject, but it saves you a lot of time when you don't have to remember all those websites in the middle of your project.

For more suggestions, see the answers to my question "How to prepare for a game development competition?".

To address the rest of your question... The general advice is: don't aim high. However, it can vary widely depending on how prepared you are (i.e. my above suggestions) and your skills in Java. This is largely a personal judgement based on your history, but since none of you have history of making games (and therefore can't judge the time necessary), aim really really low. Come up with a really basic idea which can be easily implemented in 2D without any advanced concepts (e.g. avoid pixelwise collisions, crazy physics calculations, particle effects, etc.). But then create a prioritized list of the features of the game, in as much detail as possible (e.g. break each feature into as many separate tasks as possible). This way, you simply work your way down the list as far as possible, and if you don't get to some low-priority tasks, it shouldn't be a big deal. This has to be done carefully (you still need a functional game at the end of the time, so there is a minimum set of tasks which need to be done and some tasks depend on other tasks), but in general I think this is the best approach when you don't know how long things will take.

  • \$\begingroup\$ That's excellent advice. \$\endgroup\$ Mar 29, 2011 at 21:55
  • 1
    \$\begingroup\$ Good points. Although I think source-control can also make things more complicated for beginners (imagine somebody messes up the repo). When time is critical, one shouldn't start to use new tools. But if you're already familiar with a VCS then it should certainly be used. \$\endgroup\$
    – bummzack
    Mar 29, 2011 at 22:04
  • 4
    \$\begingroup\$ Ricket's advice for aiming low and using a prioritized list are great — they're about minimizing risk and increasing iteration. You want to avoid situations where you have to work for 8 hours before you get anything running. If it doesn't work out or if it takes longer than that you might end up with nothing. Instead try to get a game running in under 1 hour and then spend the rest of your 10 hours adding things, play testing, refining. As you play you'll keep finding more things to add. \$\endgroup\$
    – amitp
    Mar 29, 2011 at 22:47
  • \$\begingroup\$ @bummzack Agreed! It can REALLY get in the way, thus practice and being sure about it are key, but it can also be super awesome and useful if used correctly. \$\endgroup\$
    – Ricket
    Mar 30, 2011 at 1:41
  • \$\begingroup\$ The best thing how to get things working fast is to do it in extreme programming fashion (better than svns), which i mean that whole teams sits together in front of one computer. It works great in small teams (2-3 max). You support each other and problems are solved more quickly - you dont get frustrated. \$\endgroup\$
    – Notabene
    Mar 30, 2011 at 9:46

Don't aim too high. Pick something you're interested in and build something simple around that. Example: Maybe you're really interested in learning about a physic-engine. Why not build a physics-puzzle like totem-destroyer or similar? Try to revolve around a core-element and don't include other complicated stuff like A.I., sophisticated rendering/graphics/shaders etc.

Focus on one aspect and try to find a game-mechanic that suits that. If you're interested in 3D, your game could be as simple as tic-tac-toe, but focus on getting good 3D graphics on screen.

Don't try to learn too much new stuff at once. Make use of existing frameworks/tools as much as possible.

To round this up, here are some ideas for a "getting started" game: What are good games to "earn your wings" with?

Update: Since you're really short on time, I'd reduce the "new stuff to learn" to an absolute minimum. A physics-engine might already be overkill if you never used one before. Also pick a game-mechanic you already know, preferably with a well defined and small ruleset and limited amount of game-states.


If you have no prior experience in writing 3D games, I'd drop the 3D idea immediately. Instead, focus on a simple game-play concept and try to implement it using simple 2D graphics. Make sure you implement the game mechanics first - if you're finished earlier, you can still add sophisticated visual effects.

But a game without gameplay isn't a game while a game without stunning graphics can still be fun.

20-30 work hours is very little time for a good game, so you really need to plan and prioritize your tasks carefully or you'll never get to a proper result.

  • \$\begingroup\$ A good point indeed :) \$\endgroup\$
    – Øyvind
    Mar 29, 2011 at 19:55

Not the answer you're looking for? Browse other questions tagged .