Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (775)
Games in Android Showcase (230)
games submitted by our members
Games in WIP (856)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  what is the easiest way to create a game  (Read 2543 times)
0 Members and 1 Guest are viewing this topic.
Offline isslam3kkilah

Junior Newbie


Exp: 7-9 months



« Posted 2018-07-09 10:36:26 »

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
Offline jonjava
« Reply #1 - Posted 2018-07-09 10:43:50 »

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 ).

Offline isslam3kkilah

Junior Newbie


Exp: 7-9 months



« Reply #2 - Posted 2018-07-09 10:52:34 »

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.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline beeaware
« Reply #3 - Posted 2018-07-09 13:36:55 »

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 know you're getting old when you played Pong while it was still hot...
Offline DarkCart

JGO Kernel


Medals: 124
Projects: 9
Exp: 50 years


It's all in the mind, y'know.


« Reply #4 - Posted 2018-07-13 08:17:10 »

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.

The darkest of carts.
Offline princec

« JGO Spiffy Duke »


Medals: 1059
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #5 - Posted 2018-07-13 08:57:40 »

Gotta start somewhere.

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

Cas Smiley

Offline gouessej
« Reply #6 - Posted 2018-07-14 08:59:25 »

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.
https://blogs.oracle.com/java-platform-group/the-future-of-javafx-and-other-java-client-roadmap-updates

Julien Gouesse | Personal blog | Website | Jogamp
Offline nsigma
« Reply #7 - Posted 2018-07-14 13:36:36 »

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

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.  Smiley

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline tariqbroadnax

Senior Devvie


Medals: 7
Exp: 3 years



« Reply #8 - Posted 2018-07-15 04:27:18 »

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.
Offline KevinWorkman

« JGO Plugged Duke »


Medals: 287
Projects: 12
Exp: 12 years


HappyCoding.io - Coding Tutorials!


« Reply #9 - Posted 2018-07-15 19:30:42 »

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.

HappyCoding.io - Coding Tutorials!
Happy Coding forum - Come say hello!
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline philfrei
« Reply #10 - Posted 2018-07-15 20:45:21 »

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.
https://blogs.oracle.com/java-platform-group/the-future-of-javafx-and-other-java-client-roadmap-updates

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.

music and music apps: http://adonax.com
Offline princec

« JGO Spiffy Duke »


Medals: 1059
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #11 - Posted 2018-07-15 22:03:33 »

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 Smiley

Offline nsigma
« Reply #12 - Posted 2018-07-15 22:23:03 »

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?

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline princec

« JGO Spiffy Duke »


Medals: 1059
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #13 - Posted 2018-07-16 09:03:58 »

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 Smiley

Offline nsigma
« Reply #14 - Posted 2018-07-16 14:39:20 »

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.

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 ...

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

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.  Smiley  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!  Grin )

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline CommanderKeith
« Reply #15 - Posted 2018-07-17 05:53:27 »

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.

Offline philfrei
« Reply #16 - Posted 2018-07-17 06:38:49 »

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.

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.

music and music apps: http://adonax.com
Offline nsigma
« Reply #17 - Posted 2018-07-17 08:31:23 »

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?

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.

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?

Everything!  Wink  Decently performing geometry ... and shaders is what comes immediately to mind.

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?

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

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.

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 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?

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.

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline princec

« JGO Spiffy Duke »


Medals: 1059
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #18 - Posted 2018-07-17 10:48:03 »

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 Smiley

Offline CommanderKeith
« Reply #19 - Posted 2018-07-17 11:11:17 »

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.
Thanks for that, I didn't know about this new renderer Marlin.
Some interesting slides about it from 2016:
https://bourgesl.github.io/fosdem-2016/slides/fosdem-2016-Marlin.pdf

Offline jonjava
« Reply #20 - Posted 2018-07-17 11:14:53 »

There's a huge market for developers familiar with Java that are transitioning, due to necessity, to web development.

That's where things like Angular and Vaadin in particular comes in. And that's fine.

I wouldn't necessarily recommend it, though. Web Development is a fast moving and interesting field. It's not what it used to be 5 years ago, at all.

And you'll be constrained using these kinds of wrappers; Although that can also be a good thing in some situations and maybe that's perfect for some.

If you're a half decent Java developer you can pick web development up instantly and master it in a few months.

There's a huge surge of people that have never coded anything else but Web Development; and they're at a disadvantage to a seasoned developer since the knowledge you've accumulated is extremely valuable, especially lower level stuff.

2cents

Offline philfrei
« Reply #21 - Posted 2018-07-17 23:05:25 »

Thanks for responding to my questions. I have to admit I'm having trouble understanding everything being written.

Does this sentence say that one can't code JavaFX in NetBeans or IntelliJ? Don't both IDE's support both AWT/Swing and JavaFX?

Quote
Maybe because 2 of 3 IDEs (NetBeans and IntelliJ) are still using Swing with no plans to move to JavaFX AFAIK.

My NetBeans supports JavaFX projects. (I mostly use Eclipse, though.)



************

What is going on with the Electron example? I've not used Electron. Can you run a more complex audio example like Praxis with it? How much, if any JavaScript coding is required? Can you pack and run a custom/modular JVM with it?

If so, this seems like a good alternative to Applets or WebStart approaches, and a way to write Java games that run on the Web.

************

Quote
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.

Since I haven't really worked with Shaders, maybe I can extrapolate from examples in Java audio. With the Clip (and AudioClip in JavaFX), we are given a few things we can do ("limited API") and no access to the audio data itself. That is why I wrote AudioCue, to provide a way to access the audio data. But this class relies on being able to output data via SourceDataLine.

So, is this a situation where there is no SourceDataLine equivalent, even if you did write a more functional Shader?

Thanks. I'm not trying to be difficult, just to better understand.

music and music apps: http://adonax.com
Offline nsigma
« Reply #22 - Posted 2018-07-18 11:01:56 »

Does this sentence say that one can't code JavaFX in NetBeans or IntelliJ?

No, I mean they're both written in Swing.

What is going on with the Electron example? I've not used Electron. Can you run a more complex audio example like Praxis with it? How much, if any JavaScript coding is required? Can you pack and run a custom/modular JVM with it?

The example I linked to is using the DukeScript demos, built on top of the NetBeans HTML4Java library.  While you can use JavaScript, you don't have to.  eg. there's a Graphics2D-like Java API that talks to a HTML Canvas element.  My thought is using a headless JVM and a Chromium based UI - this was just a quick experiment.  Vague thoughts of a long term replacement for the PraxisLIVE IDE, not the PraxisCORE audio / video / GPU stuff.

If so, this seems like a good alternative to Applets or WebStart approaches,

This is a market DukeScript are targeting, mainly legacy business stuff AFAIK.  But that's mainly using Java running in the JavaScript engine of the browser using bck2brwsr or TeaVM, not running a headless VM and lightweight local server.  Still trying to convince them to donate their server displayer code to the upstream Apache project (currently that bit is GPL) so I don't have to rewrite it!  Smiley

Since I haven't really worked with Shaders, maybe I can extrapolate from examples in Java audio. With the Clip (and AudioClip in JavaFX), we are given a few things we can do ("limited API") and no access to the audio data itself. That is why I wrote AudioCue, to provide a way to access the audio data. But this class relies on being able to output data via SourceDataLine.

So, is this a situation where there is no SourceDataLine equivalent, even if you did write a more functional Shader?

Not quite, because shaders don't run in the VM.  It's more than access to pixel data, it's the ability to run code on the GPU that works with that data.  Closest audio concept I can think of is the ability to interface with and define custom functions on one of those external DSP boards.

Praxis LIVE - hybrid visual IDE for (live) creative coding
Pages: [1]
  ignore  |  Print  
 
 

 
hadezbladez (25 views)
2018-11-16 13:46:03

hadezbladez (34 views)
2018-11-16 13:41:33

hadezbladez (18 views)
2018-11-16 13:35:35

hadezbladez (13 views)
2018-11-16 13:32:03

EgonOlsen (1890 views)
2018-06-10 19:43:48

EgonOlsen (1926 views)
2018-06-10 19:43:44

EgonOlsen (1283 views)
2018-06-10 19:43:20

DesertCoockie (1711 views)
2018-05-13 18:23:11

nelsongames (1400 views)
2018-04-24 18:15:36

nelsongames (2032 views)
2018-04-24 18:14:32
Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08

Deployment and Packaging
by gouessej
2018-08-22 08:03:45

Deployment and Packaging
by philfrei
2018-08-20 02:33:38

Deployment and Packaging
by philfrei
2018-08-20 02:29:55

Deployment and Packaging
by philfrei
2018-08-19 23:56:20

Deployment and Packaging
by philfrei
2018-08-19 23:54:46
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!