Only once your game is running so slowly that it's becoming frustrating to debug and test it.

You can tolerate a lot of low performance before you get to that point. Live with it. Focus on the rest of the game. Do the optimization only when it becomes *necessary*.

Not "last", but "only as soon as when you need it, and no earlier". e.g. when I notice the minimum compile/test/debug cycle being slowed down by more than 30 seconds just because of low performance ... I optimize.

Quote

Where is efficiency lost?... in either homemade containers or Java collections. -> And how you increase efficiency?

Worst: selecting the right subset of items from the containerSecond worst: iterating over the container

For the former, you can create custom containers - or ... just use smaller containers, and pre-split your data into chunks that you frequently access as subsets.

For both items, arrays (or, better, Buffers) of flyweight impersonated objects are much faster. But don't bother until/unless you actually need it.

I've got a turn-based tablet game that's almost complete for single-player, and now I'm adding MP. This is a personal project, so it's got to be VERY low maintenance and MINIMAL EFFORT to develop. I expect to launch with a free or very cheap server, and if it does well pay for something a bit better. If it does very well, I'd write something custom - but otherwise I wouldn't bother.

Does anyone here have recent experience with 3rd party game servers, especially SaaS?

OpenFeint - unofficially, they've dropped their gameserver product. It's still listed in their marketing blurb, but they've removed all the links from their website. So, um. Yeah, I wouldn't trust them an inch.

http://parse.com - API + hosting all from one company - it's a key/value store, trivial to work with - ...but has NO high-level mechanics, requires you to write all game mechanics - everything has to be written client-side, or you have to write a second server that queries Parse - billing model is "per method call" (ouch!)). - They assume you'll use lots of storage, and do few method calls - which is the opposite of a non-MMO online game - so their pricing isn't great

Hmm, can't say I really agree that it really looks that great for a big Java game anymore (granted that it wasn't completed and probably placeholder art) but looks like a generation or two behind current gaming standards.

IIRC the rest of the company was being asked to look at it as:

"Here's what we can do in 1/100th the budget of a standard internal title, and without a full art team and without a full programming team. Plz can haz real dev budget?"

My memory is that people generally thought it was crud - but shone in all the right places. e.g. it showed large enviornments rendering at sensible speed, it showed variety in 3d levels (no suspicious "everything looks like a heightfield; hmm ... can this engine ONLY do heightfields?" etc), it showed high-poly details on characters, and high-detail textures.

...but each of those things just showed in one or two places. Because there was no budget / time / resource to apply it consistently.

Demos to publishers are often like this - they show what the team / middleware COULD do, in small glimpses. And they ask for the remaining 99% budget to make it do that in ALL the places...

Many people (myself included) won't bother with a library if it's SVN-only, or if it's on googlecode.

For reasons like those listed above - SVN is historically *very* buggy, and Googlecode has a lot of constraints that make it a pain to work with.

Github is free, very simple to use (they give you copy/paste instructions to type in), and lets you do just about anything. As a user of the library, it also makes it trivial to "fork" the library and do custom fixes / changes.

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

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

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.

Sometimes i want to add a annotation that only once class in particular should call a method. I have been told then it shouldn't be public... well its still the easiest way to get it done, and done now, not later.

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)

I don't know if Markus still reads jgo much these days, but congratulations man. It's freaking epic.

Seconded - it's awesome!

Main changes I've noticed with 1.0: - villagers (annoying, useless, just there to be slaughtered, basically) - endermen don't die in daylight, and teleport frequently, a lot more scary than before - there's a LOT more animals around (chickens, cows, sheep)

Hm so if that took you 10-20 hours using ES but you think it'd take you 30-40 hours with ordinary paradigm-free programming... well, something's up there. Using my long-trained eye for designs of this nature it looks like about 10-20 hours or so to get what you've got there working using my usual ways... so what gives?

Yes. It's a personal problem . It only really comes up on solo projects, but it's crippling.

I'm extremely fast at fixing broken code, and very good at finding clever, short, fast solutions to difficult problems.I'm good at design, but I typically have to try something three different ways, throw them away quickly, and then settle on a fourth way that's great.

If it takes more than "minutes" to re-write my game, then I lose the thread of the design I was doing, and it takes me hours to get back on track. I can't do design if every design decision takes hours or days to try-out; I need to be trying multiple things in a single day.

With an ES, no design-change takes more than "minutes" to implement and test *in the game*. Scripting languages used to help me a little - but a lot of the design changes I make require small changes to low-level systems - e.g. the renderer.

(for instance: changing the visual style. Makes a huge difference to the feel of the game, but it always ends up needing at least one change to your rendering)

@Catharsis - First off, let me say I hope your system works really well for all the effort you put into it. But your commentary, to me, makes a very strong argument against this direction.

Let's be clear: his "direction" is:

"Try everything, to the max, find its flaws and its shininess. If it is less than perfect, move on to the next thing. Time and money are no issue"

That's how Catharsis works. He has always worked that way - he was doing it 5 years before ES's were even mentioned.

Quote

Java is not a friendly language for building these kinds of systems.

Should you really care, though? The point of the ES is not

"how easy is it to write my own ES from scratch, ignoring all the public domain and open-source versions"

it's:

"how easy does the ES make it for me to write my own game from scratch, creating something new"

So long as people are unwilling to write Games, and instead focus on writing Engines and Libraries, there will continue to be a lack of Games.

Quote

Even a trivial change, like the addition of get/set sugar, would go a long way to making it slightly less painful.

The grass is always greener... I've written multiple implementations in Java, C, and Objective-C. Java is not the worst.

e.g. I spent a whole day last week trying to make this work in Objective-C++ (for a nice iOS ES). After a day, all I had was: - Damn, this is hard - Templates in C++ aren't quite powerful enough to do this easily, unless you can use a C00x compiler (which iOS doesn't) - ...Damn, this is hard.

I'm still trying to work out how to do it. A trivial implementation, that is worse than the Java one, was easy. But to make a small implementation that's "at least as good as the Java one" is proving difficult.

Quote

it's pretty much given that a scripting language will be part of the system

Or ... not. Scripting langauges are often over-rated in games-dev. Unless you've spent a lot of time with maintaining them in a live game, it's easy to read the literature and think they're "pure benefit". In practice, they bring with them a LOT of new problems, really nasty stuff in the long-run.

EDIT: and I'd like to hilight that - for me - spending "a whole day" on something is an incredibly long amount of time. Catharsis would probably say it doesn't even count as getting started - but for me, if something can't be completely done in a day, my gut reaction is: don't do it at all - move on, do something else, do something that can be finished quickly.

It's just one big blank grey window, until you drag resize it, at which point it flickers HORRIBLY between grey and the game, and when you let go, it just displays the game correctly, and it's fine from there.

So ... I think you need to look at your Java2D initialization, and also: that flickering on resize suggests you're not using J2D framebuffer correctly.

What is it? - Spare time game I'm writing at weekends, typically 2-4 hours at a time - Every day I work on it, even if just for a few hours, I'll make a new build and upload it - I'm *actively* prototyping the core game-design - it's interesting to see how many builds it will take before it becomes a "real" game, and how much I change my mind before I even get that far

Also ... for the programmers ... - It's using the public domain Entity System at http://entity-systems.wikidot.com/rdbms-beta with a few tweaks and improvements - anything I add I commit back onto the trunk, or I'll fork and add a new page to the wiki.

NB: the Entity Systems Wiki is intended to document the *simplest possible* ES's upwards - the ES used in this game is appallingly low performance, but amazingly even on phones it's good enough to do simple games. There are much better ES implementations out there, the wiki implementations are designed for other people to *learn* from, not really to be used in live games. I'm using this game as a testbed to add small increments to the wiki, so that other java coders can understand how an ES might - sensibly - evolve from a simple version upwards.

i.e. ... no, I really don't recommend you do this. Unless you want to understand how ES's work, in which case, go for it. And then, once you grok it ... grab someone else's bigger, richer ES and use that - don't re-invent the wheel!

In the end, I just hit the "get allocations" button like crazy until something big appeared, fixed that, then repeated.

Although it felt a bit stupid, I believe this took less time than faffing around with manual DDMS dumps, manual running of the hprof converter tool (what a joke that is - "hey, we broke the standard. And, uh, we're not going to fix it. But here's a commandline tool you can use to un-break what we broke! have fun!"), etc.

(NB: I recently tried to enable the Eclipse plugin that's supposed to handle live hprofs of all kinds - it's too broken, and there are no docs, just a couple of long boring youtube videos. I gave up at that point )

It's massively undefined (one of the many glaring holes in the OS docs for Android).

My impression is that it's a fairly naive scheduler, and on any thread context switch(es) it says to itself:

"Hey! You finished! Cool. I'll go do lots and lots and LOTS of OS-stuff now. I don't know much there is to do - I haven't actually been tracking it! HaHa! It'll only take me a few hundred milliseconds to check everything ... just in case... Bye now!"

You can pretty much create whole applications without even writing any code, do it all through gui, click a button and you have it all built and ready to go.

Sitting in Brighton, UK's biggest center of Flash developers (possibly Europe's?), when I go to Flash events and Flash conferences and Flash pub-socials ... the majority have long ago switched over to being completely coding-based development.

The toolset won the hearts and minds of many of the creative people who actually wanted to make stuff, and persuaded them to start with Flash. I still contest that the only difference today is that people who use Java to make games *mostly* don't actually want to make a game, they're just playing.

I feel you're shooting the messenger here: the problem is not the ES; rather, the ES merely exposes the real problem.

The problem is that most people doing java games don't actually want to finish their game. They make games for the joy of the "continuously writing code" part - not for the "shipping a final, working, version that other people play" part.

e.g. tonight I just made a new map for Warlight (http://warlight.net). I have never done this before, I didn't even realise it was possible until this afternoon.

By playing with the game design and rules, I was able to slightly subvert the existing game and make - effectively - a new sub-game, just by playing with a map editor. It's nothing revolutionary - but it's a different kind of fun.

Took me approx 3.5 hours to figure it out, come up with an idea, implement the idea, and put it live on the Warlight servers.

I'm more interested in "having new ideas for game designs" and "implementing those game designs, playtesting, re-designing until they're 'fun'" ... than I am in "writing reams of code". Writing code is fun, too - but my passion is making games, not making libraries.

As Cas gently points out, there was a time when I tricked myself into being a library-maker instead of a game-maker. After burning years of my life on something academically worthy - but shipping only one game (commercial, but embarassingly simple) - I eventually stopped lieing to myself, embraced what I *really* wanted, and started "making stuff and putting it into other people's hands". That's what I love doing.

PS: putting it into other people's hands is critical; you quickly learn how crap other people think your stuff is. You quickly give up completely, or learn to make things "good enough for everyone else". Very important lesson to learn, IMHO

@blah^3 - But I'm rather getting at why here, the nexus of Java games development, there's an awful lot of talk and not much trousers. The Flash developers have got it right. They concentrate on shipping, largely within the fairly strict confines of what is available in Flash to keep them quite focused.

Ah, I misunderstood, sorry.

Total agreement with you on both counts: for *here*, that's the problem, and *ship it, don't talk about it* is the essence of game making.

Quote

I don't think I'll ever agree with you about entity systems. At least, not until I a) start writing in javascript and b) start making the next World of Warcraft. Where an entity system would make the job easier. To the rest of you: you have Entities, and each entity will be one of Player, Bullet, Alien, Powerup, and EnemyBullet. This is almost exactly a perfect fit for inheritance. Now get on with the rest of your game!

That's because you're a NIH zealot .

My re-write of Amstrad CPC 464 Roland On the Ropes used IIRC 5 discrete entities, and it saved time doing it that way even with so few (because I re-used one of the tiny ES's on the wiki I linked above).

Anything larger than a 1985 Amstrad game (which was probably written in BASIC) and an ES should be making significant savings on development time.

If anyone reading this doesn't find that happen ... then you've missed the point, or you're doing it wrong - or you just suck at Game Design and need to find yourself a game designer who cares.

I can field this one. It's failed to take off because of the segments of game developers:

TL;DR: Follow the money.

On the whole, the people who are genuinely interested in making a living out of game development find it easier / more profitable to use "things that are not Java".

Either they should use Java but no stakeholder/owner of Java has ever bothered to persuade them otherwise ... or they shouldn't use Java, because no stakeholder/owner of Java has provided a viable JVM for them to use.

Java gaming has never really taken off in all that time ... I am sort of surprised actually, given the sheer levels of success of various games that germinated here on JGO, that more attention never got focused on Java as a solution for gaming.

I can field this one. It's failed to take off because of the segments of game developers: * Professional teams who know how to get publishing contracts and who specialize in desktop apps (i.e. not console): they already know C++, have C++ toolsets, and no-one ran a marketing campaign to change their minds. Microsoft spends $$$ every year persuading those people to "stay where you are" * 1-person Indies hoping to make a breakout success: Flash gives you 10x the opportunity on websites (e.g. Kongregate is still Flash-only. Any *new* indie developer who does NOT use Kongregate is a fool). * (recently) Indie teams trying to make cash out of iPhone: No JVM in the OS, and no-one of sufficient size/wealth offering to provide one (including all the support required). Meanwhile: Unity. If you want to use Java, you use Unity instead, and write in C# - it's similar enough that java developers feel at home.

EDIT: missed one, the segment that are actually using Java:

* 1-3 person "teams" that use Java but don't have a strong intent to finish / launch their game. Mostly doing it ("programming"/"developing") as a hobby - doesn't actually matter if they ever launch it. Although they tell themselves otherwise. If you don't believe me ... go speak to some Flash developers, find out how aggressive they are in *shipping* games, every single month (or more often than that)

Quote

A quick scan of the various topics that have come up over the last, oh, I dunno, year or so maybe, does point me in the direction of a theory or two as to why Java is failing to gain traction.

Firstly, this obsession with entity systems is...

...the chance of salvation for many of the small developers. For some definition of "entity system".

I'm inherently biased, but ... for MOST developers, the massive shortcuts in iteration time for game *design* that a good ES provides outweigh any and all downsides.

Forget performance; this lets you get 5 versions of your game design done in 5 days - instead of in 5 months.

Quote

I'll tell you this for free:

I've tried many different routes to achieve those things, and watched them be tried by other people's teams too. An ES - used sensibly - empowers you to do those things, and greatly increases the chances of you achieving them.

I feel you're shooting the messenger here: the problem is not the ES; rather, the ES merely exposes the real problem.

The problem is that most people doing java games don't actually want to finish their game. They make games for the joy of the "continuously writing code" part - not for the "shipping a final, working, version that other people play" part.

Quote

This is why Java4k is so good.

You should be able to design some pretty neat games and finish them on Android.

I recently wrote an Android game and started publishing the builds after every 2-3 hours of development. The first build was already playable (although completely boring) - because I used an ES. I've never had a game playable (from scratch) in less than about 12 hours previous to that.

So. The problem is not the (use of) ES. PEBKAC (Problem Exists Between Keyboard And Chair)

For most people - who just want to write stuff for iPhone (in addition to wahtever else they write for web) - it's only going to take a couple of days at most to learn ObjC.

Pretty much: learn how to use basic ref-counting, learn how to use Apple's rather crap @property syntax (and the bizarre rules about usage), learn the basic method calls for the Apple rendering libraries, and finally: learn how to write anythign at all in Xcode (the IDE you are forced to use).

I was shocked that it took me a mere 7 hours - from scratch - to write my first game on iPhone (including time taken to write my first hello-world App). It also took an extra 7 hours or so just to read various obj-c docs, so all in all I started one morning, and finished the following evening.

For comparison (I'm not a great nor an especially fast coder) that's about how long it took me to get my first game working with Slick.

So ... while I eagerly watch the experiments with Java->ObjC compilation, that really shouldn't hold anyone back from just learnign ObjC and going and writing some games *right now*. Especially given how easy it is to earn real cash from iPhone apps right now (it's very easy to earn a few thousand dollars per app; earning tens of thousands is hard, 100's of thousands very hard, and more than that is a lot of luck - even for huge dev teams (I know three teams that spent more than 400k dollars on iphone development and failed to make a profit)).

...or something like that. Typed off the top of my head, and trying to convert into java, didnt bother firing up eclipse, so where there are stupid mistakes try to ignore them

Quote

Also on a completely unrelated thought process, would other non game world objects like user interface objects be entities too?

If you want them to be part of the game, yes.

I would advise start off with them as "not", but you may decide to add them in later. Many games decide to merge UI and game sooner or later.

For instance, lots of games run the renderer in the background of the main menu, showing a simulated bit of game (AI battling it out on one of the game maps, for instance).

For instance, lots of games like to have the UI context-sensitive based on what's happening in-game: if the UI needs to read the state of game objects, and needs possibly to alter the state of game objects directly (e.g. "set the "selected" game unit"), then it's generally going to make life easier if the UI can "speak" directly to the entities.

But ... for the first time, this is hard enough already, I'd probably aim to keep them separate as long as possible, just to keep yourself as un-confused as possible.

Several Game companies are using existing Game Engines (Quake, Unreal), and build their game around that. It allows them to focus on making the game, not the architecture to make the game.There are advantages and disavantages to using a Framework. Flexible is important. What can some do with it, and can they expand it.

FYI: they have (mostly) *only* done this where it allows them to fire their entire game-engine-programming department, and spend the money saved on extra level-designers / artists / shader-programmers / producers / etc.

It's a very different world in the Unreal and Quake ocean. (and .. Quake? Who the heck uses Quake any more?)

I thought such remarks were beneath you? No need to be so patronizing.

Sorry - wasn't intended to be patronizing, I just badly phrased it: it was intended literally: don't touch an ES in that case - it will be more trouble to you than it's worth. But *if* you find yourself shouting "FSCKING OOP!" at your monitor one day ... that would be a good time to revisit this subject, and see if you feel differently about it (I supect you would).

Quote

public void perform(Entity entity, HealthComponent health) { // there is a 1:1 relationship between the entity and health object. // fields like health.min, health.max, health.current are 'bound' to this entity

if(health.isDying()) // this is code in the component - bad if(this.isDying(health)) // this is code in the system - better? // remove entity from the container else health.recover(); // this is code in the component - bad this.recover(health); // this is code in the system - better? }

By "code should be in the system", I mean that the physical location of your functions that contain that code is "inside classes that are internal to the system, not inside classes that define the java/OOP objects that are used as game-entities".

Depending upon how you call the perform method, it could count as either. If you made it explicitly static, then it could *only* be the latter - but you'd also be throwing away the on-the-ground benefits of OOP as a generic programming paradigm for writing those funcitons.

BUT ... from your code snippet, I think you fully understand what I'm trying to say here, so I'll shut up .

No, that convinces me that you've got it. In the light of this, I don't understand your previous statements where you said you wanted to revent to code-in-component, OOP style?

Quote

It just takes a while to get used to, and my preference for the code-in-component might just as well change sooner or later.

Have you tried writing a system where you write all the code in the system, not in the components? maybe attempting to do that will make it clearer what you don't like (or why you do, in fact, like it )

I found that I hadnt' realiased I had 2 or 3 different mutually incompatible "types" of OOP object in my architecture - there were the game-entities, the behaviour of metacode, and the internal represetnations WITHIN The systems of the PLACEHOLDERS for game-entities that the system was TEMPORARILY referrring to while executing.

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