what is the easiest way to create a game

Hello there, i am totally new to this forum, but i have an old experience in java development which I adopt from old project doing it my self i was thinking to move my understanding to learn more about java gaming which i found it cost much more time than lua love2d which i tried only with no strong backbones in it. so where do you think i should start i know about maps and type of maps, but to be honest i am the last person on earth to ask him to draw i even finger print my signature.

note: don’t worry much my java experience are not that bad i know about jdk and ides type
important: what is the best section for people like me to learn in this forum. because, i am totally new and i don’t know where to start reading and posting in this community

Thank You
Isslam3kkilah

Find out how to draw images on a screen.

Then find out how to make those images move in a direction.

Then find out how to listen for input ( keyboard or mouse ) and move the image accordingly.

After you know how to do those things then you can start looking into more game like concepts, depending on what kind of game you want to make.

For beginners I would recommend starting with a simple browser/web game ( using html5 ).

thank u read the end of each requirement and the tail
Then find out how to listen for input ( keyboard or mouse ) and move the image accordingly. [done]

Find out how to draw images on a screen. [Okey i hate that part]

Then find out how to make those images move in a direction. [ok good i need library]

After you know how to do those things then you can start looking into more game like concepts, depending on what kind of game you want to make. i am already in it

For beginners I would recommend starting with a simple browser/web game ( using html5 ).

about java i have oo good knowledge cause i just stopped doing ERP system like for bit long time, but gaming i am so good at library and the most easy way to do implementation cause i had problem with that.

Check out this section by @philfrei -> http://www.java-gaming.org/topics/getting-started-with-javafx-game-programming-for-java-programmers/37201/view.html

You can make a “game” using a JFrame, swing timer for the gameloop, Java2D for graphics, and AWT KeyListeners/MouseListeners for input. All in one class, if you’re smart enough. Don’t expect to win any love or adoration from the “serious” programmers here if you choose to do it this way, though.

Gotta start somewhere.

I’d start with JavaFX these days though, not AWT.

Cas :slight_smile:

Hey

I’m not sure that using JavaFX is a good idea when I read this:

[quote]Starting with JDK 11, Oracle is making JavaFX easier to adopt by making the technology available as a separate download, decoupled from the JDK.
[/quote]
https://blogs.oracle.com/java-platform-group/the-future-of-javafx-and-other-java-client-roadmap-updates

JavaFX is probably in a healthier position with that than it has been in the last few years half abandoned, tied to the JDK.

Still not fussed on it mind you. :slight_smile:

If you don’t plan on using 3D, lighting, or particles, that is, you only plan on using images and simple shapes, then Swing is fine.

You could also consider using Processing, which is a language / library designed to make it easy to make visual and interactive programs. Get something simple working first. Show a rectangle. Then make that rectangle move. Then make Pong. Work your way forward in small steps.

Shameless self-promotion: I’ve written some Processing tutorials that start with the absolute basics available at HappyCoding.io.

https://blogs.oracle.com/java-platform-group/the-future-of-javafx-and-other-java-client-roadmap-updates
[/quote]
Thanks for providing the link.

The author of the article, a “Senior Director of Product Management” at Oracle seems to be reading and responding to comments!

What is the capability that members here have been asking for concerning JavaFX? I’m not up on it because I don’t use graphics at an advanced level. It seems to me, though, that it pertained to being given direct access to the bit level data used in graphics. Is this right?

I’m wondering if this is like the situation with javax library’s Clip and with JavaFX AudioClip. In both situations, the coder has no direct access to the bits, which is why I wrote AudioCue.

This would be a good place to put the question to him, to let folks at Oracle know that there is a constituency with an agenda. Point me to some articles so I can better understand the matter and I will write it myself. I’m not shy about putting my foot in it.

I’m not clear on what this upcoming detachability amounts to. With modularity implemented, there is already a degree of being able to write code that is honed to use with JavaFX.

The main issue with JavaFX is that it was closed-source and that the back-end renderer was inaccessible, and on top of that, the team maintaining it were quite reluctant to understand some of the reasons that some developers might have for wanting to get right in there and do things at the back-end level. For example… let’s say we wanted to render stuff in OpenGL directly and then have that as part of the scenegraph structure. Well, they made that essentially impossible and were very reluctant to make it happen and really I can’t fathom why they were quite so oblivious to the need. With the detachment from the JDK and the open sourcing we might see a bit of progress on this particular front.

There are a few other issues too like how difficult it is to customise controls’ appearance and behaviour or build completely new controls but that’s sort of secondary.

Cas :slight_smile:

JavaFX has been open-source for 5-7 years already. It all still depends whether those leading on development and maintenance (eg. Gluon) are interested in opening up the API in that way. Unless you want to fork it?

I don’t think forking would be the answer for JavaFX… if I were going to put that much effort into a UI library for games I’d totally make my own API from scratch that did exactly what I wanted! I will just have to wait until someone influential in the games industry joins the maintenance team efforts and… hmm.

Anyway, I watch it with interest, and it absolutely is a better bet to use for games than AWT/Swing.

Cas :slight_smile:

No, neither do I! It was meant somewhat tongue-in-cheek. You said a main issue was that JavaFX was closed source, but it hasn’t been for quite some time. So, that wasn’t what was stopping this happening. Will that change now? I don’t know, but it feels late, maybe too late, even if the new maintainers are interested. Maybe it isn’t. A few inklings of conversations around this very topic recently …

There’s a good chance that AWT/Swing will outlive JavaFX. Been involved in a few conversations at (un)conferences, mailing lists, etc. about future of UI’s in Java - niche, but still relevant for IDEs, tools, etc. Worryingly little consensus, except that JavaFX probably isn’t it. :slight_smile: Fair few people feel that HTML 5 ala. Electron but Java will be the answer! :persecutioncomplex:

Personally, to the OP, I’d say if you’re happy working with the limitations of JavaFX, you’re probably better looking at HTML 5 - either fully browser based, or in Electron with a JVM,

If you want something more, then perhaps start with libGDX, or Processing as Kevin suggested (although in PraxisLIVE obviously! ;D )

Doing user interfaces in html makes a lot more sense for programmers and users. For users, being able to highlight and copy text and images in a browser based UI is convenient for searching for error fixes and how to customise things. For programmers, html is quite portable across operating systems and most already know how to code it which avoids having to learn a new UI API.

princec, you wrote:[quote]the team maintaining it were quite reluctant to understand some of the reasons that some developers might have for wanting to get right in there and do things at the back-end level. For example… let’s say we wanted to render stuff in OpenGL directly and then have that as part of the scenegraph structure.
[/quote]
I’m not at all sure I understand.

At this point, has the back-end level been made accessible or would the only way to have it accessible be via a difficult to write fork? (Would you mind taking a moment to point to specific Objects involved or a proposed method signature? I would find that very helpful.)

Is the example you gave about rendering to OpenGL directly still pertinent? Are there other examples?

I’m assuming there are things that one can do in OpenGL that are faster than rendering with JavaFX, or that there are simply things one can’t do in JavaFX that one can with OpenGL? Is it both? What are a few good examples of things that we can’t do with JavaFX that become available if rendering to OpenGL is made possible?

CommanderKeith: I’m not clear on the argument of just using HTML instead of Java. There is still plenty that JavaScript/HTML/CSS can’t do, in terms of performance and in terms of sheer readability and maintainability of code. The HTML may be transferable, but the JavaScript?

FXML is a nice feature of JavaFX.

nsigma: I don’t see the logic of Swing/AWT outliving JavaFX, except for maybe the fact that there is so much legacy code. People are still coding in COBOL. That is not exactly a convincing argument for using COBOL over another language for a new application.

I am serious about putting some sort of query to this fellow that goussej found. Something along the lines of “a bunch of us at Java-gaming.org would like to see JavaFX do X, Y, Z. Are any of these enhancements possible/in-the-works?” And I’d try to make a case for how having a healthy game-writing community benefits the overall health of a language. But I will need help with spelling out the specifics that are being requested! Can any of you help some more with that?

If so, thanks!

Every language is going to have its pros and cons. The big strengths of Java (to me) are that the language is a lot more readable and maintainable, and that one can go pretty low level. It doesn’t have to beat every other language in all their aspects in order to have adherents/enthusiasts and to have continued interest in writing games and applications of a certain size and scope. There seems to be a lot more happening these days to keep the language relevent, and it is being done via about as rational and well-thought out process as could be expected for something so huge and complex. I’d like to do a bit of lobbying on behalf those who are interested in the game programming.

Back-ends. Both a pro and con of JavaFX, like too many things in the Java world, is trying to abstract over multiple back-ends, hindering / removing access and ending up with the lowest common denominator.

Everything! :wink: Decently performing geometry … and shaders is what comes immediately to mind.

Who needs JavaScript!? http://www.java-gaming.org/topics/what-i-did-today/33622/msg/368810/view.html#msg368810 ;D Or look at systems like Vaadin, which is now being used to make desktop applications.

Maybe because 2 of 3 IDEs (NetBeans and IntelliJ) are still using Swing with no plans to move to JavaFX AFAIK. And I think JavaFX is still lacking in essential features for that to happen. JavaFX development has been pretty stagnant in recent years, and so has adoption. Rightly or wrongly (and quite a few things wrongly IMO), the world is generally going HTML5 on desktop. I’m more positive now that JavaFX might have a chance given the way development is evolving, but that window of opportunity is closing fast. JavaFX is also missing some rather important things - there’s a part of me that would rather see an AWT++.

So, would people still pick Swing/AWT over JavaFX? Well I know people still are. And many of those who might be looking for something else aren’t looking at JavaFX.

As for AWT being legacy - the API might be, but various parts of the back-end are still getting a lot of work, like the new Marlin renderer for Java2D.

I wouldn’t bother contacting them directly, I’d sign up for the OpenJFX mailing list. Just be sure to browse the archive first though! :wink: There are things that would make it more useful in terms of low-level infrastructure and access that are also being brought up by people using it in data visualization, which in all honesty is likely to have greater sway.

Basically what @nsigma said there - JavaFX fundamentally hides everything that anyone normal would want to do with a modern computer which is baffling. Shaders for example. It hides everything under a hidden back-end interface and provides a functional but extremely limited front-end API to it all with a lowest common denominator approach which appears to be OpenGLES. Which they then inexplicably hide the implementation of on Windows (I did get it working on Windows once and it worked just fine).

More than all that though I’ve already got some pretty funky game rendering going on which is totally unsuited to JavaFX at all, excepting for the fact I want to feed it into JavaFX’s compositing scenegraph and use JavaFX to handle input. JavaFX is specially designed to make that impossible to do efficiently and there has been mysteriously no enthusiastic take up of the idea of perhaps not making it so. The mind boggles.

Cas :slight_smile:

[quote=“nsigma,post:18,topic:59566”]
Thanks for that, I didn’t know about this new renderer Marlin.
Some interesting slides about it from 2016: