Still hardly any games, why entity systems suck, and why 4k is good

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

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

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

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

;D
(via #AltDevBlogADay)

@Chromanoid
Touché.

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 :slight_smile:

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

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

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

But, we don’t have the self-discipline to prototype games, 4k forces that discipline upon us, even if that’s not the best way it still works.

Well said appel,

Creativity/Productivity through limitation.

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

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

That basically says: “Do a game without any (OO-) software design” :o
or “Do game design instead” :wink:

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

Cas :slight_smile:

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

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

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

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

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

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

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

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.

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, 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 :slight_smile:

Cheers,

Kev

Finally got around to listening to this. Big thumbs up!

There’s wasting time and there’s quality timewasting though eh :slight_smile: 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 :slight_smile:

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.

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 :slight_smile:

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.

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”.

[quote=“princec,post:154,topic:37519”]
Another chunk of my time wasted debugging because I made a typo in a constructor and didn’t notice. I love the final keyword.

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 :slight_smile:

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.