Summarize Your Life.


About Those Java 2D Game Development YouTubers...

It has been a while since I last posted here. A LONG while. But in a sense, that's good; because now I'm starting with fresh content. In specific, I've been following a few Java game development tutorials playlists on YouTube, and boy oh boy do I have a few suggestions...

First things first. I've known Java programming since around the early-1990s, at least picking up the basics at the time I was a high-school senior. I had not really done much with it since, making a few hobbyist things -- rpg utilities, dice-rolling class libraries, general gaming support classes, et cetera, and so forth. Yeah, I've been around, so I know things -- but I still keep in touch with plenty of game-dev noobs, to help them the way someone else helped me. Don't believe that I know everything about everything; but please do that I do have a lot of experience, I've learned from obvious mistakes, and I also want to help you too.

Second things ... eh, second? I really have seen some hot-and-heavy commentary going on in the past about "which is the best IDE", that often devolves down into "absolute proof" pointing out the features of one over another. I'm not about to be dragged into such a debated topic, but I will say that my personal choice is NetBeans IDE, because in my case it's allowed me to be much more productive in coding and refactoring. But the point here is, try a few different IDE programs, and see which works the best for you. Watch a few YouTube tutorials seeing active development taking place with each of them, get a sense of how the program may or may not fit you as you would type code

Third? On to the meat of the feast; now I'm getting closer to the "Java game dev" aspect, but I suppose I should also mention the rpgs. I have also -- either fortunately or unfortunately, take your pick -- played as well as developed with a software tool/infrastructure called "RPG Maker" by a tiny little company called Enterbrain. Being someone who loves to tinker with roleplaying games, on the tabletop as well as digital domain, I have dug around to see what this RM craze was all about. I've dug deep into it from the VX and VX Ace days, and then also gone back to the XP days to get some context of how things were. Feel free to try other, non-Java-development things, just to give yourself alternate perspectives and ideas about what is out there.

And now, it is comes down to this. I mention I have been watching some YouTube playlists over the last few years, yes? Well, all along I have been leaving comments below the videos pretty much alone; but lately more than ever I've been on the mindset that "Why not respond to some? The questions are there, the channel owner isn't all or even most of the comments, so ... why not use some of my expertise to help out?" -- With various results as you might expect. Eh, "you win some, you lose some", but I don't let it get to me.

So. This thing. "Java 2D Game Development Tutorials". -- If you have ever created such a series, or even watched or followed along with the videos, you begin to notice many patterns: patterns that I will, time and again, mention and provide experienced commentary upon.

The Introductory Video(s).

One necessity, of course, is in saying who they are, maybe where the series is going, perhaps a specific design goal or purpose behind why such a series is being developed. In some cases a video tutorial series might be the person's second time through a development series, a "reboot" of sorts, where they admit momentarily how lost they got along the way of developing the precursor series.

Or, sometimes the YouTuber or streamer does not really go into the logic or pacing or even order of their video series; in such cases, the viewer can only ascertain such things from commentary and example from the video content itself, as time passes. If the viewer is lucky, perhaps the YouTuber might have a defined list of objectives or modules through which the series will proceed; and if the viewer is extremely lucky, perhaps the 'tuber might illustrate and explain his or her thoughts and style of it all.

(For an aside-comment, I don't really care if the speaker is male or female, young or old, of this or that nationality or skin color -- I only care that the person making the video has some natural cadence or rythm in their speaking ability, and enunciates the words as clear as can be expected, given their computer, microphone, and assorted recording equipment. I do wish that more of the YouTube tutorial series were eloquent English-speaking females -- not in support of any damnable socio-political agenda that may be out there, but only because I wish to hear it clearly, and if I were a betting man I would bet that a higher ratio of females than males can speak more eloquently, I am betting on the female voice itself as providing a clearer tutorial than many male speakers.)

And this mythological premiere video might also tell which IDE or development infrastructure that the video maker is using; I am not surprised that the majority use eclipse as their tool of choice, but I am thinking it's deplorable that it's the only tool they describe as what to use. Really. The development world has many, many MANY more than that; as mentioned above, I use NetBeans IDE, but I've also seen Jetbrains, and many others. Heck, a developer could even really use a plain-text editor to create the classes if they so chose; but such a person is betting on their own development skills (which might not be as perfect as they think). I would rather hope that a developer would use a proper IDE which provides syntax-coloring, highlighting, error-detection, and refactoring support, but that's just me.

Jumping Into Coding Classes.

And then, it gets right down into it. For the realm of a Java 2D/tile-based game development series, you will absolutely detect a series of opening development videos in common with almost everyone else doing the same thing. The first stop on the development train just so happens to be in creating the project, creating the "main class", and then creating the "main game loop", in this order. If the video series is a collection of short (less than ten minutes each) videos, each of these steps might be in separate video, each aspect described ten ways to Sunday. Sometimes it's more of a hodgepodge of talking and defining things that a student of Java programming should already know, sometimes it's literally as terse as copy-pasting some templated code and making a few alterations.

Start With a Main Class.

One point that irks me, and I admit it, is that the developer typically makes the main class also hold the main game loop. Well. While that is not breaking any Java coding techniques, technically I prefer to break this apart somewhat. So a class that looks like this

public final class Main extends Canvas implements Runnable {
  // some fields and methods to get to the main game loop etc.

  private Main() {}

  public void run() {
    /* game loop code */

  public static void main(String[] args) {
    /* instantiation code */

could be broken apart a little bit so that it only starts with the static main method. In my implementation, I have that "extends Canvas implements Runnable" and game-loop methods in one, or sometimes two, separate class, the precise methodology depending on what I'm intending, and that might change from one project to another. No, this "main class" in my opinion should only serve one purpose: instantiate the game engine by first examining any passed-in arguments in a private static inner class, within the Main class

public final class Main extends Canvas implements Runnable {
  private Main() {
    // instantiation code, no args found, "normal" startup

  private Main(Args args) {
    // instantiation code, args found/parsed, handle or pass along

  public static void main(String[] args) {

    // more code;
    if(args != null || args.length > 0) {
      new Main();
    } else {
      new Main(new Args(args));    }


  private static final class Args {
    // maps or array-lists of parsed command-line arguments
    Map parsed;

    Args(String[] args) {
      // constructor, parsing implementation
If the static main method detects that the args parameter is null, the private constructor is instantiated and execution proceeds from this point; else if the arguments are not null,  an Args object is created and the arguments are iterated through, attempting to parse each one as a potential command that may be pushed along into the game, and the second Main constructor is the method to pass it along.

The point is, maybe the developer wants to optionally enable or disable certain "debugging" aspects in a play-through of the game engine, perhaps even based upon whether this is a debugging session or is a "released" game; and having a command-line parser object can be helpful in this regard. Whether it's to output to "System.out.println()" some text or help information, or to change some down-stream execution roles or properties (maybe screen width, height, or scale), specifying some String arguments can be very helpful.

Main Game Loop Logic.

I also see a lot of "copy-paste" of the main game loop logic; sometimes, the developer actually does explain a bit about game ticks (updates), rendering, and perhaps even a touch of thread operations. The techniques should also make clear just why it is important to have a steady frame-rate across all computers; if the game will contain any multiplayer or an online aspect, then game synchronization will be a very real necessity, although most Java game tutorials will not get into this until later.

The concept of game states and then game state management is also very important. I learned this concept years ago, even before exploring into the RPG Maker game editors/engines/platforms, but it did surprise me how well those RM creations did the state management in the Ruby scripting classes.

Basically, each aspect of the game is a state, typically subclasses of an abstract State class: the title screen, the menu screens where a new game is started or loaded from file, or even saved to disk, the tile-map instance being played upon is a state, and even game-over (win or lose) screens are game states.

Sometimes the concept of states are introduced right after developing the main game loop, sometimes not until a little while later; but often the tutor begins hard-coding some game map, some entities, some objects to get the viewers' understanding on a roll. In any case, after getting to a more-or-less-final "game loop" code, the sooner the coding gets to creating a state system the better, and the sooner both the tutor and viewers can go on to deeper topics.

Assets, Resources, and Referencing Objects.

This is sometimes the very first point at which viewers who follow along really start having serious problems. It is at this point that the introduction of images being used as sprites, animations, map tiles, et cetera. And, for some people who make a simple mistake or two, the errors start building from here.

It's not that the viewer is in any sense stupid or lacks an ability to follow the tutorial; it's that perhaps how it is described how Java handles reading in these graphical assets, and how the IDE handles the project structure, that might be confusing. I have seen well-typed source code that is, shall we say, a little less well-described in narration?

The basics are this: the Java class ImageIO is used to obtain a reference to a PNG image file, which is assigned to a BufferedImage object; then the image may be held in memory and used later on in displaying something to the screen. But, where exactly should these graphics be placed in the project?

Back to thinking about the IDE that might be used -- most people may use eclipse but this applies mostly across the board. A typical Java project will be created and instantiated with the primary Java source path, typically a folder named "src" under the project's root, and maybe optionally a primary testing-source path, a folder named "test" also under the project root; but unbeknownst to many beginner Java coders is just how extensible this (Ant-based) is to add to.

Underneath the project root may be one or more files, sometimes hidden or not shown within the IDE itself, to discourage accidental editing by the developer -- but these files are still there, on the disk under the project path. They may contain dozens, hundreds, or even thousands of lines of metadata and project description, often in plain-text like an XML-based format. Well, we still don't need to edit these metadata files by hand -- normally -- because our IDE's project explorer should make it easy enough to select our project's Project Properties dialog and tweak it as necessary.

And so it is at this point, that in an attempt to keep the Java code files separate from the non-code is made. These are assets, like binary font files, images of all sorts, sample game data like textual map definitions, and other plain-text or even binary files as necessary. The YouTuber or streamer makes at least some attempt to descriibe what to do, without perhaps going deeper into the why it is done this way; but it really does boil down to creating a folder path under the project root, and then manually adding it into the project definition files, either through the project dialog or via manual editing.

One tendency I have noticed is that this "resources" folder is mistakenly added into the project's source packages, as if the "res" is part of the package being included, when really "res" should have been added upstream from the "src" folder instead, so that both "src" and "res" are "sibling" child folders within the project root path. And then, the images and non-code assets are placed into this "res" folder.

What About That Slash?

Yes, the use of the slash character in universal resource names and addresses is in fact very important. By default I will use the "forward slash" (the top of the slash leans to the right of where the bottom of the line is) in such Java String asset references. Since we are referring to a URN that will be found within the final built jar, we begin with a forward-slash, then the name of the resource package (each folder level being separated only by an individual forward-slash), and ending with the actual file being referenced (with the actual file-extension).

Any spaces in folder or file names should either be removed, or substitute a "%20" for every single space in the reference string. Better yet, just do not be in the habit of including files which have spaces in their names to begin with, because it may be a source of headaches down the road.

Having a fonts package within your resources path that contains for example a Consolas.ttf font file, we will have the following static String reference to be loaded:

and it will be loaded properly, with no error. I really do not know how I can describe this any easier, yet I still see questions in YouTube comments that show examples of resource references beginning with "/res".

And Time Goes On....

Each successive video in a tutorial series, I now see quite a few comments about "when will you develop x feature" or "how can I do x in my project". It's understandable, but often this is the viewer getting impatient about getting into some "really interesting" facet of game development.

At its core, most game-development tutorial series are about learning the basics of Java coding, especially where it comes to game development. And then, viewers have an idea about perhaps a specific subgenre of game that they want to see developed, but which might not be within the scope of the actual tutorial series, but which few other game development tutorials are taking on themselves. It's rather easy to see and understand why, the tutor is trying to get as many started in a game development format as possible, and hope that the viewers take it and do something impressive on their own.

It's at least whimsically funny to me that at least half of the requests of "how do I" topics are either in developing a 2D "platformer" style of game, or an RPG where entities and characters than the viewer has dice. Having already mentioned near the beginning of this already-lengthy post my exploration and excursion into the RPG Maker series of editors and engines, I must admit that I too have searched YouTube for Java dev tutorials that went in that direction.

Yes. I want to make an rpg-maker-like game engine, editor, and platform infrastructure in Java. Technically, I already have, having followed through so many Java game development tutorial series from other YouTubers, and adapting and refactoring code so many ways to Sunday, that I've had a patchwork-quilt hodgepodge of Java class libraries full of ... well, almost everything necessary to make an RPG Maker.

I don't know what more to add here, other than that I shall attempt to add further posts to this old dusty blog, wherein I think, and think, and type out lengthy posts on incredibly mundane as well as interesting topics related to game-development issues that I have happened across. Follow me or not; comment or not; but I shall at least try to bring a conversational style to this, and try to foresee what common Q&A topics as necessary. So, ... "into the breach, dear friends", and join me on an interesting journey.

No comments: