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

Senior Member




Giving Java a second chance after ludumdare fiasco


« Reply #150 - Posted 2011-11-22 17:40:32 »

...

Dude I mean this in the nicest possible way: you are f**king insane.  WTF are you even talking about?  All your post scream Architecture Astronaut.  There, I said it.  If that's what you enjoy fine, but don't pretend you are carving a path forward for anyone but yourself.
Offline kevglass

JGO Kernel


Medals: 152
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #151 - Posted 2011-11-22 18:12:07 »

Do you have any idea how much game writing time you guys are wasting even getting involved in this thread? Wink

For interest, I've tested the 3 implementations thing on lots of different machines and I've got some of the Legends crowd to try it out. The end users impression:

- When Java works, it works best and feels best.
- Unfortunately Java doesn't work (well) in lots of cases. I'd say about 30% of cases reported either no applet at all or that it took so long to start the VM and load the game they'd already given up on the test.
- HTML5 seems to work nearly everywhere on the desktop with varying performances, never anything so bad it couldn't be played.
- Flash was absolutely brilliant on Windows, Mac not so much and Linux reported lots of graphical glitches, missing alpha etc.

Draw your own conclusions and know your market.

Also, I don't use ES, CA, <insert acronym> here in my code. I write simple code with tiny bits of engineering when it has a damn good reason and I don't have any performance, productivity or platform problems. Before anyone starts, I've written games from big to small scale, 2D and 3D and on more platforms than most.

If you want to produce a game, get your priorities right, you don't have enough time not to. Game first, engineering second.

If you want to produce elegant and engineered code, then you obviously have all the time in the world - so have fun doing it Smiley

Cheers,

Kev

Offline dishmoth
« Reply #152 - Posted 2011-11-22 18:27:32 »

Nice talk by Braid's programmer related to OP Smiley http://the-witness.net/news/2011/06/how-to-program-independent-games/
Finally got around to listening to this.  Big thumbs up!

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

JGO Kernel


Medals: 360
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #153 - Posted 2011-11-22 18:40:29 »

There's wasting time and there's quality timewasting though eh Smiley I'm enjoying this thread!

Imagine how much more productive you'd all be if the "public", "private" and "protected" keywords were removed from the language. Just think about that for a moment. A whole class of software engineering wank is suddenly removed from your life.

Also imagine if the final keyword were removed (and instead simply inferred at compile and run time). Another chunk of your brain freed to think about real problems.

Even the case for "abstract" looks tenuous.

I feel like designing a new language to make this easier!....

<10 years later>Hm still no game.

Cas Smiley

Offline delt0r

JGO Knight


Medals: 27
Exp: 18 years


Computers can do that?


« Reply #154 - Posted 2011-11-22 18:46:18 »

You know you could just make everything public... then you have got rid of the wank more or less.

Feels more like throwing out the baby with the bathwater to me however.

However lisp does not enforce "encapsulation" in CLOS. So your not alone in that respect.

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

JGO Kernel


Medals: 360
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #155 - Posted 2011-11-22 18:50:15 »

The problem is as soon as you are given the choice ... you will tend to spend an inordinate amount of time worrying about what should be public, private or protected. And then changing it. Then you go on to produce all sorts of daft interfaces and getters and setters to account for the fact you made all your members private. And so on. Now I think about it the amount of time I've spent wanking around in this exact way must be on the order of months of my entire career.

Cas Smiley

Offline Riven
« League of Dukes »

JGO Overlord


Medals: 781
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #156 - Posted 2011-11-22 20:00:26 »

Access modifiers are there for teams: preventing others from creating dependencies on code that is not stable yet or will never be suitable for interaction, for example because you could invalidate assumptions on the behaviour of other code.

If you are the sole developer, it makes much less sense to prevent yourself from doing things, you know how everything is connected.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline pjt33
« Reply #157 - Posted 2011-11-22 22:07:28 »

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.
And yet curiously C# loses manages to be worse. One thing I really miss from Java is the concept that "private" means "accessible within this compilation unit" rather than "accessible only within this class".

Also imagine if the final keyword were removed (and instead simply inferred at compile and run time). Another chunk of your brain freed to think about real problems.
Another chunk of my time wasted debugging because I made a typo in a constructor and didn't notice. I love the final keyword.
Offline princec

JGO Kernel


Medals: 360
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #158 - Posted 2011-11-22 22:29:39 »

Access modifiers are there for teams: preventing others from creating dependencies on code that is not stable yet or will never be suitable for interaction, for example because you could invalidate assumptions on the behaviour of other code.

If you are the sole developer, it makes much less sense to prevent yourself from doing things, you know how everything is connected.
I don't really buy this argument any more. IMHO, if source is commited to version control, it is defacto allowing itself to become a dependency or dependent on some other source. Not least because any team member can view and edit it, thus making the entire concept of hiding the implementation irrelevant. It simply doesn't make sense: you can see everything, how it works, even step through and fiddle it in the debugger. Why the hell can I not access it naturally? I've had to resort to reflection to twiddle things in libraries I didn't write to make them work properly. Why? Whose idea was it to waste my time in that way? I smell a rat. I think a "computer scientist" has tried to justify some "elegant solution" to a problem real programmers in real jobs don't really have.

Cas Smiley

Offline Damocles
« Reply #159 - Posted 2011-11-22 23:05:32 »

You dont nessesarity need to write messi code.
I write relatively "clean" code, and only in the end contract it down.
Mostly by just going though a list of optimizations that have been talked about.

Given the limited size, even clean code will not be very big anyhow.
And optimizing it down is to a large extend just copy/paste and renaming some stuff.
And looking at some framework exaples for the outer shell of the class.

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

JGO Kernel


Medals: 202



« Reply #160 - Posted 2011-11-22 23:06:00 »

Encapsulation through access modifiers is less important when you have separation of interface and implementation.  If you access a class only through its interface, everything that isn't on the interface is already effectively hidden.  Proper OOP means any subclass has to be substitutable for its superclass, but only for its public members.  Private and protected have more to do with giving subclasses an interface contract -- or in the case of private, a lack thereof.  As inheritance is more de-emphasized these days, encapsulation is also less of a byword in OOP than it used to be.  It's still not going away anytime soon.

Quote
I think a "computer scientist" has tried to justify some "elegant solution" to a problem real programmers in real jobs don't really have.

Things like type systems, and oh, compilers owe their existence to egghead computer scientists who thought there was a better way than the current practice.


Offline princec

JGO Kernel


Medals: 360
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #161 - Posted 2011-11-22 23:46:04 »

I simply find it patronising at best, and at worse, a huge inconvenience. And all wrapped up in a lovely waste of time which could have been spent solving the actual problem that needed solving.

Cas Smiley

Offline R.D.

Senior Member


Medals: 2
Projects: 1


"For the last time, Hats ARE Awesome"


« Reply #162 - Posted 2011-11-23 06:58:11 »

I don't really buy this argument any more. IMHO, if source is commited to version control, it is defacto allowing itself to become a dependency or dependent on some other source. Not least because any team member can view and edit it, thus making the entire concept of hiding the implementation irrelevant. It simply doesn't make sense: you can see everything, how it works, even step through and fiddle it in the debugger. Why the hell can I not access it naturally? I've had to resort to reflection to twiddle things in libraries I didn't write to make them work properly. Why? Whose idea was it to waste my time in that way? I smell a rat. I think a "computer scientist" has tried to justify some "elegant solution" to a problem real programmers in real jobs don't really have.

Cas Smiley

Reading this reminded me of this one here: link
Offline Damocles
« Reply #163 - Posted 2011-11-23 10:06:53 »

In a large corporate environment, with different teams, and low communication, the encapsulation makes sense.

Especially if teams build different elements of the businesslogic, and some jars are reused over
years, and get maintainance.

There you need a way to hide logic, simply to prevent cheap custom hacks, that will break the system if
other components are updated later.

Java is not mainly designed for making games, but rather for corporate use-cases.
---

It simply take the coder the brains to understand that those are different envoronments, requiering different approaches.
There is no single best practise.

Lets use the function dirtfactor.
Where
Dirtfactor = projectsize * teammembers  * code_dirtiness

So the dirtfactor should be kept at a constant, optimal level
And code_dirtiness needs to be lower in large, multiple developer teams
And high in small rapit prototypes

Offline appel

JGO Wizard


Medals: 50
Projects: 4


I always win!


« Reply #164 - Posted 2011-11-23 10:13:40 »

Java is not mainly designed for making games, but rather for corporate use-cases.
Actually, java was originally designed and intended for embedded systems, like software for cars and toasters.

Check out the 4K competition @ www.java4k.com
Check out GAMADU (my own site) @ http://gamadu.com/
Offline Damocles
« Reply #165 - Posted 2011-11-23 10:17:26 »

My toaster has 2 buttons.
Never saw a JVM there.

And anyhow, those are actually examples of industrial projects, where the same applies.
(where different modelgenerations with customizations have to be developed,
hacking this together for each iteration would also increase the costs for the QA)

Offline princec

JGO Kernel


Medals: 360
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #166 - Posted 2011-11-23 12:32:32 »

And yet, there are these massive software projects built up from PHP and JavaScript and Ruby and other scripting horrors and it turns out they didn't need encapsulation to do it. Who knew?

Cas Smiley

Offline delt0r

JGO Knight


Medals: 27
Exp: 18 years


Computers can do that?


« Reply #167 - Posted 2011-11-23 12:50:57 »

Well quite a few of these projects have hit walls. I know a few that are dumping entire code bases and starting again because its become impossible to maintain and impossible to hire new blood that can get anywhere in year (sorry NDAs).

Encapsulation is not a bad thing any more that 100% purely functional programing style is a bad thing. Its a tool and/or a style that can help solve problems. Big projects don't fit inside anyone's head, and even if your the sole developer it is easy to forget what is what. Encapsulation lets you tell others and yourself that you don't need to see whats inside. You don't need to go back over it you can look at just the outside. For the most part my code does work like this and i don't need to dive into the internals. I almost never consult the java library source, but use the api documentation extensively.

Later if you do need to you can always add a public. Its not the end of the world. Java nor C++ forces encapsulation (unlike pure functional programing). Neither does C of course even if you want it too, yet the Linux kernel is written with a high degree of encapsulation. The "many simple programs do one job and well" is even a form of encapsulation.

I have seen my enemy, and he is me. Encapsulation helps me save me from myself.

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

JGO Kernel


Medals: 360
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #168 - Posted 2011-11-23 13:12:08 »

The interesting thing to note about these complete rewrites is that I've seen exactly the same thing happen in any language in any project. The teams change slowly over time and eventually all projects end up in a bit of a mess and some genius has the bright idea of rewriting it whether it needs it or not. My conclusion is thusly: encapsulation has no measurable effect on code entropy, readability or maintainability, and that if an engineer gets left in charge of making management decisions sooner or later the irresistable urge to tinker with things pointlessly gets the better of them.

There may be some super wiz-kids out there who manage to keep stuff sane for longer but eventually everything succumbs. It should be one of those Laws.

Cas Smiley

Offline Gudradain
« Reply #169 - Posted 2011-11-23 15:14:49 »

Quote
Dummy Interfaces: Write an empty interface called something like "WrittenByMe", and make all of your classes implement it. Then, write wrapper classes for any of Java’s built-in classes that you use. The idea is to make sure that every single object in your program implements this interface. Finally, write all methods so that both their arguments and return types are WrittenByMe. This makes it nearly impossible to figure out what some methods do, and introduces all sorts of entertaining casting requirements. For a further extension, have each team member have his/her own personal interface (e.g., WrittenByJoe); any class worked on by a programmer gets to implement his/her interface. You can then arbitrarily refer to objects by any one of a large number of meaningless interfaces!

I found that on the site : How to write unmaintainable code Smiley.

It makes me think about Entity System or code design of some programmer.
Offline Gudradain
« Reply #170 - Posted 2011-11-23 15:18:17 »

Quote
Too Much of A Good Thing™: Go
1  
2  
3  
4  
5  
6  
myPanel.add( getMyButton() );

private JButton getMyButton()
{
   return myButton;
}


That one probably did not even seem funny. Don’t worry. It will some day.

Another one relevent to this topic

Quote
Wrap, wrap, wrap: Whenever you have to use methods in code you did not write, insulate your code from that other dirty code by at least one layer of wrapper. After all, the other author might some time in the future recklessly rename every method. Then where would you be? You could of course, if he did such a thing, insulate your code from the changes by writing a wrapper or you could let VAJ handle the global rename. However, this is the perfect excuse to preemptively cut him off at the pass with a wrapper layer of indirection, before he does anything idiotic. One of Java’s main faults is that there is no way to solve many simple problems without dummy wrapper methods that do nothing but call another method of the same name, or a closely related name. This means it is possible to write wrappers four-levels deep that do absolutely nothing, and almost no one will notice. To maximise the obscuration, at each level, rename the methods, selecting random synonyms from a thesaurus. This gives the illusion something of note is happening. Further, the renaming helps ensure the lack of consistent project terminology. To ensure no one attempts to prune your levels back to a reasonable number, invoke some of your code bypassing the wrappers at each of the levels.

Quote
No Secrets!: Declare every method and variable public. After all, somebody, sometime might want to use it. Once a method has been declared public, it can’t very well be retracted, now can it? This makes it very difficult to later change the way anything works under the covers. It also has the delightful side effect of obscuring what a class is for. If the boss asks if you are out of your mind, tell him you are following the classic principles of transparent interfaces.
Offline Gudradain
« Reply #171 - Posted 2011-11-23 15:26:00 »

Quote
Static Is Good: Make as many of your variables as possible static. If you don’t need more than one instance of the class in this program, no one else ever will either. Again, if other coders in the project complain, tell them about the execution speed improvement you’re getting.

Quote
And That’s Final: Make all of your leaf classes final. After all, you’re done with the project - certainly no one else could possibly improve on your work by extending your classes. And it might even be a security flaw - after all, isn’t java.lang.String final for just this reason? If other coders in your project complain, tell them about the execution speed improvement you’re getting.

Lol someone told me exactly that once because I was arguing that putting everything final was a bad idea...

Quote
Eschew The Interface: In Java, disdain the interface. If your supervisors complain, tell them that Java interfaces force you to "cut-and-paste" code between different classes that implement the same interface the same way, and they know how hard that would be to maintain. Instead, do as the Java AWT (Advanced Windowing Toolkit) designers did - put lots of functionality in your classes that can only be used by classes that inherit from them, and use lots of "instanceof" checks in your methods. This way, if someone wants to reuse your code, they have to extend your classes. If they want to reuse your code from two different classes - tough luck, they can’t extend both of them at once! If an interface is unavoidable, make an all-purpose one and name it something like "ImplementableIface." Another gem from academia is to append "Impl" to the names of classes that implement interfaces. This can be used to great advantage, e.g. with classes that implement Runnable.

Everyone love awt Smiley
Offline Gudradain
« Reply #172 - Posted 2011-11-23 15:38:56 »

ok just 2 last one

Quote
Subclass With Abandon: Object oriented programming is a godsend for writing unmaintainable code. If you have a class with 10 properties (member/method) in it, consider a base class with only one property and subclassing it 9 levels deep so that each descendant adds one property. By the time you get to the last descendant class, you’ll have all 10 properties. If possible, put each class declaration in a separate file. This has the added effect of bloating your INCLUDE or USES statements, and forces the maintainer to open that many more files in his or her editor. Make sure you create at least one instance of each subclass.

Smiley!

Quote
Globals, We Can’t Stress These Enough!: If God didn’t want us to use global variables, he wouldn’t have invented them. Rather than disappoint God, use and set as many global variables as possible. Each function should use and set at least two of them, even if there’s no reason to do this. After all, any good maintenance programmer will soon figure out this is an exercise in detective work, and she’ll be happy for the exercise that separates real maintenance programmers from the dabblers.

Globals, One More Time, Boys: Global variables save you from having to specify arguments in functions. Take full advantage of this. Elect one or more of these global variables to specify what kinds of processes to do on the others. Maintenance programmers foolishly assume that C functions will not have side effects. Make sure they squirrel results and internal state information away in global variables.

Local Variables: Never use local variables. Whenever you feel the temptation to use one, make it into an instance or static variable instead to unselfishly share it with all the other methods of the class. This will save you work later when other methods need similar declarations. C++ programmers can go a step further by making all variables global.

Indeed that is good practice.
Offline JL235

JGO Coder


Medals: 10



« Reply #173 - Posted 2011-11-23 15:48:59 »

And yet, there are these massive software projects built up from PHP and JavaScript and Ruby and other scripting horrors and it turns out they didn't need encapsulation to do it. Who knew?
PHP and Ruby don't support your argument. Both have private/public/protected, and both offer more ways to modularize your code. Especially Ruby with it's mixins, blocks, lambdas and it's meta-programming abilities.

As for JS, I personally find the lack of access modifiers an issue, and have had to use code practices to make it easier to navigate. For example I just never access fields directly from outside, because I have no idea if it's meant to be public or private. Does it really matter? Yes! With any large code base it's easy for small changes to cause bugs, and knowing that nothing else is touching this bit of code right here, is a HUGE advantage.

The simple fact is that there are plenty of language features out there that don't get used, and if people didn't find accessors useful, then they would be one of them.

Offline princec

JGO Kernel


Medals: 360
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #174 - Posted 2011-11-23 16:08:51 »

Select field -> Write Access in Workspace

Cas Smiley

Offline ShannonSmith
« Reply #175 - Posted 2011-11-23 16:30:29 »

Access modifiers are there for teams: preventing others from creating dependencies on code that is not stable yet or will never be suitable for interaction, for example because you could invalidate assumptions on the behaviour of other code.

If you are the sole developer, it makes much less sense to prevent yourself from doing things, you know how everything is connected.
I don't really buy this argument any more. IMHO, if source is commited to version control, it is defacto allowing itself to become a dependency or dependent on some other source. Not least because any team member can view and edit it, thus making the entire concept of hiding the implementation irrelevant. It simply doesn't make sense: you can see everything, how it works, even step through and fiddle it in the debugger. Why the hell can I not access it naturally? I've had to resort to reflection to twiddle things in libraries I didn't write to make them work properly. Why? Whose idea was it to waste my time in that way? I smell a rat. I think a "computer scientist" has tried to justify some "elegant solution" to a problem real programmers in real jobs don't really have.

Cas Smiley

It's clear you haven't really worked on a large codebase with a big team of typical software engineers. You cannot rely on other engineers doing the right thing and in fact have to work VERY hard just stop them from doing idiotic things. My life would be a living hell without access modifiers, they are essential for many reasons.

They protect your code from being abused, without them you couldn't make any assumptions about any of your member variables ever. You would have to synchronize everything and null pointer check everywhere. They give massive hints as to how your code was designed and how it should be used and modified. Sure someone can just come along and make your internal member variable public but they will be wary of doing so and will likely check to see if this is what they should be doing.

Of course I have seen this taken to it's extreme (especially in web-server frameworks for some reason) and it's not pretty either. I saw a brilliant analogy to it with trying to buy a hammer http://discuss.joelonsoftware.com/default.asp?joel.3.219431 .

At the end of the day you need to remember it's about simplicity as Einstein once said "Make things as simple as possible, but not simpler.". Access modifiers essentially generate a layer of simplicity for other people to use, you just need to be careful about going too far.
Offline Roquen
« Reply #176 - Posted 2011-11-23 16:40:56 »

Ha. I've been thinking of that Einstein quote, along with Antoine de Saint Exupéry's:

Quote
perfection is attained not when there is nothing more to add, but when there is nothing more to remove

(edit: And also "A goal without a plan is just a wish")
Offline princec

JGO Kernel


Medals: 360
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #177 - Posted 2011-11-23 16:46:59 »

It's clear you haven't really worked on a large codebase with a big team of typical software engineers.
LOL. You really ought to find out more about me.

Cas Smiley

Offline theagentd
« Reply #178 - Posted 2011-11-23 17:02:48 »

Why are you guys flaming access modifiers in the first place? Is it hard or time-consuming to pick the right one and write it?

Myomyomyo.
Offline nsigma
« Reply #179 - Posted 2011-11-23 17:04:13 »

Ha. I've been thinking of that Einstein quote, along with Antoine de Saint Exupéry's:

Quote
perfection is attained not when there is nothing more to add, but when there is nothing more to remove

(edit: And also "A goal without a plan is just a wish")

I also like another Einstein quote, which somehow seems very apt for this thread.

Quote
A clever person solves a problem. A wise person avoids it.

It's on that CodeWisdom feed I linked to earlier today btw  Grin

Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Pages: 1 ... 4 5 [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.

atombrot (20 views)
2014-08-19 09:29:53

Tekkerue (21 views)
2014-08-16 06:45:27

Tekkerue (21 views)
2014-08-16 06:22:17

Tekkerue (12 views)
2014-08-16 06:20:21

Tekkerue (19 views)
2014-08-16 06:12:11

Rayexar (55 views)
2014-08-11 02:49:23

BurntPizza (37 views)
2014-08-09 21:09:32

BurntPizza (27 views)
2014-08-08 02:01:56

Norakomi (35 views)
2014-08-06 19:49:38

BurntPizza (64 views)
2014-08-03 02:57:17
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

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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!