Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (542)
Games in Android Showcase (133)
games submitted by our members
Games in WIP (604)
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 4
  ignore  |  Print  
  Game Object Component System  (Read 26461 times)
0 Members and 1 Guest are viewing this topic.
Offline ewjordan

Junior Devvie





« Reply #30 - Posted 2009-06-05 12:36:31 »

This is a nice enough article:

Evolve Your Hierarchy 
http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/
Thank you for the explanation and link, I was certain I'd heard the term somewhere before but couldn't remember where - turns out it was that article.

I guess I'd question whether or not this type of thing is necessary for smaller games.  For AAA stuff where you might have thousands of different types of "thing" in your world, the constraints are very different, and one of the most important things is to be able to make sure that the designers can create new "things" without consulting with the programmers at all.  Components will facilitate that much better than inheritance, definitely.

I'd guess that for most of the types of games people are working on here, the complexity threshold where it matters is never crossed.  As mentioned in that link, the problem that component systems are intended to solve is the so-called "blob anti-pattern," where you end up with a very unbalanced inheritance hierarchy, with too much functionality either a) living in the root of the tree, or b) copy-pasted to the leaves as needed.  Unless you're seeing that happen, or designing a system large enough where it's to be expected eventually (RPG or virtual world or something like that), I don't know that the effort spent avoiding typical OO stuff is going to really pay off.

I'd leave it to a matter of taste, though.  There are situations where I could see something like this being appropriate.

Anyone ever implemented something like this before?  I didn't really see any specifics, and I don't have access to that Game Programming Gems article.
Offline princec

« JGO Spiffy Duke »


Medals: 439
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #31 - Posted 2009-06-05 12:43:48 »

You'll probably never have thousands of different types of thing though, not even in AAA games. I hate OOP sometimes. It breeds this sort of programming brain-freeze.

Cas Smiley

Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 849
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #32 - Posted 2009-06-05 13:10:32 »

Have you read the article? It is certainly an improvement over their previous design, which was based on inheritance.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

« JGO Spiffy Duke »


Medals: 439
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #33 - Posted 2009-06-05 13:32:23 »

The article's not all that great at giving any concrete evidence of tangible benefits. The number of entity types he's got in the example there isn't even half the size of what's in Alien Flux. All that wasted time refactoring and introducing new bugs for what benefit? Bugger all as far as I can see. The thing is, they didn't really have a problem to begin with. I see this a lot with software engineers. They just like to fiddle around with the "elegance" of the code for weeks on end trying to make it "feel pretty", often because they can't be arsed to bite the bullet and type a bit of code twice. In the end progress is ultimately usually slower and the end result is usually just as complicated, if not more so.

That's not to say that composition isn't a completely valid way of doing things - but really, you need a bit of smart thinking and use both techniques. In Alien Flux for example, the movement of some aliens is factored out into a separate class so it could be reused in lots of different aliens but without having to try and inherit from some alien type that moved in a particular way. But there's still a 4-deep hierarchy in there.

Cas Smiley

Offline ewjordan

Junior Devvie





« Reply #34 - Posted 2009-06-05 13:59:22 »

You'll probably never have thousands of different types of thing though, not even in AAA games. I hate OOP sometimes. It breeds this sort of programming brain-freeze.
I'm right there with you, I have no particular love for OOP in general (or at least for the crippled approximation of OOP that Java allows), for exactly this reason - way too much effort is spent thinking about and implementing (not to mention talking about Smiley ) patterns to achieve what might take one line in a language with just a little more power, and oftentimes all this work only benefits the "OO-ness" of the overall design and makes the programmer feel like he's doing "the right thing."  In a scripting or functional language the problem that this is trying to solve would never have been a problem in the first place.

I don't know whether or not this approach helped the Tony Hawk team or not; I'm hesitant to disregard the claim, because the author appears to have a good amount of experience and I'd like to think that he wouldn't claim tangible benefits if they weren't there, but you're absolutely right that the article lacks real detail.  It does strike me as a little odd that a skating game would have the type of object proliferation where this would be necessary; if this was WoW, I'd understand it in a heartbeat.  The one tangible benefit I can see is that non-programmers can now design new objects without passing requests to the programming team, but there are a million ways to achieve that, so I don't know that this is the best.

I still think it's moot for the rest of us, though - if I ever notice the "blob anti-pattern" in my code and it starts to cause problems, I'll keep this in the back of my mind as a potential solution, but thus far it hasn't been an issue, and I don't have a hundred person team working on any projects with me, so decoupling design from programming is not an issue I have to contend with.

Also, I'm still a bit unclear, so let me ask again: isn't this just the properties pattern, rediscovered and given a new name?
Offline appel

JGO Wizard


Medals: 69
Projects: 4


I always win!


« Reply #35 - Posted 2009-06-05 14:40:38 »

I also see a future benefit from using a component based game object system, whereas you can reuse components between games. Not only are the components entity-independent within the same game but they are game-independent.

You could easily create a library containing a set of standard components, and people could get their games going with fully functional game objects in a heartbeat. All they need to do is to define certain parameters in a XML file. If they need more, they can easily extend some component or create a totally new one. Honestly, I'm getting a bit tired of writing that darn Movement and Shooting functionality over and over again Smiley

My short experience with the component system (compared to the entity-inheritance way) is that there are almost no obstacles, no programmers-block when you get stuck on "hm, should MovementEntity inherit from ShootingEntity or reversed?".

Yes, it requires a little more time to create the system, but eventually it will lead to much more productive and enjoyable game programming.


I don't really know what the debate is here. Is it OOP vs. procedural? Wasn't that settled back in the 20th century? Over-designing vs. working asap? It all depends on what you're doing, of course. Let's not forget that this is JavaGaming.org, so pointing to another language that can do the trick just for "winning" the argument doesn't count.

Check out the 4K competition @ www.java4k.com
Check out GAMADU (my own site) @ http://gamadu.com/
Offline ewjordan

Junior Devvie





« Reply #36 - Posted 2009-06-05 15:12:40 »

I don't really know what the debate is here. Is it OOP vs. procedural? Wasn't that settled back in the 20th century? Over-designing vs. working asap?
I'm not entirely sure, to be honest.  I think it's something along the lines of "Is there actually a problem here in need of a solution?"  My answer: maybe, depending on what you're doing.  I get the sense that Cas thinks it's more a solution in need of a problem.

Re: programming paradigm, no, it's not (IMO) between OOP vs. procedural, I'd personally argue that the sweet spot is OOP with the ability to dip into functional style when you need to (which is why I like Scala).  Nouns should be nouns, verbs should be verbs, and we shouldn't try to pretend otherwise if we can help it.  But I wouldn't go all the way towards functional zealotry - I think state can be very useful, and a lot of the efforts to create state-free code in languages like Haskell end up massively convoluted, in the same way that overly designed OO can be ridiculous.

Quote
Let's not forget that this is JavaGaming.org, so pointing to another language that can do the trick just for "winning" the argument doesn't count.
Hehe, fair enough. Smiley

I'd still suggest that Scala integrates well enough with Java that it's worth checking out, though, especially if you're feeling a lot of pain over not being able to have implementations in your interfaces. (/plug)
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #37 - Posted 2009-06-05 15:55:56 »

I don't know whether or not this approach helped the Tony Hawk team or not; I'm hesitant to disregard the claim, because the author appears to have a good amount of experience and I'd like to think that he wouldn't claim tangible benefits if they weren't there, but you're absolutely right that the article lacks real detail.  It does strike me as a little odd that a skating game would have the type of object proliferation where this would be necessary

I suspect that the people on the "I don't get it" camp don't appreciate the complexity that the component system is trying to solve. I don't think it's unfair to say that most of the games worked on here are very simple compared to something like Tony Hawk. A rendering component for a simple j2d game might be a single draw() call, which will obviously leave you thinking that the whole thing is an over-engineered waste of time. It becomes trivial to just rewrite the draw call in every object that needs it. But when your rendering component is setting up multiple models, skins and animations and has to work across three different console platforms then you really don't want to be duplicating that for every object. The same applies for physics, animation, sound, scripting, etc. etc.

To a certain extent you can push that duplication into helper classes but you'll still end up with a lot of error-prone boilerplate to stick things together, and without the snap-together approach of components any new entity will likely require a certain amount of tweeking of exiting helper code to make it suitable for re-use.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline cylab

JGO Ninja


Medals: 56



« Reply #38 - Posted 2009-06-05 16:03:57 »

They just like to fiddle around with the "elegance" of the code for weeks on end trying to make it "feel pretty", often because they can't be arsed to bite the bullet and type a bit of code twice.

Some like to get something done fast, some others like to develop abstractions and patterns. So what? (I now the latter type rarely get anything done in their free time, but it's a hobby anyway...)

In the end progress is ultimately usually slower and the end result is usually just as complicated, if not more so.

As long as it "feels" pretty, I am happy Wink

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

JGO Wizard


Medals: 69
Projects: 4


I always win!


« Reply #39 - Posted 2009-06-07 02:33:01 »

Here are great articles from this guy Adam Martin at T=Machines.

He calls his system a Entity System. It's similar to what we've discussed here, but goes much further. It's more oriented for MMOG games. Gives me some good ideas.

Entity Systems are the future of MMOG development
http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/

Check out the 4K competition @ www.java4k.com
Check out GAMADU (my own site) @ http://gamadu.com/
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline thalador

Senior Newbie





« Reply #40 - Posted 2009-06-07 11:23:30 »

There are also two very insightful discussions over at gamedev.net:
Offline tom
« Reply #41 - Posted 2009-06-07 19:11:19 »

I'm working on a simple "game" engine at work. It will not be used to create games, but training scenarios. So workers can train on procedures in a power plant. I've been looking at Unity3D and Blade3D for inspiration and they both use a Component System. I recommend trying out Unity to see how it works. It has a 30 day trial version. The documentation is also available on the net. Here is the part about GameObjects and Components:
http://unity3d.com/support/documentation/Manual/Building%20Scenes.html

I did not know about the "Game Object Component System" before reading this thread. Has given me something to think about Smiley I'll probably go for a "Components with methods" rather than "Components as pure data". I guess I'm too stuck in the OO way of thinking.

Some random thoughts. Components need to talk to each other. There is no need to abstract this interaction away using the observer pattern. Either use direct references if the target don't change, or do a query whenever needed. A component should be able to get hold of and use any other component or GameObject. Setting up the references could be done when the level loads. An example is a LookAt component. In the editor you could add the LookAt component to a camera. The LookAt component should have a target property that you set threw the ui. Of course you could specify this information in the xml file if you don't have an editor.

Scripting lends it self very well to the Component System. A script is simply a Component. You could implement a 3'rd person camera using a script. This script Component would require that the GameObject also has a Camera and Transform component. Reference to the other components would be found when the components are initialized and cached for later use. The script would also need a target. This could be done in the editor ui or the script could search the world for the Player GameObject when it was initialized.

I'm still thinking about how to integrate the components with the scene graph. A Transform component would have a matrix and a parent. A Model component would have the visual representation. But should the component or a Manager class attach the GameObject to the scenegraph?

Offline appel

JGO Wizard


Medals: 69
Projects: 4


I always win!


« Reply #42 - Posted 2009-06-09 22:16:22 »

I'm still thinking about how to integrate the components with the scene graph. A Transform component would have a matrix and a parent. A Model component would have the visual representation. But should the component or a Manager class attach the GameObject to the scenegraph?

This is what I've been thinking about for some time now.

I've been thinking of creating something like a NodeComponent, which does not much but to store a list of children gameobjects. The NodeComponent needs to be attached to a gameobject to enable it to become a parent.

Another way is to simply attach gameobjects to other gameobjects. The problem with that solution is that ALL gameobjects would need to have it's own List object. This creates a big overhead needlessly, especially when you might have hundreds of gameobjects and hundreds of bullets flying around, each requiring a List. (There is also some consensus that the gameobject should really be nothing but a GUID (global unique id) in the game world, and not "contain" anything, just be attached to components.) So let's forget about this idea!


The NodeComponent needs to be explicitly attached to a gameobject so it can contain child gameobjects.

And now regarding the local/world translation and rotation problem.
The NodeComponent should ensure that children gameobjects have the world translation and rotation, so they don't need to look them up or calculate them. The gameobjects should be oblivious to the fact they are attached to another gameobject (via NodeComponent), so the NodeComponent needs to recalculate the translation and rotation, and set it, for each gameobject before they are updated and rendered.

Check out the 4K competition @ www.java4k.com
Check out GAMADU (my own site) @ http://gamadu.com/
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #43 - Posted 2009-06-13 17:30:49 »

Cas (and others perhaps - but Cas was most vocal and made the easiest-to-refute claims Wink), I don't think you're seeing the whole picture here. Multiple inheritance helps "not at all" for entity systems. Generally speaking, all OOP features/variatns help very little with ES's - until/unless you want to use it *internally* inside a method implementation because the method itself is so vast that it needs splitting down using something - and we are all well aware of how good OOP is at doing that.

IMHO, within 20 years, ES's will be used for almost all mainstream programming. OOP is poor paradigm for real-world projects, it always has been - it only started as a desperate attempt to improve on a language where fundamental language constructs were based on "what would be easiest to compile into assembler" rather than "what would make programs better" or "what would make software development better" etc. OOP was a nice-stopgap, and it will always remain useful as a way for breaking down large pieces of complex contiguous code into an easier-to-manage low-level code. But it sucks for application writing - we just don't work this way.

Bigger problem, which is the real reason I suspect ES's will eclipse OOP, is that OOP is the antichrist of SQL - and there's literally nothign you can do to change that (unless you win a nobel prize for mathematics by solving stuff that mathematicians and computer scientists have so far been unable to). Our world relies more and more on data. Have a look at the "data" languages: they're all functional (SQL, XSLT, etc), and OOP can't do functional. Even if you think the world will stop becoming more and more data-centric, just look how much data is already stored in SQL. New data, simple data, stuff that's done by intermediate programmrs like us ... well, it may not all be going into SQL too (although HSQLDB et al are making inroads on that - Firefox uses SQL internally, the iPhone provides local SQL as a core service to programmers, etc), but most that isn't, that's going into "something more modern", is going into... XML. For which the primary interaction language is XSLT. And so it goes on...

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

« JGO Spiffy Duke »


Medals: 439
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #44 - Posted 2009-06-13 21:09:10 »

I never thought OOP helped a massive amount for entity systems particularly. But my point is that the "big" picture is actually nearly always, in fact, a very "small" picture and people just like to overcomplexify and overengineer everything and never get anything done because they're too busy bashing square pegs into round OOP holes.

Cas Smiley

Offline DzzD
« Reply #45 - Posted 2009-06-13 22:05:14 »

....just like to overcomplexify and overengineer everything and never get anything done because they're too busy bashing square pegs into round OOP holes.....
Cas Smiley
+1

trying to always make "hyper generic stuff" seems very nice but.... at the end, is there always a real benefit ?  is there a real solution ?  it is something as a quest

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #46 - Posted 2009-06-13 23:57:46 »

Ugh. When I wrote HSQLDB, I meant SQLite.

Anyway ...

People occasionally beat me over the head demanding that I finish the Entity Systems for MMO post series, but I don't want to mess it up with some half-assed followup. Sadly, I no longer work on MMO tech, don't even work for an MMO developer any more, and so I have no opportunity to carry on experimenting with this stuff - and I'd really like to include some worked example code in the next post(s).

It is *so easy* to fall into OOP coding accidentally when doing this stuff, and I want to be sure that my next posts are very explicit about the details of how people should architect their ES code.

ES's are fairly easy to do efficiently in C++, since most of the real challenges are about how to efficiently access vast amounts of data from streamed sources (i.e. structs are very good) - but there's no reason you can't do them well in Java, with a little effort

If anyone's interested in putting together a java-based ES game - especially if they'd open-source it - I'd love to help.

Essentially, I can advise you on how to architect the ES side of it, and work with you through the specific implementation issues that come up. The one thing I can't do is write code for you - I don't have time.

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

Junior Devvie


Projects: 1



« Reply #47 - Posted 2009-06-14 00:23:41 »

When I find the perfect programming paradigm, I will write the perfect program.

Offline ewjordan

Junior Devvie





« Reply #48 - Posted 2009-06-14 04:21:59 »

@blahblahblahh: Given your comments and that you've had some actual experience with this stuff, are you saying that it's the functional deficiencies of OOP that are solved by ES, or does it run deeper than that?

For instance, if you were writing game logic in Scala, Ruby, or Javascript (all solid OOP/functional mixes, though Javascript is kind of an odd man out given its odd breed of OOP), would you still write an ES system for the game, or are there easier or equivalent solutions within the languages themselves?

I'm very curious to see an example of situations where you really win with this sort of approach, as well as hear guidelines for implementing it.

That said, I agree with Cas' point about picture size. Smiley Most projects, classes, code, and components for games are never going to be reused, and time spent worrying about how to make reuse and extension easier is utterly wasted unless the project has a very large scope (like an MMO, for sure).
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #49 - Posted 2009-06-15 12:02:03 »

@blahblahblahh: Given your comments and that you've had some actual experience with this stuff, are you saying that it's the functional deficiencies of OOP that are solved by ES, or does it run deeper than that?

This has been a recurring theme, yes - ES -> SQL -> ES is trivial without boilerplate code, unlike OOP -> SQL -> OOP.

Although I havent yet delved far enough to check whether it's only some aspects of fn that are made-up-for this way, or all of them (in my experience, it seems to be the latter - OOP + ES == a decent, practical, simulation of fn-programming for your game objects).

Quote
For instance, if you were writing game logic in Scala, Ruby, or Javascript (all solid OOP/functional mixes

I don't know Scala, I haven't looked at Ruby in a very long time (that's the one that's a SmallTalk variant?), but Javascript is blatantly not functional. Being able to do a bit of slightly-functional-like programming in a language does not make it a fn language - javascript is inherently imperative, for instance. My vague memory of Ruby was that it wasn't especially fn either (but it's been at least 4 years since I even saw any Ruby code, so I honestly have no idea there).

I'm not trying to be pedantic - the same issue crops up with OOP: is there a minimum set of OOP-ness that a language requires to be considered an OOP language (since the invention of C++, and Bjarne's explanation for it, most people have felt "yes", IIRC). You can, for instance, simulate OOP inside Perl - but it is so obviously a simulation that you would never call Perl an OOP language (and "OO-Perl" is a slightly tacky concept that - if you know what it means - is fine, but often confuses people into thinking that Perl does full OOP)

Quote
would you still write an ES system for the game, or are there easier or equivalent solutions within the languages themselves?

By preference, I would write all MMO games entirely in fn languages.

Sadly, there are far far far too few trained fn programmers in the world - and unless you work in telecoms or microprocessor design (or other similarly niche fields), it's very hard to get any commercial experience in proper fn programming. Which all makes it prohibitively expensive, in real terms, to use fn for everything.

OOP + ES is a neat compromise where your coders "only" need to learn this new paradigm - the ES - which itself comes with a framework that solves a lot of problems they'd have had to work on anyway (for instance, the SQL de/serialization issues), and can carry on working in their language-of-choice with their IDE of choice and compilers, runtimes, etc of choice - and deubggers etc.


malloc will be first against the wall when the revolution comes...
Offline DzzD
« Reply #50 - Posted 2009-06-15 12:13:58 »

I have a blured vision of ES benefit (one thing I understand on it is  that : you store data in the functionalities (component) rather than in the object/entity itself, is that right ? I have trouble to understand why an ES cannot have an equivalent OO design as the interfaces samples posted previously).

anybody able to post a short, clean, working code showing a basic ES implementation in java ?

Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 849
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #51 - Posted 2009-06-15 13:02:31 »

For one: you can add/remove functionality from an Entity at runtime, as apposed to compile time when using interfaces.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social
Offline Markus_Persson

JGO Wizard


Medals: 16
Projects: 19


Mojang Specifications


« Reply #52 - Posted 2009-06-15 15:37:29 »

I've never run into the problems discussed in this thread.

Unless you want to either define/load new units in runtime or allow easy modding, I don't see the difference between defining a unit in an external file (xml or whatever) and in a java class file.

Play Minecraft!
Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 849
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #53 - Posted 2009-06-15 15:53:29 »

I think the problem is that ES shines in situations that nobody but Adam has encountered.

Most of us would never reach the point where OOP would not suffice.

The 'fact' that ES is better, is irrelevant if you can easily manage your own design.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social
Offline appel

JGO Wizard


Medals: 69
Projects: 4


I always win!


« Reply #54 - Posted 2009-06-15 16:55:15 »

Well, the ES design is certainly, hm, design-provoking. But for my RTS game it's probably a overkill, although I do like the design idea and will probably experiment with it on future games.

However, the idea of taking the functionality out of the gameobjects and move it into specialized components is working out quite well for my RTS game.


Now I've integrated Spring into my game design. All the gameobjects are defined as prototype beans in the spring bean XML file, and if I wish to create a new instance of a starship I simply call:

1  
GameObject myStarship = (GameObject)beanFactory.getBean("myStarship");


or if I want to add many starships into the game:

1  
2  
3  
4  
5  
// as it's a prototype bean, each getBean() method creates a new instance of myStarship
worldGameObjects.add((GameObject)beanFactory.getBean("myStarship"));
worldGameObjects.add((GameObject)beanFactory.getBean("myStarship"));
worldGameObjects.add((GameObject)beanFactory.getBean("myStarship"));
worldGameObjects.add((GameObject)beanFactory.getBean("myStarship"));


^ the above code can even be defined in another Spring XML file, called worldGameObjectsBean01, and inject it as the worldGameObjects list. That way I can define multiple worlds, or maps, in order to load them, simply by injecting them into the game-engine on demand.


Overkill? I don't know. Maybe it's because it's never been done before (well, at least in this isolated community) that we think it's too much, we fail to see the benefit. For me, I'm starting to see them.

At least it's one way of doing things.

Check out the 4K competition @ www.java4k.com
Check out GAMADU (my own site) @ http://gamadu.com/
Offline princec

« JGO Spiffy Duke »


Medals: 439
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #55 - Posted 2009-06-15 18:43:24 »

Actually, was doing that in 2003 for Alien Flux, and have done it ever since. I use factories configured by XML to create instances of stuff. It's like a lightweight and slightly easier to use and understand model than the various kitchen sink implementations out there.

Cas Smiley

Offline ewjordan

Junior Devvie





« Reply #56 - Posted 2009-06-15 19:03:03 »

I don't know Scala, I haven't looked at Ruby in a very long time (that's the one that's a SmallTalk variant?), but Javascript is blatantly not functional. Being able to do a bit of slightly-functional-like programming in a language does not make it a fn language - javascript is inherently imperative, for instance. My vague memory of Ruby was that it wasn't especially fn either (but it's been at least 4 years since I even saw any Ruby code, so I honestly have no idea there).
I'll admit very little JS or Ruby knowledge; however, in Javascript functions are true objects, you've got real closures, nested functions, higher order functions, you can pass functions to other functions, etc.  Once we add eval into the mix I don't know of anything you can do in Lisp that would be very difficult to translate to JS (though the code would certainly be a little heftier without proper macros).  What it lacks is predefined convenience methods that tend to permeate functional programming (fold, reduce, map, flatmap, etc.), and I'm not sure how it fares at tail call elimination, it might blow stack in your typical browser just like the JVM would.  Don't know as much about Ruby, to be honest, but from what I've heard it satisfies most functional programmers fully apart from the speed issues.

Javascript gets a real bad name because most of the uses it sees are very imperative and don't exploit its power, but to my knowledge it's a perfectly full featured fn language, albeit an impure one.  It definitely has flaws, but I don't think it particularly imposes an imperative style, even if it does make it easy to fall into.

What would you require in a fn language that it doesn't have? (aside from perhaps a flat out prohibition on state-ful programming, as the Haskell guys would prefer)  And what sort of language does qualify, in your view?
Offline princec

« JGO Spiffy Duke »


Medals: 439
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #57 - Posted 2009-06-15 20:38:41 »

Who cares... as someone's mentioned, this is a Java games dev board Wink

Cas Smiley

Offline ewjordan

Junior Devvie





« Reply #58 - Posted 2009-06-15 21:49:32 »

Who cares... as someone's mentioned, this is a Java games dev board Wink
Indeed, me == pulling the discussion OT into a language war yet again, as usual. Smiley

Still, Java (the platform) has a ton of flexibility as far as the language you code in, which to me is one of its greatest strengths.  Since it's so easy to mix any and all of the mentioned languages in with Java code, I don't see why we should restrict ourselves from discussing the possibility, esp. if it's a faster/easier/better solution than the alternative (which I'm not sure about, since I still don't entirely grok the claimed problem, lacking concrete examples of OOP's failures in typical game settings).

If all you need to solve your problem is a few function pointers or a closure, it's takes a couple downloads and a cut and paste to add a scalac step to your Ant build, compared to the weeks it might take to design, build, and debug a sophisticated component system.  It's more work to use Ruby or JS alongside Java, but it's still a lot less time than you'd spend to architect a perfect pure-Java solution.

...is all I'm saying. Tongue
Offline appel

JGO Wizard


Medals: 69
Projects: 4


I always win!


« Reply #59 - Posted 2009-06-15 22:12:48 »

If anyone is interested, here's this game of mine (very infant) that is using this Game Object Component System, and also Spring, which I use to define the game objects.

http://private.is/arni/gcom/

You can check out the link there which shows the Spring XML, should give you an idea. But, it's all in development still. But, with this power I can now rapidly create components and put together all sorts of game objects in the XML, and get them going in a heartbeat.

Some download overhead because of spring and slick libs.

Check out the 4K competition @ www.java4k.com
Check out GAMADU (my own site) @ http://gamadu.com/
Pages: 1 [2] 3 4
  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.

Elsealabs (11 views)
2014-12-28 10:39:27

CopyableCougar4 (17 views)
2014-12-28 02:10:29

BurntPizza (21 views)
2014-12-27 22:38:51

Mr.CodeIt (14 views)
2014-12-27 04:03:04

TheDudeFromCI (19 views)
2014-12-27 02:14:49

Mr.CodeIt (26 views)
2014-12-23 03:34:11

rwatson462 (57 views)
2014-12-15 09:26:44

Mr.CodeIt (47 views)
2014-12-14 19:50:38

BurntPizza (94 views)
2014-12-09 22:41:13

BurntPizza (115 views)
2014-12-08 04:46:31
How do I start Java Game Development?
by gouessej
2014-12-27 19:41:21

Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50
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!