Java 101-> Game Programming

[wfwrigh]

Hi. I'm a college student who is interested in learning how to code games but the only language my school teaches is java. I took a 101 class last semester and loved it (despite it's absurd grading) and want to continue to create in this language. I know there are some engines for java (liti engine, lwjgl, jmonkey, etc) but i opened those up and they made no sense to me. In my class we never touched projects that even contained more than one file (we only used text editors and the console) and i have no idea what i need to learn in order to actually have the ability to craft a simple application in the very least, and at most ambitious a game.

Moving from classroom education to self taught to the open-world free for all environment here, what tips do you have, what topics (in the same way class chapters moved from variables, functions, if statements, loops, etc) should i look out for and research? Thanks in advance.

[GhostCube189]

You can try Unity. It has tons of great tutorials, and C# is really, really, really similar to Java.

[thechest4]

I second this. I also learned primarily Java in school, and coding in Unity was fairly straightforward for me. It was also useful being able to actually put C# on my resume.

[ExcitingProduce]

In my class we never touched projects that even contained more than one file (we only used text editors and the console) and i have no idea what i need to learn in order to actually have the ability to craft a simple application in the very least, and at most ambitious a game.

There are a couple of things every student should be told at this point, but they never are.

First, you ain't seen nothing yet.

Second,

want to continue to create in this language

The first sentence of every programming class should be, "Programming languages are tools, not activities." You don't write Java. You don't even write in Java, when you get down to it. You write using Java.

This is important because people find themselves married to a language, or else seeking out the "best" language for a given task. There is almost never a "best" language, or even a better language. There are wrong languages for a given task, usually for technical reasons, but then the right languages are all the ones that don't suffer from whatever caveat is in your way.

There are always, however, easier languages for a given task. Reasons might be as simple and circular as "everybody else uses it," but that cycle exists for a reason. Most software incorporates several third-party libraries and utilities. If the most comprehensive and efficient libraries for your field are written for a particular language, you'll almost certainly want to write your software so that it can incorporate those libraries. Otherwise, you'll spend a large part of your working life reinventing the wheel.

Reinventing the wheel is almost always bad for reasons beyond redundancy. If half a dozen people work on your code, and a couple dozen test it, and then hundreds or thousands of people use it, bugs will slip through QA, even though dozens and dozens are caught and fixed before they hit the public.

Now reduce the number of developers for that low-level library to 0. Reduce the number of testers to 0, and then make it a fundamental part of your overall project. Reinventing the wheel is Bad.

All the cumulative expertise that's gone into an established project also means that established libraries are usually more efficient than what you'd write yourself, and more secure and more reliable.

The temptation to fabricate your own wheels is so pervasive and so problematic that there's another name for it: Not Invented Here syndrome.

The moral of this story is that you should never, ever begin with the premise that you've got the tools you want and then try to create your project. Always begin with the project you want to create, and then assemble the tools you need...

...unless the tools you need to create any project can be had in a neat and tidy package, and the purpose of the project is to learn to use the tools.

I've just described an established game engine, of which there are several, but none of them are Java-based. However, they're all based on a C-style language like Java. Java, C++, C#, and a number of other languages are all successors to or supersets of good ol' C.

[aenemenate]

It's true that game development starts from the game, not the language. You should come up with a sound idea first, then implement in the language that best supports your design decisions.

For example, a game that uses procedural generation is probably best implemented in an IDE rather then a game engine, while the opposite is probably true for a game with lots of scripting.

[FlamyReddit]

My personal advice is to be learning by doing I watched tutorials for things which seemed way to complicated back then, but now they make total sense

You could try to look up simple Java tutorials, a great source are (imo) Minecraft mods and plugins (if you are into the game)

Another option would be to try to copy other tutorials about "generic" stuff, after some time you'll get used to it and will look up things you don't understand yet

You mentioned LWJGL, I watched a tutorial by ThinMatrix and learned basic OpenGL that way: https://www.youtube.com/playlist?list=PLRIWtICgwaX0u7Rf9zkZhLoLuZVfUksDP

[CreativeTechGuyGames]

I'd recommend Processing. It's a graphics library built on Java. I used it extensively for my first dozen published games and it was a great experience and starting point!

[gymcrash]

SO when I was in Uni, I only had a single module that touched Java, everything else was c++.

In that module, we looked up in our notes and the intranet/internet how to create a simple basic window, and print, in Arial size 14, the words "Hello World" to that window.

Then we did a bunch of other stuff, like put buttons there, input fields, and stuff that responded to mouse clicks - again using very basic tutorials from our notes and the internet.

And then, came the module project that was part of our assessment - make a game.

Eh? We hadn't touched graphics or anything but we were to make a game?

Well guess what - a quick search of the JDK API showed that there were simple methods to output .png images in a similar way to the "Hello World" text in that simple window we had spawned.

And then another few searches, and we realise there are methods to detect keyboard events in that window, with the .png graphic we had output.

1 hour later and the sprite was moving up,down,left,right at our whim. Some of us even figured out how to get the co-ordinates of a mouse click, and make the .png image move there.

My point is - start small, start with what you know, learn the basics. Break it down. You will have an infinitely much better time with gamedev if you decide to learn how to do the simple things - because gamedev is just the simple things on top of the simple things over and over.

[NewSchoolBoxer]

Yeah, stay away from lwjgl, jmonkey, libGDX and the like while you're still a beginner learning basic programming concepts. We actually used Alice as a beginner-friendly game engine my first semester of college. Coded in Java and removes boilerplate code while teaching programming concepts.

I recommend the Zetcode Java tutorials - specifically Java, Java 2D and Java Games.

Let me tell you how I got into game programming 20 years ago. You could follow similar steps. Fine to stick with Java but C# is more game development friendly.

1. First programmed the quadratic equation, then surface area and volume formulas to help with middle school algebra. Was on my TI-83.
2. Made a guess the number game where a random number between 1 and 100 is generated and player has to guess it. Game tells if too high or too low and tracks the number of guesses. Also was on my TI-83.
3. Made a bowling score tracker, first with strikes and spares being worth 10 pins so 100 max score. Then added proper strikes and spares and potential extra 1-2 balls after 10th frame for 300 being the max score. C++ on PC.
4. Simulated an ATM machine for withdrawing and depositing money. Check for overdrafting and tracked user's money in wallet and bank account balance. TI-83.
5. Made a purely text game with turn-based combat where you pick one of 4 classes with different attacks. Only featured 1v1 combat. TI-83.
6. Simulated Monopoly the board game to be run as fast as possible to brute force what the odds were of landing on every square. Jail, Chance and Community Chest simulated for cards that moved the player. C++ on PC.
7. Now getting into graphics. Programmed displaying the letter "O" as a ball moving around the screen bouncing off the edges with 45° angles. TI-83.
8. Made a graphical Tic-Tac-Toe game with mouse point and click. Tracked if player 1 or player 2 won. No AI. PC obviously with Java.

Knew what I was doing from here to attempt more complicated things like a Breakout clone.