Featured games (79)
games approved by the League of Dukes
Games in Showcase (476)
Games in Android Showcase (106)
games submitted by our members
Games in WIP (533)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
    Home     Help   Search   Login   Register   
Pages: [1] 2 3 ... 10
 on: 2014-07-25 04:18:07 
Started by jrenner - Last post by jrenner
I fixed my shader problems. shouldn't crash on mac or other linux distros anymore. Link is the same.

 on: 2014-07-25 03:57:46 
Started by kingroka123 - Last post by kingroka123
Such a simple answer.  Cranky

My filter was this :

so I switched them and got the result I needed. I should have looked at the syntax closer:


 on: 2014-07-25 03:50:49 
Started by assjiggler - Last post by jrenner
If you're new to input it doesn't occur to you right away (at least for me it didn't) but touchUp is called at the end of every touch, so you can use it as a hook for when a touch is finished.

 on: 2014-07-25 03:48:16 
Started by kingroka123 - Last post by BurntPizza

You need to use a Nearest filter, not a linear one, which causes the blurring.

 on: 2014-07-25 03:47:36 
Started by Orangy Tang - Last post by Catharsis
I think it's fair to say most ES tutorials barely contain interesting information. They talk about Components and Systems for: position, velocity, sprite, health, and that's about the depth of the article.

Indeed it's a bummer that most ES articles are so basic. The ones that are out there for Java at least are far more speculative than data oriented in benefits and lack implementation details.

The problem is that these things are no problem whatsoever in OO, when using encapsulation/composition, where you can toggle functionality at will (using inheritance is a rookie mistake). This approach obviously doesn't scale with the number of components, but... does it need to scale in this manner?

We agree that composition is the bees knees so to speak. A CA and thus ES brings implicit composition to the table and there are benefits to having this in the toolbox in addition to normal explicit composition and even a touch of inheritance, but not as a central organizational mechanism. The current Java ES implementations more or less have very limited CA features.

You get this sort of scaling for free built into a proper CA.

What would be a simple use case for a game with limited scope, where an ES clearly excels over proper OO? Given your lengthy posts, ESs are clearly saving you enough time to elaborate, yet again Smiley

The chitchat monster is a demanding beast. As mentioned a limited scope game where no design changes are expected OO design is perfectly suited for the task.

The CA aspects are what really make things a pleasure during development. I'm not necessarily speaking about the currently available Java ES implementations. A lot of the killer use cases for me are modularization at the SDK / engine level which goes beyond the game focused limited CA ES implementations available.

In my efforts these are the things I like:

- Similar to Spring and such TyphonRT features a declarative loading mechanism to load up the runtime from external configuration files. This is great because conditional dependencies are externalized and not peppered through the codebase. System components can self-wire themselves and traverse implicitly the entire runtime environment let alone ES specific use cases.

- I use XML for the config files since it's available everywhere, but really it can be replaced with anything including a binary format. The really cool thing especially considering Android Studio Gradle integration in regard to build flavors is that it's super simple to provide just one XML file defining the app and completely load different functionality for product versions or any other mutation in development via providing a new flavor that simply has a different app XML config file rather than duplicating a code base. This is also very useful for multiple developers working on a shared codebase since new development can occur in parallel with less disruptions or requirements to embed factories and nasty other hacks to not disrupt developers depending on the old codebase while the new one is in progress.

- In combination with implicit message passing it's possible to completely separate dependencies between system components while maintaining functional connections. This isn't new and aligns more closely with Alan Kay's original ideas on what constitutes OO design if anything. Getting away from the listener pattern is key in conjunction with a CA / ES. This is something that bums me out when I look at Ashley since it uses the listener pattern which reduces flexibility considerably.

- Velocity of development is much faster with a proper CA and code changes don't require large refactorings. It's great for rapid development where data can be implicitly passed around.

- It makes large codebases manageable along with providing the basis for explicitly knowing dependencies of code at hand and being able to limit side effects. This valuable in testing and multi-developer environments. Get something working 100% correct and know with certainty that there are no unintended side effects with code changes not linked to the modules at hand. This includes keeping individual classes small and understandable.

- A CA provides dynamic / functional like characteristics that run on all Java platforms maintaining type safety which is a huge boon over scripting languages in general.

- The CA provides a standard API for accessing logic and data and there is far less method based boilerplate creation. While the concepts need to be grokked by devs it is consistent.

- As mentioned by others data components are DAO and facilitate journalling, serialization, and concurrency concerns.

- CA supports tooling better than rigid OOP code bases.

- A proper CA provides the magic sauce to implement runtime modularization that goes beyond the service pattern (re OSGi). A fast / dynamic CA implementation plays nice with OSGi and other future modularization frameworks.

--- I can go on, but indeed I procrastinate and have some work to get back to.. ;P

I think it's something that once you really need it and give it a go it's hard to return to old development practices when possible. I constantly get bummed out when I do any client work as most of it is very bottom basement regarding OO design. Re: 90's are calling and they want their design patterns back.

The "classic" use case in games is particles. There are usually a lot of them.

Modeling particles as objects is obviously not the proper way to handle things nor is it appropriate with ES on a per particle basis.

Being able to attach to any entity a single data component with an array of particles being tracked is nice without having to add accessor methods / explicit composition.


Building a next-gen CA / ES is not easy and very time consuming... Using a well constructed one for dev for games or otherwise is liberating.  A lot of this is still forthcoming for Java. I'm an early adopter so to speak. I look forward to getting my CA / ES efforts out in the wild.

The chitchat monster says I'm being baited.. ;P again... :: sigh ::

 on: 2014-07-25 03:43:28 
Started by kingroka123 - Last post by kingroka123
I'm trying to get a pixely effect when zooming (and in general really) into these tiles in LibGDX, but whenever I do, they blur around the edges. Is there any way to get rid of this effect?

 on: 2014-07-25 03:42:26 
Started by jrenner - Last post by jrenner
tkausl, the new 3D API, is actually not so new anymore.  It's just an abstraction layer on top of OpenGL to make things a little easier to develop with.  I actually don't have any experience with the old 3D API

 on: 2014-07-25 03:32:09 
Started by Drenius - Last post by wessles
Great job, Drenius. I look forward to the next installment in this awesome series  Grin!

 on: 2014-07-25 03:28:46 
Started by orange451 - Last post by SHC

Yes. I've tested it with Mountain Lion and Mavericks too. Only thing is that you have to kill the finder and open it again to recognise it as application in mavericks 10.9.3

 on: 2014-07-25 00:43:54 
Started by BurntPizza - Last post by princec
Text editing widget working. Started on checkboxes. A surprisingly fiddly component.

Also did a fair amount of fiddling with Basingstoke, but that's Unity, and the Devil's work. We shall say no more of it here.

Cas Smiley

Pages: [1] 2 3 ... 10

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

pw (18 views)
2014-07-24 01:59:36

Riven (17 views)
2014-07-23 21:16:32

Riven (14 views)
2014-07-23 21:07:15

Riven (17 views)
2014-07-23 20:56:16

ctomni231 (45 views)
2014-07-18 06:55:21

Zero Volt (40 views)
2014-07-17 23:47:54

danieldean (32 views)
2014-07-17 23:41:23

MustardPeter (36 views)
2014-07-16 23:30:00

Cero (51 views)
2014-07-16 00:42:17

Riven (50 views)
2014-07-14 18:02:53
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22 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‑
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!