Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (579)
games submitted by our members
Games in WIP (500)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 ... 6 7 [8]
  ignore  |  Print  
  Still hardly any games, why entity systems suck, and why 4k is good  (Read 19383 times)
0 Members and 1 Guest are viewing this topic.
Offline gouessej

« In padded room »



TUER


« Reply #210 - Posted 2011-11-25 13:07:30 »

More people around here should evaluate using the runtime container from the NetBeans platform.  Great platform for deployment.  Cross platform and highly customizable installers / launchers (it is possible to include an embedded JVM with a bit of work), along with a decent module system, good native loading mechanism, and much more besides.
Does any game use it?

Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #211 - Posted 2011-11-25 13:10:32 »

I don't know really that any game really needs it.

Cas Smiley

Offline nsigma
« Reply #212 - Posted 2011-11-25 13:28:09 »

More people around here should evaluate using the runtime container from the NetBeans platform.  Great platform for deployment.  Cross platform and highly customizable installers / launchers (it is possible to include an embedded JVM with a bit of work), along with a decent module system, good native loading mechanism, and much more besides.
Does any game use it?

None that I'm aware of, but then I'm not sure how many people know you can use it as other than a Swing platform.

I don't know really that any game really needs it.

Try reading it in the context of what you (and others just above) had written about deployment!  It basically does what you mentioned, with a couple of nice extras thrown in.  It's not particularly heavyweight in the context of a desktop installed game.

Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline gouessej

« In padded room »



TUER


« Reply #213 - Posted 2011-11-25 13:33:13 »

Try reading it in the context of what you (and others just above) had written about deployment!  It basically does what you mentioned, with a couple of nice extras thrown in.  It's not particularly heavyweight in the context of a desktop installed game.
Is it possible to use it to make something as simple as Java Web Start for the final users?

Offline nsigma
« Reply #214 - Posted 2011-11-25 15:33:59 »

Try reading it in the context of what you (and others just above) had written about deployment!  It basically does what you mentioned, with a couple of nice extras thrown in.  It's not particularly heavyweight in the context of a desktop installed game.
Is it possible to use it to make something as simple as Java Web Start for the final users?

I think you're missing the point there! It's about making native installers and launchers so that the app / game behaves like any non-Java app / game, including things like desktop shortcuts / menu integration, as well as choice of VM (potentially included) or system one.  It could be simpler for end users because it's not some completely different mysterious process peculiar to Java.

One thing as you're a Linux user, like me.  The Windows and Mac options are standard to the platform.  The Linux installer is currently a self-installing executable, which works very well and also allows installation into the user's home directory, but automatic .deb / .rpm creation is unfortunately lacking - it's a manual job, though far easier given the launcher.

Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Offline delt0r

JGO Coder


Medals: 22


Computers can do that?


« Reply #215 - Posted 2011-11-25 16:00:18 »

.deb and .rpm are the worst possible way to distribute a game. Games on unix will almost always be installed in user space. Not system wide. Linux package management handles this very poorly.

I have no special talents. I am only passionately curious.--Albert Einstein
Offline gouessej

« In padded room »



TUER


« Reply #216 - Posted 2011-11-25 16:24:12 »

.deb and .rpm are the worst possible way to distribute a game. Games on unix will almost always be installed in user space. Not system wide. Linux package management handles this very poorly.

Most GNU Linux users have a root access and can use KPackage or any other GUI front end to install RPM and DEB. I don't understand your objection.

Offline nsigma
« Reply #217 - Posted 2011-11-25 16:34:52 »

.deb and .rpm are the worst possible way to distribute a game. Games on unix will almost always be installed in user space. Not system wide. Linux package management handles this very poorly.

Most GNU Linux users have a root access and can use KPackage or any other GUI front end to install RPM and DEB. I don't understand your objection.

Wish I'd never brought that up!  Roll Eyes

Installation in user space can sometimes be useful, and as I mentioned the NetBeans Linux installer works great.  In fact, it can install in user or system space, depending on whether it's run as root or not.  It's not like all the dependency stuff with RPM or DEB is usually that useful for us.

Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Offline delt0r

JGO Coder


Medals: 22


Computers can do that?


« Reply #218 - Posted 2011-11-25 16:37:17 »

So what if you have root? I don't want to install games globally. Period. Packages don't let you do that. Games are not part of the system so they don't and shouldn't be distributed as if they are part of the system (that is what these packages do, install things in places like /usr/bin etc).

Also no. A lot of us *don't* have root, for example at work i don't. When i am admin on a block of computers i don't give everyone admin. One of the criticisms of windows is you always need admin...... I am allowed to install games at work if they are not distributed with stupid package management crap. Like say the id games.

Also do you have a Slackware package? Just stick with a simple installer or a archive. Done and Done. Why make it complicated? Why make it so specific. This is not how windows does *user space application* installs.

I have no special talents. I am only passionately curious.--Albert Einstein
Offline kappa
« League of Dukes »

JGO Kernel


Medals: 70
Projects: 15


★★★★★


« Reply #219 - Posted 2011-11-25 17:16:05 »

Agreed about the package management issues on Linux but there are some installers that work reasonably well without admin permissions, however its far from ideal.

As much as I dislike Macs, I think their application bundles are probably one of the nicest solutions for downloadable applications. Easy as dragging and dropping. Also since the application and its files are all self contained inside the application bundle (everything inside one folder) it keeps the system really clean unlike the now retarded methods used by Windows and Linux where applications files are all over the place.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline nsigma
« Reply #220 - Posted 2011-11-25 17:27:49 »

Agreed about the package management issues on Linux but there are some installers that work reasonably well without admin permissions, however its far from ideal.

Like the one I was talking about - should never have mentioned package managers  Lips Sealed

As much as I dislike Macs, I think their application bundles are probably one of the nicest solutions for downloadable applications. Easy as dragging and dropping. Also since the application and its files are all self contained inside the application bundles (everything inside one folder) it keeps the system really clean unlike the now retarded methods used by Windows and Linux where applications files are all over the place.

Absolutely agree, both on the general Mac dislike and on application bundles.  But then, I grew up with RiscOS, which did this really neatly years ago.  In fact, a lot of good things on Mac were in RiscOS years ago!  Smiley

On a slightly related note, and as I posted in the JamVM thread, I noticed in an article the other week that Cyberduck is in the Mac App Store - interesting because it bundles a JVM in a nice self-contained bundle!

Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Offline sproingie
« Reply #221 - Posted 2011-11-25 18:27:21 »

Packages are handy for dependencies, but it doesn't make sense for most games, and especially java games.  I suppose the dependency on java itself is one, but java is something a lot of distributions have f***ed up in such epic fashion that I don't install it through the package manager either.
Offline pjt33
« Reply #222 - Posted 2011-11-25 19:39:42 »

I'm kind of surprised this isn't the common understanding and am at times kind of amazed at some of the discussion in this thread and forums in general. Not to be disparaging per se, but it's like CS 101 hasn't sunk in at all.
CS 101 shouldn't be covering software engineering. That's a completely separate discipline.
Offline pjt33
« Reply #223 - Posted 2011-11-25 19:41:03 »

Oh all bloody right Kev! So far I've used 8000 of my 16384 bytes and I've somehow managed to squeeze the entire sprite engine and effects engine and FM synth game framework from Puppygames into it.
Synth? Does it include basic drum effects implemented in a small enough amount of code that it might fit into a 4k game?
Offline sproingie
« Reply #224 - Posted 2011-11-25 19:48:06 »

Software engineering should be in a completely different curriculum.  Except it probably shouldn't be called "engineering" either.  As unsexy as it sounds, "Computer Programming" really does sum it up.

... says the guy whose job title is "Software Engineer".   persecutioncomplex
Offline Catharsis

Junior Member




EGR Software rocks!


« Reply #225 - Posted 2011-11-25 19:53:03 »

I fully understand the need to help people understand the usage of APIs by how you expose them.

No doubt.. One can't work that long in the industry and not grok that...  Grin

I just feel that most of the time it is a major pain in the arse deciding, when you aren't making a library for the use of others but instead writing end-code, or if you're the recipient of such a library, you simply can't use the code you have executing in your own damned program the way you want to have it executing if you don't have the source to hand.

I think there must be a better way.

Then don't criticize those looking towards entity systems and by general extension component architectures as wasting time or that they suck as the handful of us that are doing this are searching and some of us have found what we consider a better way. Searching and experimenting takes time and most definitely it takes an immense amount of time to convert a significant existing OO framework to a very granular component oriented one. I only did so after I saw the writing on the wall and pushed the older way to the limits. The inflexibility that you speak of above was obvious in my efforts with traditional Java / OOP mechanisms and I tried everything before going whole hog toward component architectures. Almost everything in my efforts now can be replaced or substituted fairly easily from external configuration files. A great deal of time was spent minimizing dependencies between components and related groupings so this is possible.

Beside the scenario above as you describe is just a poor API / framework that didn't do what it is intended to accomplish and I believe someone above commented on this sentiment in a reply above. I'm aware there may be times when a dev desires to mod a perfectly working API to do something slightly different as well, but usually that is an exceptional case as OOP in itself doesn't disable extension.

And that's how all new languages are born........

It can be, but I'm not ready to give up on Java yet. Though I certainly keep in mind how the CA can be leveraged from Scala and other JVM languages. In fact I certainly posit that it's a much better way to integrate Java w/ Scala or other JVM languages as opposed to extension of Java classes. I still need to experimentally validate this, but I put a lot of thought into it. A simple shift in perspective and coding practice is what I'm really trying to get at and while it works for me it may not work for everyone. The only downside so far is increased verbosity at the Java layer. There should be some ways with Scala for instance to reduce the verbosity in practice.

Now, I'm certainly not saying anyone has to follow me down the path I'm heading, but I do believe it will benefit any project small to large. It's not "f**king insane" as a poster above claimed. I have a large body of code that has only seen a benefit and things still chug along nicely in a reasonably complex 3D demo case. There will be early adopters and the typical bell curve of adoption. I most definitely have an up hill battle to fight, but it's an pedagogical one that can be overcome with good documentation, lots of clear tutorials, and perhaps a hit app or game + outside success stories. All that takes time...

To continue I would posit further that yet again this is a dirty mark on OOP and the is-a and explicit has-a relationship. It doesn't lend to flexible APIs / frameworks that can be easily extended or reconfigured and only truly works well for small to mid (at the most) sized projects in terms of maintenance unless there is someone full time working as a "cleaner / hands on architect" that can see the forest from the trees and has authority to refactor and uphold whatever standards that are set up. Code reviews are not enough in this regard as it's really an active full time position for a larger project with one or more folks involved day to day. Most small to mid sized projects with various devs involved benefit from a dedicated hands on architect.

Again a clarification, in my experience standard OOP as implemented in status quo Java projects doesn't work well as the central organizing mechanism, but is less of a deadly force in the leaves of any API / framework. Thus while my new efforts are component oriented they are partially still OO in the leaves which means some of the components / systems themselves. As a framework dev it's impossible to limit OOP in the leaves since OO is baked into Java. This is not necessarily the case for the entity system where it is recommended to minimize OO in the leaves, but for the runtime layer of my efforts it makes sense where there are component peers w/ a base cross-platform implementation + J2SE and Android peer extensions. Mind you the interface based programming aspect comes in because one stores the given platform implementation by the common interface / contract in the CA thus on any platform the dev just retrieves the particular platform implementation component by its common interface and bam easy cross-platform support w/ ease of adding more platform support on an as needed basis.

A simple shift of perspective to promoting the implicit has-a relationship as foundational and minimizing the explicit form and is-a relationship is not crazy. It's just a different approach. This is also fairly "CS 103" Cheesy material and shouldn't be strange language per se. It is a shift of perspective nonetheless though. It's true power is not realized until a significant amount of code is converted to this mechanism.

I know the "AbstractComponentManagerControl" thing may be hard to follow from a previous post as that is an implementation detail specific to my efforts, but I'll show it in psuedocode below (just a snippet mind you and not using best practices / IE never use foreach loop in near realtime bound code). It basically is an internally used component that can extend and change the behavior of the manager itself. It is what allows vetoing and encapsulation back that otherwise would be lost by the implicit has-a relationship. If you wanted to make a particular compound component final you'd first composite all the desired included components then add an ACMC that vetoes further set / unset actions.

This code is not the exciting part per se, but defines the bread and butter implicit has-a relationship. The exciting part is building a larger framework around a few essential new patterns that come from all of this.

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
41  
42  
43  
44  
45  
46  
47  
48  
49  
50  
51  
52  
53  
54  
55  
56  
57  
58  
public class ComponentManager
{
   HashMap<Class<IComponent>, IComponent>  components
   HashMap<Class<IComponent>, Collection<IComponent>>  componentCollections

   public <C extends IComponent> C getAs(Class<C> componentType)
   {
      return components != null ? components.get(componentType) : null;
   }

   public <C extends IComponent> Collection<C> getCollection(Class<C> componentType)
   {
      return componentCollections != null ? componentCollections.get(componentType) : null;
   }

   // Sets a component adding it to this component manager
  public <C extends IComponent> boolean set(Class<C> componentType, C component)
   {
      Collection<AbstractComponentManagerControl> controlCollection = componentCollections.get(
       AbstractComponentManagerControl.class);
     
      if (controlCollection != null)
      {
         // Iterate through ACMCs to perform extra control actions or potentially veto set altogether if a control returns true.
        for (AbstractComponentManagerControl control : controlCollection)
         {
             if (control.set(this, componentType, component)
             {
                // control vetoed set action
               return false;
             }
         }
      }

      return components.put(componentType, component);
   }

   public <C extends IComponent> IComponent unset(Class<C> componentType)
   {
      Collection<AbstractComponentManagerControl> controlCollection = componentCollections.get(
       AbstractComponentManagerControl.class);
     
      if (controlCollection != null)
      {
         // Iterate through ACMCs to perform extra control actions or potentially veto unset altogether if a control returns true
        for (AbstractComponentManagerControl control : controlCollection)
         {
             if (control.unset(this, componentType)
             {
                // control vetoed unset action
               return null;
             }
         }
      }

      return components.remove(componentType);
   }
}

Founder & Principal Architect; EGR Software LLC
http://www.typhonrt.org/
http://www.egrsoftware.com/
Offline Catharsis

Junior Member




EGR Software rocks!


« Reply #226 - Posted 2011-11-25 20:12:31 »

I'm kind of surprised this isn't the common understanding and am at times kind of amazed at some of the discussion in this thread and forums in general. Not to be disparaging per se, but it's like CS 101 hasn't sunk in at all.
CS 101 shouldn't be covering software engineering. That's a completely separate discipline.

I was being a little rhetorical in that statement. It's fundamental knowledge essentially and is widely recognized as a best practice in the industry.

On whether software engineering is a separate discipline I at least do not treat it as such. The left hand must know what the right hand is doing otherwise if you just want to be a brick layer and be paid less be a programmer with little responsibility. You may eventually despise your work / job when non-software engineers / architects are calling the shots and this _will_ happen at some point if you don't demand to take control of this or keep it in mind in your career path. Besides when working as an indie one does both. There is no reason why one can't be a hands on architect especially on a small to mid sized team.

As far as teaching and degree wise I absolutely think it's a tragedy that things are being separated. After the CS 101/102/103 but before the typical data structures / algorithms course software architecture / engineering should be part of the curriculum. What are data structures other than patterns of organizing data. This is accomplished through a knowledge of the "paradigm" of implementation OO or otherwise. A course on design patterns before data structures seems appropriate in my opinion.  

Founder & Principal Architect; EGR Software LLC
http://www.typhonrt.org/
http://www.egrsoftware.com/
Pages: 1 ... 6 7 [8]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

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

The first screenshot will be displayed as a thumbnail.

xsi3rr4x (37 views)
2014-04-15 18:08:23

BurntPizza (33 views)
2014-04-15 03:46:01

UprightPath (49 views)
2014-04-14 17:39:50

UprightPath (31 views)
2014-04-14 17:35:47

Porlus (48 views)
2014-04-14 15:48:38

tom_mai78101 (69 views)
2014-04-10 04:04:31

BurntPizza (129 views)
2014-04-08 23:06:04

tom_mai78101 (229 views)
2014-04-05 13:34:39

trollwarrior1 (193 views)
2014-04-04 12:06:45

CJLetsGame (200 views)
2014-04-01 02:16:10
List of Learning Resources
by SHC
2014-04-18 03:17:39

List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30
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!