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

Junior Devvie


Medals: 3



« Reply #120 - Posted 2011-11-18 18:39:56 »

I think a 2D scene graph like structure without the need to draw by yourself would help very much. This is something I miss when casually looking at slick or libgdx.
Eh? libgdx has a 2D scene graph, you can add images and move them around without making any draw calls yourself.
As I said I just looked casually Roll Eyes thanks for making this clear! I was irritated by these calls in the tutorial
batch.begin(); sprite.draw(batch); batch.end();
So is it possible to do something like this: sprite=new Sprite(spriteBatch) stage.add(sprite); w/o ever having to think about the draw method? (sorry for ot)
Offline nsigma
« Reply #121 - Posted 2011-11-18 18:40:56 »

<edit>And DEFINITELY NO APPLETS. Applets are SHIT. End of. See Kev's latest example to get an idea of just how shit. It's dead technology - move on!
HTML5 loaded first, then Java. Flash didn't load at all, because I have a blocker. Smiley Disabling the blocker and refreshing the page though, and Java loads first every time. I guess it is just JVM start up time? Shift refresh doesn't change anything, but then maybe that doesn't touch anything cached for Java.

Same here.  Seems to be a great example of applets not being as shit as I thought they were!  Grin

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

« JGO Spiffy Duke »


Medals: 976
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #122 - Posted 2011-11-18 18:47:09 »

What you don't know is that Kev's applet placed a trojan in your system32 directory.

Cas Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline sproingie

JGO Kernel


Medals: 202



« Reply #123 - Posted 2011-11-18 18:50:40 »

What you don't know is that Kev's applet placed a trojan in your system32 directory.

Hell, I assume that's the case whenever I click the noscript button for flash. Tongue

Anyway lemme see.... ~/.wine/drive_c/windows/system32 ... nope nothing there Wink
Offline princec

« JGO Spiffy Duke »


Medals: 976
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #124 - Posted 2011-11-18 18:52:01 »

I am, of course, 'shitting you Wink
But the Flash app left a permazombiecookie.

Cas Smiley

Online kappa
« League of Dukes »

JGO Kernel


Medals: 119
Projects: 15


★★★★★


« Reply #125 - Posted 2011-11-18 19:26:13 »

Apart from the initial java loading screen (which can be changed), I also thought the applet ran the best out of the three, they've come a long way from the crashing frozen gray things from a few years back.
Offline loom_weaver

JGO Coder


Medals: 17



« Reply #126 - Posted 2011-11-18 20:37:58 »

Opposite behaviour on the Mac.  The Java applet took the longest (although not that much longer) and its sound didn't work.
Offline Catharsis

JGO Ninja


Medals: 73
Projects: 1
Exp: 21 years


TyphonRT rocks!


« Reply #127 - Posted 2011-11-20 23:25:03 »

>Firstly, this obsession with entity systems is the pustulent boil of a symptom which I used to call "object oriented wank".

Hah.. So I am late to the party on this one and mobile, so I don't have the quotes I yanked yesterday, but since I've been around here for ~9+ years _without_ releasing some code I suppose I'm obligated to chime in; by the time I do release my efforts which I'm squarely trying to get fully live / public by Q2 '12 w/ early access opening up to a wider audience in a month or so I'll have put in 12k hours min ~15k hours max  Roll Eyes I'm likely the biggest "offender" on JGO. While yes this forum is game dev oriented keep in mind this is also one of the few places where performance Java is discussed online. Not everyone is doing simple (but polished!) 2D games Cas. You are right in that you can stick with the same old approach you've done for years and keep it OOP for your particular case, but that is a limited case. Should beginner and intermediate devs do this; well actually, yes they should get a handle on essential OO dev.

For the longest time until the arrival of Android I couldn't really justify any ROI releasing a desktop only framework. My efforts for quite some time were focused on spatial audio, building a studio for it which took years (& $$$ that game dev would not provide), prototyping hardware and the Java software framework I created initially was for network / OSC (Open Sound Control) control of external hardware software & fast 2D / 3D GUIs. Basically due to long term funding concerns I had time to muck about with software and architecture experiments. While I dabbled in 3D efforts to learn GL via a Q3 class level renderer I also used it to send / control external spatial audio systems (via SuperCollider). It only was until Android came out and I jumped on it Oct '08 when the G1 hit my hands that potential ROI appeared for releasing a cross-platform client oriented framework for app & custom hardware dev (I'm working on a custom DSP box running Android). I already played around the the Danger SDK / Sidekick3 doing some porting work of my efforts back in '06, so I knew things were legit with Android.

I'm one of those "architecture wonks" though and went on a long path of refining my code base into ever increasing modularity. First mostly through OOP, but it broke down eventually and I turned to component architectures; COP (component oriented programming). Component oriented Entity Systems (ES) are just a special case of COP. I hardly think the handful of folks on this board who have examined and created their own prototype ES systems are / were wasting time. modularity is architecture. There are plenty of advanced language techniques one utilizes in COP and that alone improves the devs expertise.

I could have released a more OO oriented effort April '09 when I got everything ported over to Android, but realized the OO approach is even further flawed when trying to treat the Android ecosystem holistically and creating well written software that runs across the ecosystem. I jumped whole hog into component architectures at this point. It should be painfully obvious to most that the old school (just like your penchant for OOP) approach of tying the Android SDK to firmware and additively releasing new APIs was going to cause havoc. Even API level 1 -> 2 -> 3 it was painfully clear what was to come. Android is fully capable of advanced games and such. It doesn't create limitations on devs that will help them ship a quality game as Cas recommended. If anything there is a complexity / scope expansion if the dev wants to target more than a handful of devices w/ many pitfalls at each OS / API level to work around.  

And of course the SDK itself is OO derived. I could make a whole post about how the Fragment API addition is a botched example of OO dev where a short cut was taken at the total expense of future app / activity control flow modifications; IE they loaded the shotgun and aimed it at their knees. In my efforts I'll be able to supply Fragment API support as a component addition that can be enabled / disabled and work back to API level 3 (I'm pulling the main implementation from the compatibility API). Like I mentioned though I can expand on this for a whole post on a potential failure of OO and dirty implementation of a new Android API; where expedience of implementation won out over future maintenance concerns.

Anyway.. I'm one of those grand vision kind of folks and am creating a real time app / game dev client runtime / SDK that can be configured across J2SE & all of Android. Being able to create specially tuned runtime distributions for different vertical app categories or even running on custom hardware is important to me. Heck I want my stuff running satellites in space one day soon. None of this happens over night and I knew way back when I was in this for the long haul. My spatial audio / hardware focus alone indicated this was going to be my life's work and go on for years. I'm very happy that I can finally spin off a software product from all of this as it has way more ROI than custom / niche spatial audio hardware w/ small margins. I do plan to get back to the DSP hardware in the coming years especially now that I have the R&D media facility.

Back to COP and such. Yes.. Indeed my final push into component architectures has been a long and arduous one especially in refining and constantly refactoring a significant OO framework (~150k SLOC) into a very granular component oriented one. This has consumed most of my last 2 years of dev. Thank goodness when it's done it's done as it's a laborious and mind bending process. There are little performance downsides BTW; only amazing flexibility in runtime APIs offered and ability to run on practically any Java based environment.  I dunno... When the scope is limited OOP will do OK and be expedient.

I don't think anyone working with ES here at JGO are limiting the output of Java games. I'm considering for my next big demo to create a cross-platform renderer for the Grome level editor and COP + ES are not going to hold me back. To each their own I suppose. I think there is just as much chance for one of the JGO "architecture wonks" to make it big. New ideas though take longer to germinate. I know I'm a way better developer / architect because of my chosen path. I love coding and architecture and am passionate about "doing it right" and exploring new ways of doing things if the old doesn't pass muster. I finally found an approach to Java after 15 years that I'm truly happy with that make the grand vision possible. This approach will play nicely and work well with JVM languages and the next 10+ years of dev efforts. Now code code code and mmm... can't wait for it to get out now.

Check out the TyphonRT Video Suite:
http://www.typhonvideo.com/

Founder & Principal Architect; TyphonRT, Inc.
http://www.typhonrt.org/
http://www.egrsoftware.com/
https://plus.google.com/u/0/+MichaelLeahy/
Offline R.D.

Senior Devvie


Medals: 2
Projects: 1


"For the last time, Hats ARE Awesome"


« Reply #128 - Posted 2011-11-21 01:01:51 »

To... much.. acronym... Cheesy
I had to google half of your post to understand it. But if I'am correct it took you years to find a way to do something? Well that's pretty hardcore imho. Maybe it's because I'm not that familiar with all the Software Engineering and Software Quality (had courses in college but meh xD) but if I'm doing something it always goes like this: have to implement something -> think about ways to do it -> choosing the one which is the easiest to implement -> does what I want? (if no, back to think about ways to do it) -> keep it! That works just perfect because often the easiest way is the best way. I sometimes even implement a feature hacky since I always think that the consumer does not care how it works Smiley

Well but I don't do frameworkthningies so there might be a difference, not sure.
Offline princec

« JGO Spiffy Duke »


Medals: 976
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #129 - Posted 2011-11-21 09:23:15 »

er... QED.

Cas Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Roquen

JGO Kernel


Medals: 516



« Reply #130 - Posted 2011-11-21 09:23:28 »

@Catharsis - First off, let me say I hope your system works really well for all the effort you put into it.  But your commentary, to me, makes a very strong argument against this direction.  The entity framework of a game is pretty unimportant (99% of the time) in the grand scheme of things.  Outside of games, the original point of component based was to make easier to build and maintain software.  And this certainly can be the case.  But, again, Java is not a friendly language for building these kinds of systems.  Even a trivial change, like the addition of get/set sugar, would go a long way to making it slightly less painful.  Be that as it may, if one takes steps back and thinks about class-based OO, prototype based OO and data driven design in general, then couple those with the design needs of supporting game objects, then there are tons of easier solutions possible even if one needs a great deal of flexibility.  If one really "needs" uber-flexibility then it's pretty much given that a scripting language will be part of the system, and if that is the case then choose a scripting language that provides the desired features and code the entity system in the DSL.  This is a task that a would take a moderately skilled programmer something like 1-day to 1-week.

(edit)
Quote
er... QED.
Ninja'd me!  I'm saying the same thing, but in a more verbose manner.
Offline R.D.

Senior Devvie


Medals: 2
Projects: 1


"For the last time, Hats ARE Awesome"


« Reply #131 - Posted 2011-11-21 12:37:12 »

er... QED.

Cas Smiley

I take that as a compliment Cheesy
Offline delt0r

JGO Wizard


Medals: 139
Exp: 18 years


Computers can do that?


« Reply #132 - Posted 2011-11-21 12:51:21 »

Sorta read everything above.

I came to similar conclusions to Cas about 4 weeks ago. The biggest feature missing from my game is finishing. Honestly what does it matter how good it could be when its not finished! Or even worse, not even playable.

I think the entities or OO is a red herring. Its kinda Meh. OO or functional? Scala or java? I do think that composition solves a different problem than OO and both can be useful tools. In particular over design is always a bit of a problem when you don't have to retool a production line to "just add this little thing".

Anyway I though i would share briefly my last weekends experience and experiment. The goal was to start a prototype of the game idea have had for some time(brutally cut down RTS--so much so some won't call it an RTS anymore). By "started" I wanted to have basic units movement with mouse controls and network play. I got there at about 1am last night. Now that is not finished. But i really did learn a lot about what was wrong with my last attempts.     

An example is the network code. In my original unfinished, unplayable RTS, the network code is about 3000 lines of code and about 6 classes. My new network code does everything that the original does wrt to the game and is *only* 150 lines long! Sure i don't have nth level abstraction or plug-able authentication or encryption or whatever. But i can play my game in some sense over the internet right now! So what the hell was i thinking in the first place with the original code. Some of it is scope creep. This is even easier when there is no scope in the first place. Most of the problem is simply forgetting what the problem i am trying to solve in the first place is. I am trying to write a game... not a general purpose highly scalable network thing.

Focusing on playable is how i am going to try to avoid this in the future. Now i have something playable, not fun, but playable. Each milestone goes from playable state to playable state. If i refactor the netcode... at the end of that its playable again, I don't start refactoring the unit system before then. This way i avoid solving problems that i don't need  to solve. Well thats the idea.

Also it feels great to have something you can play at the end of the day...

I wish to have this game finished by March.  Needless to say that the prototype will be become the game if it goes as planed.

And don't be afraid to hack. Breaking a few best practices every now and then won't kill you. It may just save you a week of coding.

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

« JGO Spiffy Duke »


Medals: 976
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #133 - Posted 2011-11-21 13:24:40 »

You could even arch an eyebrow at the mere use of the word "best" in the phrase "best practises".

Best for who or what exactly? And says who? And proved how? And when? Has the landscape, perhaps, changed rather significantly in the last 20 years?

Cas Smiley

Offline theagentd
« Reply #134 - Posted 2011-11-21 13:37:42 »

If "best practices" takes me weeks to code and doesn't work any better than my quickly hacked together solution, then it obviously isn't the best solution, and therefore neither best practices in my book.

Myomyomyo.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #135 - Posted 2011-11-21 14:14:26 »

@Catharsis - First off, let me say I hope your system works really well for all the effort you put into it.  But your commentary, to me, makes a very strong argument against this direction.

Let's be clear: his "direction" is:
  
   "Try everything, to the max, find its flaws and its shininess. If it is less than perfect, move on to the next thing. Time and money are no issue"

That's how Catharsis works. He has always worked that way - he was doing it 5 years before ES's were even mentioned.

Quote
Java is not a friendly language for building these kinds of systems.

Should you really care, though? The point of the ES is not

   "how easy is it to write my own ES from scratch, ignoring all the public domain and open-source versions"

it's:

   "how easy  does the ES make it for me to write my own game from scratch, creating something new"

So long as people are unwilling to write Games, and instead focus on writing Engines and Libraries, there will continue to be a lack of Games.

Quote
Even a trivial change, like the addition of get/set sugar, would go a long way to making it slightly less painful.

The grass is always greener... I've written multiple implementations in Java, C, and Objective-C. Java is not the worst.

e.g. I spent a whole day last week trying to make this work in Objective-C++ (for a nice iOS ES). After a day, all I had was:
 - Damn, this is hard
 - Templates in C++ aren't quite powerful enough to do this easily, unless you can use a C00x compiler (which iOS doesn't)
 - ...Damn, this is hard.

I'm still trying to work out how to do it. A trivial implementation, that is worse than the Java one, was easy. But to make a small implementation that's "at least as good as the Java one" is proving difficult.

Quote
it's pretty much given that a scripting language will be part of the system

Or ... not. Scripting langauges are often over-rated in games-dev. Unless you've spent a lot of time with maintaining them in a live game, it's easy to read the literature and think they're "pure benefit". In practice, they bring with them a LOT of new problems, really nasty stuff in the long-run.

EDIT: and I'd like to hilight that - for me - spending "a whole day" on something is an incredibly long amount of time. Catharsis would probably say it doesn't even count as getting started - but for me, if something can't be completely done in a day, my gut reaction is: don't do it at all - move on, do something else, do something that can be finished quickly.

malloc will be first against the wall when the revolution comes...
Offline delt0r

JGO Wizard


Medals: 139
Exp: 18 years


Computers can do that?


« Reply #136 - Posted 2011-11-21 14:34:28 »

When I said best practices i really did mean "best practices Roll Eyes"

Of course I don't mean write sloppy code. But lets be honest here... we are writing or at least trying to write games. Not nuclear power plant software.

I have no special talents. I am only passionately curious.--Albert Einstein
Offline avm1979
« Reply #137 - Posted 2011-11-21 20:09:19 »

You could even arch an eyebrow at the mere use of the word "best" in the phrase "best practises".

Best for who or what exactly? And says who? And proved how? And when? Has the landscape, perhaps, changed rather significantly in the last 20 years?

Cas Smiley

I think the main change is in the quality of IDEs. Standard "best practices" are largely about future-proofing of some sort - maintenance, adding new features, writing more robust code, etc. Given how easy code navigation, debugging, and refactoring are now, most of that is completely moot.

Offline sproingie

JGO Kernel


Medals: 202



« Reply #138 - Posted 2011-11-21 21:04:45 »

When pastebins and email and chat all have code navigation, debugging, and refactoring built in, then maybe it'll be a little more moot.  Til then, most IDEs don't really do much in the way of collaboration, and coding standards will still be quite important.  I know there are chat features in some IDEs that do integrate into the IDE, but they're not often used for a number of reasons.

Even if every collab tool is on board with instant refactorings and navigation, you still have to enforce some standards, some of which may strike you as common sense, but they are still "best practices".  For example, if I see IdentifierName, I immediately think "type" (class or interface).  I see IDENTIFIER_NAME, I think constant or enum, not a mutable field.   And so on.

And no amount of IDE support can fix badly structured code, so there are design standards as well, and those have become no less important.

Offline delt0r

JGO Wizard


Medals: 139
Exp: 18 years


Computers can do that?


« Reply #139 - Posted 2011-11-21 21:25:00 »

@sproingie  I really mean things like excessive use of patterns for no other reason than patterns are best practice. Or using massive DI frameworks for a app that really only needs a 100 lines of plain old java code for the glue. Or adding massive amounts of "error" checking and recovery when catching the exception and logging it is all that is needed. At least at the start.

Examples are things like letting a class have a public access  to a variable that perhaps shouldn't because it will solve a problem without a refactor. I mean what a friend functions other than a way to cheat in C++? Sometimes i want to add a annotation that only once class in particular should call a method. I have been told then it shouldn't be public... well its still the easiest way to get it done, and done now, not later.

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

JGO Coder


Medals: 1


http://t-machine.org


« Reply #140 - Posted 2011-11-22 02:50:37 »

Sometimes i want to add a annotation that only once class in particular should call a method. I have been told then it shouldn't be public... well its still the easiest way to get it done, and done now, not later.

Does anyone seriously argue that Java 1 got it right with the private/protected/public keywords? Some of the most common use-cases for encapsulation were "forgotten" by the original spec, and never fixed.

(speaking as a C programmer who came to Java, and was surprised that a *known problem* with encapsulation being done "too little" had somehow slipped through the cracks with Java)

malloc will be first against the wall when the revolution comes...
Offline Gudradain
« Reply #141 - Posted 2011-11-22 04:45:48 »

Sometimes i want to add a annotation that only once class in particular should call a method. I have been told then it shouldn't be public... well its still the easiest way to get it done, and done now, not later.

Does anyone seriously argue that Java 1 got it right with the private/protected/public keywords? Some of the most common use-cases for encapsulation were "forgotten" by the original spec, and never fixed.

(speaking as a C programmer who came to Java, and was surprised that a *known problem* with encapsulation being done "too little" had somehow slipped through the cracks with Java)

Yeah I agree that I often want to do something like that : a method is private for everything except one class and when you try to do it it becomes a pain in the ass to design the structure of your code....

So the good solution is indeed to make it public. Doing so is contradictory with the mentality of always putting the lowest visibility possible but you are so much efficient to code since you can access everything you want. Well it can become a mess later on but who care? Make a nice interface over that part of the code and call it done Smiley
Offline Chromanoid

Junior Devvie


Medals: 3



« Reply #142 - Posted 2011-11-22 09:09:04 »


 Grin
[size=8pt](via #AltDevBlogADay)[/size]
Offline theagentd
« Reply #143 - Posted 2011-11-22 09:46:55 »

@Chromanoid
Touché.

Myomyomyo.
Offline princec

« JGO Spiffy Duke »


Medals: 976
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #144 - Posted 2011-11-22 10:10:09 »

The whole notion of encapsulation has proved to be a complete waste of time over the last 20 years anyway. Of course I care about how something's implemented! I might want to bloody change it, whether I wrote it or not. Or even debug it. Ridiculous.

Cas Smiley

Offline appel

JGO Wizard


Medals: 80
Projects: 4


I always win!


« Reply #145 - Posted 2011-11-22 13:36:09 »

I don't think it's just the 4096 bytes limit that makes 4k contest so "productive", of course it's a big reason because it forces all sorts of other restrictions, but also the programmer is really in practice limited to just one class, and has to bundle all his code in this one class, and structure somehow. One class means you have a "perfect" overview over the game code, and won't dwell on anything "wasteful" like entity systems or setting up your game code "properly", which seems to be very subjective.

I'm pretty sure if you had a contest where 1) programmer is limited to just one class and 2) has to deliver in 48 hours 3) no bytes limit, you'd get something similar to 4k games.

4k limit may not be the best restriction, because you may have a good finished game running, but it's larger than 4096 bytes, so you start cutting down gameplay that's already there. A necessary evil I think, because if the limit was 8k, well, no games would ever be submitted because programmers would never finish any games Smiley

But, we don't have the self-discipline to prototype games, 4k forces that discipline upon us, even if that's not the best way it still works.
Offline Damocles
« Reply #146 - Posted 2011-11-22 15:03:24 »

Well said appel,

Creativity/Productivity through limitation.

Whats important is, that when making a 4k game, early working results are forced in.
(Also simply to check the resources they use), thus it speeds up the important phase of getting the prototype working.

With the limitations, formalizing, generalizing and blowing up the prototype are a nogo. It rather gets more simplified.
 This pushes the development speed a lot.

Offline cylab

JGO Kernel


Medals: 173



« Reply #147 - Posted 2011-11-22 15:13:05 »

I'm pretty sure if you had a contest where 1) programmer is limited to just one class and 2) has to deliver in 48 hours 3) no bytes limit, you'd get something similar to 4k games.

That basically says: "Do a game without any (OO-) software design" Shocked
or "Do game design instead" Wink

Mathias - I Know What [you] Did Last Summer!
Offline princec

« JGO Spiffy Duke »


Medals: 976
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #148 - Posted 2011-11-22 15:15:52 »

It has to be said I don't do OO design, I still hack away merrily. It's just that using a few of the constructs in OO helps my tiny brain work faster. I'm hoping the 16k compo will at least allow people to relax enough to use a few more methods and classes and code a little bit more "normally" with less of an eye on shaving bytes everywhere. Of course it will probably end up that way eventually anyway Smiley

Cas Smiley

Offline Catharsis

JGO Ninja


Medals: 73
Projects: 1
Exp: 21 years


TyphonRT rocks!


« Reply #149 - Posted 2011-11-22 15:34:35 »

The whole notion of encapsulation has proved to be a complete waste of time over the last 20 years anyway. Of course I care about how something's implemented! I might want to bloody change it, whether I wrote it or not. Or even debug it. Ridiculous.

Eh heh heh.. So now you are implicitly for composition declaratively or otherwise / component architectures (CA) / entity systems (ES) as this is exactly what the "has a" relationship addresses. Your complaint is a valid one against OOP as "is a" encapsulation doesn't lead to easy code reuse, maintenance, or modification and is precisely why I moved on from that sinking ship.

As Java is an OO language through and through you can't stop anyone from using "is a" inheritance / encapsulation, but through careful construction of the CA one can force this to the leaves and prevent it overtaking the core at least as the central organizational construct.

Encapsulation as a concept in and of itself is not the enemy. I've mentioned this before, but in my particular efforts one can still achieve refined encapsulation by adding an internal control system component (AbstractComponentManagerControl / ACMC) to a component manager (may be an entity or whatever) that may veto or transform components or systems added / removed. If this control vetoes all additions / removals you just made that component manager final, etc. Want to change how it works then compose the component manager / entity with a different ACMC and series of components / systems. Potentially you may achieve your modification through composition (very quick) or you'll be able to just modify the smallest amount of components necessary to realize the change then swap out the offending ones. This also aids in debugging as with declarative composition w/ a little control flow especially on Android being able to filter with device and family names one could branch and load the old and new composition on two different devices testing both at the same time, but on different devices from one build.

Folks should realize that creating a CA and validating its performance characteristics for near real time usage is a difficult task. In my case the ES part is just an extension of a more generalized CA. Since my effort is a runtime middleware layer converting and granularly separating this runtime from its prior OOP configuration so that it runs well over J2SE, Android, <fill in next Java environment / GL binding / etc> is what has taken 99.5% of the time. Not everyone should create their own CA, but those who do will also become better developers and fully use and understand all the advanced language constructs of Java 5.

Conceivably using a well constructed CA / ES once one wraps their head around it and understands how things work together makes coding and prototyping faster and efficient in addition to flexibility through the entire design and implementation process to make quick changes vs massive refactoring.

Ack now to respond to all the good comments since my last post... erg.. will take a bit, but I'm on it... My initial verbosity was due to being on a plane with free provided chrome book and wifi... This next one due to good / interesting comments on the forums!  Cheesy


Edit: I suppose to make things more clear as of course in OO design the "has a" relationship is available as any member field fits this description. What component oriented programming in an OO language like Java changes from normal OO is that the "has a" relationship becomes implicit rather than explicit for component managers, entities, etc.

Check out the TyphonRT Video Suite:
http://www.typhonvideo.com/

Founder & Principal Architect; TyphonRT, Inc.
http://www.typhonrt.org/
http://www.egrsoftware.com/
https://plus.google.com/u/0/+MichaelLeahy/
Pages: 1 ... 3 4 [5] 6 7 8
  ignore  |  Print  
 
 

 
Ecumene (112 views)
2017-09-30 02:57:34

theagentd (147 views)
2017-09-26 18:23:31

cybrmynd (245 views)
2017-08-02 12:28:51

cybrmynd (241 views)
2017-08-02 12:19:43

cybrmynd (241 views)
2017-08-02 12:18:09

Sralse (255 views)
2017-07-25 17:13:48

Archive (874 views)
2017-04-27 17:45:51

buddyBro (1025 views)
2017-04-05 03:38:00

CopyableCougar4 (1578 views)
2017-03-24 15:39:42

theagentd (1376 views)
2017-03-24 15:32:08
List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05

SF/X Libraries
by SkyAphid
2017-03-02 06:38:56

SF/X Libraries
by SkyAphid
2017-03-02 06:38:32

SF/X Libraries
by SkyAphid
2017-03-02 06:38:05

SF/X Libraries
by SkyAphid
2017-03-02 06:37:51
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!