Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (109)
games submitted by our members
Games in WIP (536)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 ... 5 6 [7] 8
  ignore  |  Print  
  Still hardly any games, why entity systems suck, and why 4k is good  (Read 20736 times)
0 Members and 1 Guest are viewing this topic.
Offline ShannonSmith
« Reply #180 - Posted 2011-11-23 18:46:56 »

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
Do tell, I'm always interested in peoples paths to their current software philosophy. Mine is born out of working at two companies at either extreme.

Company A:
Writing firmware for routers/switches, the code base was gargantuan written in C and had evolved over time and pretty much no API's at all, every variable was just extern'ed and used wherever it was needed. It was an unbelievable rats nest of dependency hell. It basically became impossible to change anything without breaking something else. Fixing a bug meant you were pretty much guaranteed to introduce a bug somewhere else. The management solution to this problem was more code reviews, it would take me a week to introduce a line of code. I lasted there for 6 months.

Company B:
Web based applications for managing people/processes. The code base was also gargantuan, written in Java and ridiculously over-engineered. There were more interfaces than classes and roughly only 10% of the code actually did anything. Fixing a bug was a nightmare as you had to drill down through layers upon layers of abstraction to find the code you were after. The company was all about frameworks and design patterns. It is here I grew to hate the phrase "business logic", also lasted 6 months.
Offline avm1979
« Reply #181 - Posted 2011-11-23 20:09:08 »

Select field -> Write Access in Workspace

Cas Smiley

More of a pain than just highlighting it w/ "mark occurrences" toggled on, imo. If you have to do this for every field when coming back to some old code, ugh. But clearly, it works for you - it just wouldn't for me.

I think blaming access modifiers for wasted time is a stretch. They're just a tool - useful sometimes, not useful other times. Also a matter of style and taste. I don't buy that when someone spends too much time deciding which ones to use, it's the access modifiers' fault. That problem is between the chair and the computer Smiley

Offline pitbuller
« Reply #182 - Posted 2011-11-23 20:11:08 »

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
Do tell, I'm always interested in peoples paths to their current software philosophy. Mine is born out of working at two companies at either extreme.

Company A:
Writing firmware for routers/switches, the code base was gargantuan written in C and had evolved over time and pretty much no API's at all, every variable was just extern'ed and used wherever it was needed. It was an unbelievable rats nest of dependency hell. It basically became impossible to change anything without breaking something else. Fixing a bug meant you were pretty much guaranteed to introduce a bug somewhere else. The management solution to this problem was more code reviews, it would take me a week to introduce a line of code. I lasted there for 6 months.

Company B:
Web based applications for managing people/processes. The code base was also gargantuan, written in Java and ridiculously over-engineered. There were more interfaces than classes and roughly only 10% of the code actually did anything. Fixing a bug was a nightmare as you had to drill down through layers upon layers of abstraction to find the code you were after. The company was all about frameworks and design patterns. It is here I grew to hate the phrase "business logic", also lasted 6 months.


We have those both in same company. There is c side and java side and both do something about database thingy but I am not yet sure what and how. Even if I have been in company over six months.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #183 - Posted 2011-11-23 20:54:58 »

@ShannonSmith - since you asked here is an out of date base CV (which is largely factual unlike most CVs I have to read through). It's out of date now as I don't need one any more, and this one is the base CV, not tailored to any particular job application. The phone number is deliberately incorrect as I don't want a job ever again Wink

Cas Smiley

Offline loom_weaver

JGO Coder


Medals: 17



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

I think one of the mistakes of OO was that it taught that this:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
class Point {
    private int x;
    private int y;

    public Point(int x, int y) {
        this.x = x;
        this.y = y;
    }

    public int getX() { return x; }
    public void setX(int x) { this.x = x; }

    public int getY() { return y; }
    public void setY(int y) { this.y = y; }
}


was somehow superior to this because it used data-hiding and encapsulation!!!
1  
2  
3  
4  
struct Point {
    int x;
    int y;
}


If you using Points as mutable data structures then really one hasn't encapsulated anything by using a class.  There is still the same dependencies on anything that uses it.  These days I'm leaning towards keeping my data in raw form e.g. arrays, maps, basic types and writing functions to transmute it.

I still think global variables suck though because the singleton pattern, while it sounds cool and makes the speaker seem erudite, actually should be an anti-pattern because it sucks and most of the time you don't even need it.
Offline R.D.

Senior Member


Medals: 2
Projects: 1


"For the last time, Hats ARE Awesome"


« Reply #185 - Posted 2011-11-23 21:18:24 »

Ever tried to develope a map maker in 3 weeks? Sure singleton are helpful... more then you think I guess. and what are globals variables for you? Let's say you have an entity with a postion... ist the postion field bad because it's declared global (and public of course, can't understand people who make getters... useless wank of OO imho^^)
Offline loom_weaver

JGO Coder


Medals: 17



« Reply #186 - Posted 2011-11-23 21:23:54 »

Ever tried to develope a map maker in 3 weeks? Sure singleton are helpful... more then you think I guess. and what are globals variables for you? Let's say you have an entity with a postion... ist the postion field bad because it's declared global (and public of course, can't understand people who make getters... useless wank of OO imho^^)

There's a big difference between a singleton (global) and an instantiated entity with a position that has public access.
Offline sproingie

JGO Kernel


Medals: 202



« Reply #187 - Posted 2011-11-23 21:34:43 »

The theory is that a subclass can override the getters and setters to use a different data structure for storage, or that it could implement an interface like Tuple2D so you could treat a Point2D and a Vector2D differently when you want, and uniformly when you want. 

But if you don't need any of that, then there's no shame in designing a class for a specific purpose.  I personally think getters and setters are a good thing, but Java is horrific at hiding that kind of boilerplate or providing nice syntax for it (both things my pet language has no problem with).
Offline ShannonSmith
« Reply #188 - Posted 2011-11-23 22:25:16 »

@ShannonSmith - since you asked here is an out of date base CV (which is largely factual unlike most CVs I have to read through). It's out of date now as I don't need one any more, and this one is the base CV, not tailored to any particular job application. The phone number is deliberately incorrect as I don't want a job ever again Wink

Cas Smiley

That's quite a CV, and after all that you think that access modifiers are a bad idea? After 10 years and many different languages I've come full circle on a few things and have spent some time considering what I would put in an ideal language but I've never considered not having access modifiers. One thing I do agree with you on his how much I hate programming and how unfortunately necessary it is for writing games.
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #189 - Posted 2011-11-23 23:06:03 »

And that CV omits 13 years of non-commercial experience beforehand and the last couple of years too.

What it boiled down to was this: which features have actually ever made my life easier or harder, or got more or less done with? And access modifiers have sadly only ever made my life harder - on many occasions when I've been trying to use other people's code and they've not foreseen some situation or other which requires tinkering - or less productive, as I've sat there and wrangled with designs to try and "encapsulate" stuff so that those poor diddums kiddy programmers who came after me wouldn't accidentally blow their own heads off by writing the wrong bit of code or doing it in a way Benevolent But Menacing Caspian did not approve of. Or likely think of at the time. In short - just a huge waste of time and effort to patronise my fellow developers.

I could of course be totally wrong but as I've noticed, languages that lack these features don't seem to suffer productivity problems, and therefore neither can they suffer maintainability problems. Maintenance is irrelevant if productivity is so high as to make it as cheap to rewrite as it is to try buggering around in someone else's mindset. This is the reality of software development today.

Cas Smiley

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

Senior Member


Medals: 2
Projects: 1


"For the last time, Hats ARE Awesome"


« Reply #190 - Posted 2011-11-23 23:29:47 »

Pew~ I always thought I had to squeze my head into all that software engineering to get a job or at least have the chanve to do real programming but your CV shows that can also try the road of being a "target-programmer". Nice to know Smiley

(Also, I never knew you are the creator of LWJGL)
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #191 - Posted 2011-11-24 00:11:54 »

Unfortunately when such features are in the language you will be expected to use them as everyone else will be, so you're still going to have to! Unless you get a job in one of these silicon valley startups where they do things in crazy disruptive ways.

I had a hand in the original LWJGL but sadly not been too involved in it for the last few years. Too busy using it!

Cas Smiley

Offline sproingie

JGO Kernel


Medals: 202



« Reply #192 - Posted 2011-11-24 05:18:16 »

Since we're on the subject, and just out of curiosity Cas, what's your opinion on checked exceptions?
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #193 - Posted 2011-11-24 10:12:54 »

Weighing carefully on the 3 main implementations of exceptions that I know of (none at all, Java style, and C# style)... I'd say that checked exceptions are, on balance, not a great help. Yeah I know, heresy, etc. but the only real problem they solve is that you no longer have to co-opt special values from return codes to mean special things. The other problems that they allegedly solve I see routinely defeated by everyday programmers, and thus their effectiveness tends towards zero. Another evolutionary dead end.

C# on the other hand acknowledges that there is no real need to bully programmers into checking exceptions. All exceptions are safely propagated up the stack and end up either killing a thread (with a lovely stacktrace output to system.err) or eventually caught and dealt with somehow anyway. So I'd say the C# design is probably the most useful.

Cas Smiley

Offline delt0r

JGO Knight


Medals: 26
Exp: 18 years


Computers can do that?


« Reply #194 - Posted 2011-11-24 12:04:46 »

Checked exception are dumb. Exceptions are not so dumb on their own. But with check exceptions you end up with nested try/catch blocks because dealing with an exception throws more checked exceptions.

Also i hate that i can not easily just check for EOF. Since its an exception, that is the way to find it (or a null line on BufferedReaders). Ok so i am almost ranting about imperfect APIs rather than lang features.

Also i am wasting time arguing the virtues of different coding styles rather than coding!  Undecided

I have no special talents. I am only passionately curious.--Albert Einstein
Offline pjt33
« Reply #195 - Posted 2011-11-24 18:49:37 »

Also i hate that i can not easily just check for EOF. Since its an exception, that is the way to find it (or a null line on BufferedReaders).
As a general rule, either you use BufferedReader and get a null line or you use InputStream.read(byte[], int, int) and check for a return value of -1. I never catch EOFExceptions.
Offline sproingie

JGO Kernel


Medals: 202



« Reply #196 - Posted 2011-11-24 18:59:31 »

Cas, I think you put it about as well as I could have.  I like the idea of checked exceptions, but I think not catching them should have been a warning, not an error.  Possibly coupled with a command line flag that can promote specific warnings into errors.  Theoretically they make sense, since the nonlocal return path of a method should be part of its signature that you must account for ... but even as much as I love theory, this is one that just didn't pan out in practice.  For all its embrace of theory, Scala gave up on checked exceptions entirely.
Offline Catharsis

Junior Member


Exp: 18 years


TyphonRT rocks!


« Reply #197 - Posted 2011-11-24 19:36:21 »

Yeah.. I'm not really into checked exceptions especially for any performance bound code, but handle unchecked exceptions intelligently from the clocking threads (potentially end the clocked runtime item silently, w/ a warning, log it, or if it is marked as a fatal error stop entirely) and via a default uncaught exception handler as to not crash the runtime, but provide some sort of reasonable response to the user, logging, or possible recovery if applicable. Any custom exceptions that are thrown in my efforts are all unchecked / runtime oriented.

As you say Sproingie if checked exceptions created a warning instead of an error if not handled I suppose there could also be an annotation that promoted it to an error state or could provide an IDE the ability to mark it visually instead of just a runtime JVM flag.

Offline nsigma
« Reply #198 - Posted 2011-11-24 19:40:04 »

I like the idea of checked exceptions, but I think not catching them should have been a warning, not an error. 

+1 to that.  Something in-between Exception and RuntimeException, possibly.  There's a benefit to having to declare them in method signatures.

Scala gave up on checked exceptions entirely.

 Shocked WHAT? There's something Scala doesn't have???  Grin

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

JGO Kernel


Medals: 202



« Reply #199 - Posted 2011-11-24 20:06:38 »

Scala doesn't have break or continue either (well it kinda has break now).  It also doesn't have "static", it has companion objects.   It doesn't have void, it has Unit which is an actual value.  Sometimes improvement is a matter of taking things away.

Offline Nate

JGO Kernel


Medals: 145
Projects: 4
Exp: 14 years


Esoteric Software


« Reply #200 - Posted 2011-11-25 00:53:15 »

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.
It's about defining an API. *I* define what you access in my API. We have a contract. Anything I don't provide to you is none of your damned business and I am free to change without breaking you. There are plenty of scenarios where this makes sense. Everything *could* be public, but then I would have to assume any change I make will break all clients, and that is shit. If you want to access something that isn't exposed, you aren't using the API as intended and it is supposed to be a PITA. Blame the poorly designed API.

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #201 - Posted 2011-11-25 01:29:26 »

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

Don't listen to Cas on this; he's forgotten what it's like to work with competent-but-imperfect colleagues - he only knows "useless" and "expert".

Encapsulation is the single best thing in language design since the invention of ARM assembler.

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

JGO Coder


Medals: 1


http://t-machine.org


« Reply #202 - Posted 2011-11-25 01:33:31 »

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.
[/quote]

You will not win that argument. You aren't putting it strongly enough (it's too easy to say:"well, work with better people")

The way to go is:

"It's clear you haven't reallyh worked on a large codebase where you yourself fscked-up your own code, because you misinterpreted what you'd previously written, or abused it in nice-sounding-but-actually-quite-stupid ways".

C programmers know this innately: there is no code so simple that an expert coder cannot shoot themself in the head. One of the best things that programming languages can do is protect us *from ourselves*.

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

Junior Member


Exp: 18 years


TyphonRT rocks!


« Reply #203 - Posted 2011-11-25 05:01:30 »

It's about defining an API. *I* define what you access in my API. We have a contract. Anything I don't provide to you is none of your damned business and I am free to change without breaking you. There are plenty of scenarios where this makes sense. Everything *could* be public, but then I would have to assume any change I make will break all clients, and that is shit. If you want to access something that isn't exposed, you aren't using the API as intended and it is supposed to be a PITA. Blame the poorly designed API.

^ this; I'm kind of surprised this isn't the common understanding and am at times kind of amazed at some of the discussion in this thread and forums in general. Not to be disparaging per se, but it's like CS 101 hasn't sunk in at all. Interface based programming is one of the industries best practices and is core to API / framework creation in Java. It's central to my efforts with component architecture development and separating things modularly. I think interface based programming is likely the most important best practice that can be objectively discussed as such without a question of whom it might benefit.

Still going to try and post a bit of a response to various replies in this thread likely on Sat when I'm on a plane again.

Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #204 - Posted 2011-11-25 12:13:23 »

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

I think there must be a better way.

Cas Smiley

Offline ra4king

JGO Kernel


Medals: 342
Projects: 2
Exp: 5 years


I'm the King!


« Reply #205 - Posted 2011-11-25 12:44:32 »

I think there must be a better way.
And that's how all new languages are born........

Offline kevglass

JGO Kernel


Medals: 123
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #206 - Posted 2011-11-25 12:48:07 »

You're all still wasting time! Get on with the frickin games damn you! Smiley

Cheers,

Kev

Offline gouessej
« Reply #207 - Posted 2011-11-25 13:02:32 »

I should probably make a strong point to note, much to gouessej's obvious chagrin, that every single one of the games that have made it are based on LWJGL
I remind you that Wurm Online used JOGL until 2011. JOGL success stories are more numerous outside gaming, for example Playviz.

Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #208 - Posted 2011-11-25 13:04:19 »

Oh all bloody right Kev! So far I've used 8000 of my 16384 bytes and I've somehow managed to squeeze the entire sprite engine and effects engine and FM synth game framework from Puppygames into it. Text rendering and particle effects next. No actual, ahem, game yet Smiley

Cas Smiley

Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #209 - Posted 2011-11-25 13:05:38 »

I should probably make a strong point to note, much to gouessej's obvious chagrin, that every single one of the games that have made it are based on LWJGL
I remind you that Wurm Online used JOGL until 2011. JOGL success stories are more numerous outside gaming, for example Playviz.
I gave up on Wurm Online years ago because the rendering was so buggy and glitched... but that's another story.

Cas Smiley

Pages: 1 ... 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.

CogWheelz (15 views)
2014-08-01 22:53:16

CogWheelz (15 views)
2014-08-01 22:51:43

CopyableCougar4 (15 views)
2014-08-01 19:37:19

CogWheelz (19 views)
2014-07-30 21:08:39

Riven (27 views)
2014-07-29 18:09:19

Riven (16 views)
2014-07-29 18:08:52

Dwinin (14 views)
2014-07-29 10:59:34

E.R. Fleming (35 views)
2014-07-29 03:07:13

E.R. Fleming (13 views)
2014-07-29 03:06:25

pw (44 views)
2014-07-24 01:59:36
Resources for WIP games
by CogWheelz
2014-08-01 18:20:17

Resources for WIP games
by CogWheelz
2014-08-01 18:19:50

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

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

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

HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22
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!