As I said I just looked casually :
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)
Same here. Seems to be a great example of applets not being as shit as I thought they were! ;D
What you don’t know is that Kev’s applet placed a trojan in your system32 directory.
Cas
Hell, I assume that’s the case whenever I click the noscript button for flash. 
Anyway lemme see… ~/.wine/drive_c/windows/system32 … nope nothing there 
I am, of course, 'shitting you
But the Flash app left a permazombiecookie.
Cas
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.
Opposite behaviour on the Mac. The Java applet took the longest (although not that much longer) and its sound didn’t work.
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 : 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.
To… much… acronym… 
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
Well but I don’t do frameworkthningies so there might be a difference, not sure.
er… QED.
Cas
@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)
Ninja’d me! I’m saying the same thing, but in a more verbose manner.
I take that as a compliment
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.
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
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.
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.
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.
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.
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.
When I said best practices i really did mean “best practices ::)”
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 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.
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.
@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.