Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (539)
Games in Android Showcase (132)
games submitted by our members
Games in WIP (603)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1] 2 3 ... 153
1  Game Development / Game Mechanics / Re: Entities and entity managers on: 2012-04-02 15:19:12
Is it worth building your own container classes for them?... or just using built in collections classes that Java has.

NB: if you're doing something SUPER intensive, but SUPER low-complexity (e.g. particle effects), then don't bother with containers, go straight to arrays/buffers. For everything else...

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 container
Second 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.
2  Game Development / Networking & Multiplayer / Turn-based servers + hosting - recommendations / experiences? on: 2012-03-04 15:59:42
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?

So far, I've been looking at:

- OpenFeint
- http://parse.com
- http://www.smartfoxserver.com
- Apple's GameCenter
- Amazon S3
- Amazon EC3

Pros/Cons I've seen so far:

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

http://www.smartfoxserver.com
 - non-hosted
 - some (very minor!) support for game mechanics - looks like about 10-20% ?
 - low lifetime cost (3k euro to unlock unlimited use)
 - lets you write a custom server, in Java

Apple's GameCenter
 - iOS only (no Android - would have to launch as iPad only, then start again for Android)
 - provides 95% of game mechanics
 - only allows one player to take a turn at once

Amazon S3
 - Like Parse, there's no active server - it's just a shared data store - so you have to write everything client-side
 - cheap and easy and very well known

Amazon EC3
 - less effort than maintaining a dedicated server, but otherwise "you have to do everything yourself"
3  Discussions / General Discussions / Re: FOUND! - Old ncSoft game that was built on jMonkeyEngine on: 2012-03-04 15:43:33
it looks really really good and has amazingly good graphics.
That looks too good!   Stare

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...
4  Discussions / General Discussions / Re: Releasing a small library on: 2011-11-25 09:51:51
Use SVN for starters. It's quite easy: http://code.google.com/apis/gadgets/docs/tools.html#Host

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.

So ... use github.
5  Discussions / General Discussions / Re: Still hardly any games, why entity systems suck, and why 4k is good on: 2011-11-25 00: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*.
6  Discussions / General Discussions / Re: Still hardly any games, why entity systems suck, and why 4k is good on: 2011-11-25 00: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.
7  Discussions / General Discussions / Re: Still hardly any games, why entity systems suck, and why 4k is good on: 2011-11-22 02:50:37
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)
8  Games Center / Featured Games / Re: Minecraft Officially Released! on: 2011-11-21 15:13:45
I don't know if Markus still reads jgo much these days, but congratulations man. It's freaking epic. Cheesy

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)
9  Games Center / Archived Projects / Re: (unnamed) Rogue Battle Chess (Android ONLY) on: 2011-11-21 14:29:20
Helpful to know if it runs at all though eh? Smiley

Indeed Smiley.

Quote
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 Smiley. 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)
10  Discussions / General Discussions / Re: Still hardly any games, why entity systems suck, and why 4k is good on: 2011-11-21 14:14:26
@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.
11  Games Center / Archived Projects / Re: (unnamed) Rogue Battle Chess (Android ONLY) on: 2011-11-21 13:53:58
But it did run, at least (30fps) (Galaxy 2 S, 2.3.4)

Thanks guys - really helpful!

PS: no need to post FPS and model - if you have internet access, each time you finish a level, it'll send a small ping to Flurry with the average FPS.
12  Games Center / Archived Projects / Re: (unnamed) Rogue Battle Chess (Android ONLY) on: 2011-11-21 13:50:25
Why the entity system?

What you see at the moment is approx 10-15 hours of design + art + development + refactoring + iteration.

Without the ES, that would have taken me 20-30 hours.

It's all about making sure I can get a game running very very early - and that *I can change the design rapidly*.

Quote
I had no idea what was going on, but it ran. Samsung Galaxy Tab 10.1

At the moment, it's not much of a game: you move around, you kill enemies, and pick up green/red potions to recharge your health.

When all the enemies are dead, there's nothing to do but hit the back-button and start again.

Or ... if you die before the enemies are all killed, it'll dump you back to the level-select.
13  Games Center / WIP games, tools & toy projects / Re: An Adventure Game on: 2011-11-20 23:53:22
Sound works fine on OS X, but ... the rendering is broken.

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.
14  Games Center / Archived Projects / (unnamed) Rogue Battle Chess (Android ONLY) on: 2011-11-20 23:26:18
Built for Android 2.1 - so should work on most phones

Download current alpha:
 - http://t-machine.org/wp-content/uploads/Chess-Quest-0.4.0.apk

Background info / about links:
 - http://t-machine.org/index.php/2011/11/21/prototyping-chess-quest-v0-4/

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 Smiley

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!
15  Game Development / Performance Tuning / Re: How to find the worst allocations in Eclipse w/ Android (Dalvik) JVM? on: 2011-11-20 22:20:34
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 Sad )
16  Games Center / LWJGL16k - 2011 / Re: SharpShooter16k on: 2011-11-20 21:08:53
Works great on OS X. Although I couldn't find anyone to shoot Sad.

+1 for the Webstart link - I wouldn't have bothered running it if I had to do more than click + hit "Allow"/"OK" a couple of times...
17  Game Development / Performance Tuning / How to find the worst allocations in Eclipse w/ Android (Dalvik) JVM? on: 2011-11-20 19:24:00
I wrote lots of sloppy code, quickly, to get a game up and running fast.

That's great, worked fine, but now (weeks later) performance has slowed down enough it's getting annoying, and I'd like to clean things up.

First, obvious, thing: I'm getting GC freeing 1.5 MB per second. That's a lot bigger than I expected, since I'm only running at 20 FPS.

Eclipse's DDMS view has an allocation tracker, but the frequent GC's mean I don't get to see what's allocating so extensively.

Any ideas on how to catch this? Or is it just a case of "keep hitting Get Allocations button until you see something unexpected" ?
18  Game Development / Performance Tuning / Re: Android threading vagaries on: 2011-11-20 19:16:37
it seems, forced to use two threads to run my game in.

Out of interest (I haven't bothered doing multi-core optimizations for Android yet) ... what were you expecting?

Quote
if it's the Android thread scheduler (which should be just plain ol' Linux thread sheduling)

IME: it's the Android thread scheduler, at least pre-3.0 (I vaguely remember that 2.3 or 3.0 upgraded the scheduler?)

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!"

...anyway, my early experiences were: go single-threaded, don't look back. I got fed up having the OS treat me so unpredictably Sad.
19  Discussions / General Discussions / Re: Still hardly any games, why entity systems suck, and why 4k is good on: 2011-11-17 14:55:36
I'd say this is mainly because their toolset is a lot stronger.

That used to be the case. Today, it is irrelevant.

Quote
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.
20  Discussions / General Discussions / Re: Still hardly any games, why entity systems suck, and why 4k is good on: 2011-11-17 01:53:59
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
21  Discussions / General Discussions / Re: Still hardly any games, why entity systems suck, and why 4k is good on: 2011-11-15 21:21:46

@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 Tongue.

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.
22  Discussions / General Discussions / Re: Still hardly any games, why entity systems suck, and why 4k is good on: 2011-11-15 21:18:10
Bonus points to anyone who implements a entity system in 4k  Grin

The smallest-possible implementation over at http://entity-systems.wikidot.com/ would probably fit quite well in 4k entry.

Although I wouldn't recommend it. With 4k, you're not iterating enough to really care about ES, IMHO.
23  Discussions / General Discussions / Re: Still hardly any games, why entity systems suck, and why 4k is good on: 2011-11-15 15:25:09
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.
24  Discussions / General Discussions / Re: Still hardly any games, why entity systems suck, and why 4k is good on: 2011-11-15 15:14:50
Logged in just to reply to this (hi, Cas!)

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)
25  Discussions / Business and Project Management Discussions / Re: Will the Java Platform Create The World's Largest App Store? on: 2009-10-28 11:53:56
I'd like to know more about this store - would someone please post some screenshots?

(as I'm not physically in the USA right now, I am "not allowed" to view the site, apparently)

Quote
The Java Store Beta Program is currently available only to U.S. residents, and will become available in other countries in 2010.
26  Discussions / General Discussions / Re: iPhone + kev g on: 2009-07-22 21:16:56
Learning Objective-C really isn't that hard, though.

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)).
27  Game Development / Game Play & Game Design / Re: Game Object Component System on: 2009-06-22 21:34:12
At the risk of inserting a noob question, can anyone show how (if at all) it could be incorporated in a "game" loop like the following:


while (running)
   {
   // tick something over   
   something.tick();

   // display something to the user   
   render(something);
   }



while (running)
   {
   // Let each system tick
   system1.tick( system1components );
   system2.tick( system2components );
...
   // ...or the obvious sensible way to do it instead
   foreach( system in systems )
   {
      Collection entities = getEntitiesForSystem( system );
      system.tick( entities );
   }

   // display something to the user   
   render( getEntitiesForSystem( getRenderableSystem() ) ); // I'm assuming you do animations inside your Renderables system
   }

   public Collection getEntitiesForSystem( ASystem system )
   {
      runSQLqueryToGetAllEntitesMatchingSystem( system.getUniqueName() );
   }


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

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.
28  Java Game APIs & Engines / Tools Discussion / Re: JGF - Java Game Framework on: 2009-06-17 15:39:05
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?)
29  Game Development / Game Play & Game Design / Re: Game Object Component System on: 2009-06-17 15:31:53
Well, that's what I make of it, and it certainly can be implemented that way, as I currently have it just like that.

Yes!

Quote
One nice thing is that you can have a 'ram container' and a 'sql container' and use the one that best fits your Component type, specified in a 'hybrid container'.

YES YES YES! Smiley
30  Game Development / Game Play & Game Design / Re: Game Object Component System on: 2009-06-17 15:30:11

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

Quote
Maybe this code clearly shows that I'm missing your point. (?) Maybe, but I'm fairly sure I'm going in the right direction.

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 Smiley)

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.

(the latter type being like template-programming in C++)

Have I made it totally and utterly obscure yet? Smiley
Pages: [1] 2 3 ... 153
 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

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

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

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

BurntPizza (76 views)
2014-12-08 04:46:31

JscottyBieshaar (37 views)
2014-12-05 12:39:02

SHC (51 views)
2014-12-03 16:27:13

CopyableCougar4 (49 views)
2014-11-29 21:32:03

toopeicgaming1999 (115 views)
2014-11-26 15:22:04

toopeicgaming1999 (105 views)
2014-11-26 15:20:36

toopeicgaming1999 (31 views)
2014-11-26 15:20:08
Resources for WIP games
by kpars
2014-12-18 10:26:14

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

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

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

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

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

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

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!