Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (487)
Games in Android Showcase (110)
games submitted by our members
Games in WIP (552)
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 ... 107
1  Game Development / Game Mechanics / Re: Excellent article on turn-based game loops on: 2014-08-05 08:25:30
Most of you know I'm a design-patterns-consider-harmful kinda person.  Now this author's design-patterns page is pretty good, but this is WTF.

Why on earth would one implement an action as a command-pattern?  Oh yeah because all of your problems must be broken into into a fixed set of cookie-cutter solutions.
Last time I wrote a roguelike, I found having actions as command-pattern hugely simplified the AI and GUI, since I could generate all valid actions, then just push that list to the UI (for humans) or AI (for NPCs) to make the actual decision of which to use.

Patterns tend to be overdone and overly formalised, but I think you're throwing the baby out with the bathwater here.
2  Discussions / Miscellaneous Topics / Re: Does Visual C++ run on multiple platforms? on: 2014-08-05 08:11:12
Today I filled in certain gaps in my java knowledge. I wanted to start using C++ since c# is a microsoft only language. I really like how Visual stuidios looks compared to other compilers but I'm seeing that it wont compile on a mac or linux. I did some reading that it wont compile on mac, but if I code somthing in Visual studios and export the project, will it work on all platforms(windows, mac, linux)?

You can write cross-platform C++ using Visual Studio IDE (no 's') and use the Visual Studio compiler and debugger to compile and debug under windows. You'd then take the same code and use a different IDE+compiler to build and run on other platforms like linux and mac (for mac, have a look at XCode).

The main snags are:
1. Unlike java, you'll need to compile separately on each platform. Cross compilers exist but for desktop platforms aren't usually that good. For big projects you'd typically have a build machine that runs different OSs in virtual machines to do all your builds.

2. It's much harder to write cross platform C++. There are very few cross-platform apis, and even the ones that are cross platform need hand tweeking with per-platform #ifdefs (eg. BSD socket code on windows uses *slightly* different types than on linux and osx). If you go this route you'll need to either write lower level code for each platform, or use a library (such as libpng) which provides cross-platform functionality for you. Additionally, different compilers have different quirks and handle standard C++ slightly differently, meaning you have to compile and test for each platform much more.

I would be incredibly careful about heading down this route. C++ is exceptionally low level, and writing a full game requires a *lot* of system level functionality. You *will* spend at least half a year just getting a basic pong game compiling and running identically on windows/linux/mac.

What problem are you looking to solve, exactly?
3  Game Development / Networking & Multiplayer / Re: Game server and database interactions on: 2014-06-27 12:12:36
^

I was thinking about saying the same thing, but then I realised that the OP was asking when THE SERVER should STORE DATA in the DATABASE.

You're right, I completely misread the initial post.  Lips Sealed
4  Game Development / Networking & Multiplayer / Re: Game server and database interactions on: 2014-06-27 11:54:10
If you don't want item duping, then you have all actual item interactions take place on the server, then sync the client to the latest server state whenever it changes.

If you sync the inventory on login and logout you're asking for all kinds of item dupe bugs/exploits. The *only* place to reliably pick up/drop/discard/trade an item is a transaction on the server.
5  Discussions / General Discussions / Re: Component Systems: Artemis style systems vs. traditional fat entities on: 2014-06-27 10:02:56
Ok: I wasn't going to say anything but  I can't resist.  Why are you attempt to over-engineering your problem?  Focus on what "must" happen, what you can fake and how data is manipulated.  Much easier to think about and to write.

Don't me distracted by the number of components - the actual code here is remarkably simple, mostly a handful of very decoupled systems. Similarly the data flow is simple, as is the actual object hierarchy. It's just not as efficient as I'd like, and making it more efficient is probably going to sacrifice some of either the simplicity or the decoupled nature of the independent systems.

Just because I can talk verbosely about the particular design trade-offs currently in the system doesn't mean that the current state of the code isn't simple and straightforward. Tongue
6  Discussions / General Discussions / Re: Component Systems: Artemis style systems vs. traditional fat entities on: 2014-06-27 08:26:41
I'll get back to the other replies in a minute (they need proper thinking about), but:

Even so I'm still wondering what an ECS is useful for in this scenario.

ECS is giving me a lot of options for making new world entities very quickly. For example a planet is made from these components:

Entity
 + NetworkId
 + ReplicationId
 + Transform
 + Radius
 + Colour
 + NavBlip

An asteroid:

Entity
 + NetworkId
 + ReplicationId
 + Transform
 + Velocity
 + Physics
 + Radius
 + Colour
 + Transient
 + NavBlip
 + Health

And a player ship:

Entity
 + NetworkId
 + ReplicationId
 + Transform
 + Velocity
 + Physics
 + ThrustControl
 + NavComp
 + Stations

I may have sliced these too finely - as I said this was a bit of an experiment in using Artemis.
7  Discussions / Miscellaneous Topics / Re: What I did today on: 2014-06-26 13:45:48
Radial blur god rays, made popular by Crysis, only rely on the limited screen space information available.

The original Halo did radial blur god rays way before Crysis. Smiley
8  Discussions / General Discussions / Re: Component Systems: Artemis style systems vs. traditional fat entities on: 2014-06-26 11:29:28
Orangy, how about you describe your current game to us?

Sure. The basic concept is 2d elite-lite with local multiplayer. Fly around a procedurally generated galaxy and shoot stuff. And some other special stuff that's secret right now Wink

My initial annoyance came from trying to sync all of the floating asteroids in the galaxy across the network. A naive component solution involves a component that tests if the transform has changed, and if it has replicate it over the network. Obviously this spends a lot of time doing redundant checks. Additional annoyance - ideally objects near the player should be updated more frequently to use network bandwidth more efficiently. Right now I've a crude coordinate hashing thing doing that, but crowbarring in some kind of quadtree would certainly help.

A more traditional entity system (ie. non artemis), or even a non entity system approach would be much simpler by entities pushing themselves onto a 'dirty' list when their position is changed, and blatting through that every frame. That's harder to do cleanly within artemis without violating some of the constrains - either components have to become non-dumb, or things like the physics system have to become aware of the network system and push change notifications between each other. These are not terrible things, but highlight a wider issue where a 'pure' approach leads to less efficient behaviour.

An additional snag is that gameplay-wise I have to sync all of the objects because the player can see them all of the time - think always-on mini map which spans the whole galaxy (it's more complicated than that but that would be too awkward to explain fully).

One thing that's become apparent is that people write components in *very* different ways:

1. huge monolithic components that are basically just like their original pre-ECS entities. Minimal changes to wrap your head around, but misses the benefits of combining logic components in interesting ways. Still gets you good stuff like easier editor integrations etc. though.

2. Chunky components that handle their logic and communicate with other components in defined ways. Nicer to combine but quite a change that seems to take people at least a few months to wrap their heads around and do properly.

3. Thin, data-only components and aspect-like systems that updates some combination of components based on what's present (or not) in a single entity. Great for really breaking things down into tiny pieces of logic and making dependencies super-explicit (and avoid a lot of the config problems of 2) but makes communication between components and systems hard (without resorting to flags and polling).

4. Components as ids into external systems. Tends to happen a lot when integrating some 3rd party library - physics being a good example. The component becomes a proxy for the actual data (possibly just an id/pointer) stored in an external system. Nice because the external system doesn't really know/care about the component system, and the rest of the game gets a nice clean component interface to interact with.

1, 2 and 4 are largely interchangable within a single project, which is awesome. But 3 very much expects a different data model so it seems not really compatible with the first two approaches. Often I think discussions about ECS tend to be very polarizing because people have either decided one way is the 'best' way, or don't even realise the other ways exist. Similarly I wonder how many people have been turned off them because they've been exposed to one style and assumed all other ECS are like that (in particular the artemis / style 3 approach is *hugely* off-putting on first encounter and requires a pretty huge mental shift in approach).
9  Discussions / General Discussions / Re: Component Systems: Artemis style systems vs. traditional fat entities on: 2014-06-26 09:53:45
Games just contain too much logic to take advantage of this. We just don't use data trees enough to get the power data driven architecture like ECS gives. In games, ECS will always be overkill because let's face it, not all aspects of a game is data. We just use data to assist logic structures. In logic and gaming, the fastest path is always the best one. Sorry entities, but your piping path takes too long...

I utterly cannot parse what on earth you're trying to say here. It sounds like you're making the usual mistake and focusing on ECS as cache-optimal design, and not from a general architecture/organisational view.
10  Discussions / General Discussions / Re: Component Systems: Artemis style systems vs. traditional fat entities on: 2014-06-25 08:42:28
Quote
The problem isn't so much with entity systems per se...
My view is that it is.

Then this is not the thread for you, sorry.

We have lots of threads on the merits (or otherwise) of entity systems, or you can start another yourself. This is not that thread.
11  Discussions / General Discussions / Re: Component Systems: Artemis style systems vs. traditional fat entities on: 2014-06-25 08:02:39
In any case I'm a bit perplexed by the use of an entity system and then coming up with problems... rather than the other way around. I had thought that the problems would be driving the development of a solution. I must be old fashioned too.

Cas Smiley

The problem isn't so much with entity systems per se, but with the Artemis entity system's way slicing things makes some things easier, but a few things harder compared with a more traditional entity system (the Artemis website clearly states that it's a bit of an experiment to see if this alternate way is better or not).

As I said before, I think entity systems solve more problems than they introduce, but if you're happy with other (equally valid) approaches, then that's fine too.

Since as far as I know you've not used a traditional entity system, nor have you used Artemis, and you're happy with what you're already doing, why are you grumping up a thread about comparing the two?
12  Game Development / Artificial Intelligence / Re: A* Multiple paths to goal on: 2014-06-24 08:07:17
Here's an idea:

Rather than passable/impassable for your tiles, have a 'cost' associated with moving through them. Impassable are +infinity, and initially all passable tiles start with cost 0. Then:

1. Find the most optimal path considering the costs with regular A*
2. Store that path as a possible path
3. For every tile that the path touches, increase the cost of traversing that tile.
4. Repeat until you have 'enough' paths.

This effectively means that every path after than the first, it's 'harder' to take the same route as an existing path. Note that you don't set the tiles to impassable, as you still want the tiles to be used if there's no other option (like the tile immediately right of your green start square).
13  Discussions / General Discussions / Re: Component Systems: Artemis style systems vs. traditional fat entities on: 2014-06-24 06:59:43
Marker components aren't *that* expensive, normally. Where and why is your CPU time consumed - because of a high entity count, sporadic insert/remove bursts, something else?

For my situation it's a high (+500) entity count that I'm trying to keep running at 60hz on android, so the cpu is a bit limited to start with. It absolutely flies without even trying on my ancient desktop, but not so on android.

Mostly I'm seeing a significant amount of time burned in just entity/component iteration, looping over entities to check if things are changed and pushing data from one component to another. It's not that this is bad per se, it's just that it's unnecessary work eating up my cpu budget, especially when most of the entities aren't visible right now but due to the nature of the system it's hard to not process everything all the time.
14  Discussions / General Discussions / Re: Component Systems: Artemis style systems vs. traditional fat entities on: 2014-06-23 22:19:10
One solution might be a custom EntitySystem to which you manually insert entities that need to be processed as a result of some state.
Yeah, I've seen this solution a couple of times. It kinda makes sense, but the resulting code is definitely harder to read, and adding an entire new EntitySystem for this behaviour is pretty heavy in terms of boilerplate code for what really should just be a method call.

It probably depends how finely you slice up your logic though - if you have bigger, chunkier entity systems that do more than you don't need signalling flags as much, but then you're left with more specialised code and you veer toward the Blob system that does everything.
15  Discussions / General Discussions / Re: Component Systems: Artemis style systems vs. traditional fat entities on: 2014-06-23 21:23:12
Good stuff!

Lastly, to respond to the OP and fat components; it's certainly doable, but it tends to make the code a little more rigid and hence harder to refactor.

Yes, I am seeing a bit of this - an artemis-style system seems to be optimal in terms of code reuse and flexibility, but I'm seeing that come at the expense of some readability and having to resort to polling behaviour over event-driven code.

Of course there's nothing to stop me putting event-driven code into the thin components and mixing the two approaches, but I suspect that would get messy and confusing quickly.
16  Discussions / Miscellaneous Topics / Re: What I did today on: 2014-06-23 21:08:30
I started writing the preferences dialog for a profiler I'm working on.

I'm continuously staggered at how ugly even basic stuff in swing looks.  Undecided
17  Game Development / Game Mechanics / Re: Vector4f on: 2014-06-23 21:05:02
Homogeneous coordinates

Quote
Homogeneous coordinates have a range of applications, including computer graphics and 3D computer vision, where they allow affine transformations and, in general, projective transformations to be easily represented by a matrix.

Short answer: Unless you're writing a renderer from scratch, you probably don't need to know right now.
18  Discussions / General Discussions / Re: Component Systems: Artemis style systems vs. traditional fat entities on: 2014-06-23 21:03:31
I think entity systems often confuse two separate design goals - being cache-friendly, and managing the complexity that comes with lots of different object types and gameplay behaviours.

On the first, I agree that entity systems tend to be overkill for client programming, particularly for Java where you can't precisely control memory layout, so cache coherency is mostly a guess anyway.

The second however I'm firmly behind. Any game of moderate complexity really benefits from the separation of gameplay features that an entity system brings. Yes, there are other approaches that yield similar results, and that's fine, but the component system seems to work pretty well and other people are instantly familiar with it which is handy as well.

Entity systems also really pay off when you've got multiple gameplay programmers trying not to step on each other's toes, or designers who put your components together in interesting ways and come up with behaviour you hadn't even thought of yet.

However I'd rather not debate all of that - if you don't want to use an entity system that's fine, but I'd like to discuss the higher level approaches people are taking to their entity systems.
19  Discussions / General Discussions / Component Systems: Artemis style systems vs. traditional fat entities on: 2014-06-23 13:53:09
I'd like to start a discussion on how people are currently using entity systems, and how they're structuring them. I've personally moved away from traditional inheritance-heavy ('old') game structure a while ago, but only recently tried using a more formal entity system to handle the gameplay logic side of things. I've also had two projects running concurrently, one using Artemis which uses 'thin' components (like the position example here) with no logic and just uses systems to do the logic, and one built in Unity, which uses a more 'traditional' approach where the components are 'fat' and contain their state and logic.

Initially I really got along with the Artemis style, defining aspect-like systems really helped with functionality that spanned multiple component types. However the more I use it the more I feel like I'm butting up against limitations. Often I'll end up having to set flags in components in one system for another system to pick up on later, resulting in lots of polling-style code and the inability to have much event-based gameplay code (at least, without doing some slight mental contortions).

Of course, I could just use Artemis and write 'fat' components, which is what I'm going to do as an experiment in my next project. But I'm wondering what other people have made of the thin vs fat approaches, and if one really paid off one way or another.

The polling style wouldn't be too bad except on android it *really* sucks up a lot of extra cpu time, just to enforce a seemingly arbitrary design separation. (Yes, I'm aware of artemis-odb and will be switching to that soon). Along with that, some task that feel like they should be simple end up being much harder than they should be.

Artemis still lists itself as "an experimental framework based on an experimental concept". Do you think the experiment is a success or not?
20  Game Development / Newbie & Debugging Questions / Re: Problem with detecting 2 different things! on: 2014-06-21 10:13:02
[slightDerail]
What purpose would you have to use a logical/bitwise &? I mean, if & checks both(or all) conditions, but && checks them 1 at a time, and gives up when it fails, how is that functionally different to your program? I can't think of a reason why you would want to continue checking the rest of the conditions if even one failed, because if one failed the if statement will fail anyway? Kinda seems like a waste of processing.

Having said that, that means I guess the most logical way to order your IF (condition && condition) statements is to have your least CPU intensive check first, and most last.
[/slightDerail]

If all of the things being checked are boolean values then they're functionally identical. You'll get differences if the blocks are function calls instead. Consider:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
class Player
{
  int x, y;
  int vx, vy;
 
  boolean moveAndCheckIfDoor()
  {
    x += vx;
    y += vy;
    return x == 0;
  }
}

// elsewhere
public void update()
{
  if (player1.moveAndCheckIfDoor() && player2.moveAndCheckIfDoor())
  {
    // do door stuff
 }
}


Here because moveAndCheckDoor() has side effects, you'll get different behaviour depending on whether short circuiting takes place or not.

Although personally I'd strongly suggest *not* writing code like this, sometimes this kind of behaviour can creep in more subtly without you noticing.
21  Discussions / Miscellaneous Topics / Re: Losing projects on: 2014-06-13 15:07:41
#1 Rule: Don't delete anything unless you've rewritten identical functionality in a better way. You'll never know if you might find a use for it again.

Or, you know, just use a source control system. Svn, Git and Perforce are all available in free flavours with integration with your favorite IDE.
22  Game Development / Newbie & Debugging Questions / Re: [LibGDX] Shader problem is beginning to piss me off on: 2014-06-11 13:42:35
AND I also had to use the "color" variable so that it wouldn't get optimized out. So, my current fragment shader looks like this:
Unfortunately this is a GLSL issue - if an attribute isn't used, then the compiler is free to completely remove it. There's no requirement for the driver to still expose a dummy attribute that doesn't do anything. I'm not sure I agree with that but that's what the spec says.

I would guess that libGDX is now actually reporting when you try and set an invalid attribute rather than blindly ignoring them like it did before.
23  Game Development / Newbie & Debugging Questions / Re: XBox 360 controller rumbers on: 2014-06-09 10:13:28
I have a feeling this is a commonly asked question, how can I get Xbox 360 rumblers to work?

Short version: you can't, sorry. Blame Microsoft. Sad

Long version: On windows there are two input APIs: the older DirectInput, and the newer XInput. DirectInput has been around for ages, and pretty much all controllers use it and are supported by it. It worked great, but it was a bit complicated due to supporting lots of different device capabilities (dpads, analog sticks, sliders, buttons, flight stick hats, vibration, etc.).

When the 360 came out, MS also released the XInput API. It's a simpler input api largely built around the 360 input devices, and works on Windows and 360, to make it easier to port games between the two. The 360 pad on windows can be used under each device, *but* to try and drive XInput use, the 360 pad is somewhat nerfed if you use DirectInput, and you can't use the rumble if you're talking to it via DirectInput (IIRC you also can't get all of the button states, and you can't talk to the center ring leds, or get the battery status). If you use XInput you get all functionality, but you can only talk to official 360 pads.

LWJGL only uses DirectInput, so you get nerfed 360 support. Which is a shame, but writing an entire back-end for one controller kinda sucks.
24  Discussions / General Discussions / Re: Apple announces new graphics API: Metal on: 2014-06-04 17:16:47
Seriously, people. Apple is not going to drop support for OpenGL.

People said the same thing about Flash.
25  Game Development / Performance Tuning / Re: Cache locality and LibStruct - fixing Java's horrible memory layout on: 2014-05-28 12:43:26
LibStruct is developed by me - theagentd plays around with it, yelling at me when it breaks again (and again). I'm his main cause of hair loss these days.

Portability wise, you're bound to the all powerful HotSpot VM.
Ah, I didn't realise that, sorry :S

Anyway, could you provide a bit of an overview of what it's doing under the hood? Or point me somewhere about it? I remember reading your posts about such hackery a while back but didn't realise you turned it into a proper working thing. Smiley
26  Game Development / Performance Tuning / Re: Cache locality and LibStruct - fixing Java's horrible memory layout on: 2014-05-28 12:16:55
theagentd: Could you post a high-level description of what's actually going on under the hood on libStruct? I'm guessing you're generating bytecode to do some of this? What does that do for portability (I'm thinking Android and libGDX/iPhone platforms)?
27  Game Development / Performance Tuning / Re: Parsing Android profiler trace file format on: 2014-05-28 11:19:08
Turns out there isn't any open source code for parsing this (or none that I could find at any rate). I did however track down the Android class that generates it: http://code.metager.de/source/xref/android/4.1.1/dalvik/vm/Profile.cpp

Which means I've now extracted enough of a spec to parse it, and have started writing a profiler (because all of the current ones for Android suck for games where you're trying to optimise in a very different way). Hopefully I should have something usable in a little bit, and I'll post it here for people to try out.

If anyone has any general thoughts on profiling for games wrt. Android, then feel free to dump them in this thread.
28  Game Development / Performance Tuning / Parsing Android profiler trace file format on: 2014-05-24 16:35:01
Does anyone know if there's any open source code to parse Android trace files (as generated by startMethodTracing? There's a bunch of tools for reading the files, but I can't find any code to just parse them to do my own analysis.

Thanks.
29  Java Game APIs & Engines / OpenGL Development / Re: FloatBuffer and Batching on: 2014-04-07 13:16:08
The Hotspot VM is supposed to intrinsify the put() call such that it should be identical in performance to the float[] access... maybe this isn't happening for some reason?

Cas Smiley

Last time I did this it was indeed roughly identical... on desktop VMs. The android vm was much, much slower and combining everything into a big float[] was way faster. Probably why libgdx is doing it this way too.
30  Game Development / Game Mechanics / Gameplay movement: physics engine vs. hand crafted on: 2014-02-26 00:50:33
I'm currently prototyping a 2d spaceship flying/combat game (think Asteroids meets Elite) and I'm looking at various ways to control the ship and how the movement works out. At the moment I've got a simple mock up using Box2d, a single dynamic body for the ship and thrusters that work by applying forces to the body. This works, but feels pretty crap.

Obviously I'm going to tweak this a bit right now, but it leaves me with the same lingering question I had at the beginning - is it ever a good idea to use a physics engine for the central gameplay movement / control which the player will interact with? Often physics-based games feel either laggy or floaty (eg. compare Little Big Planet with Mario Galaxy). But it does mean you get much more emergent behaviour (like proper torque when objects collide, and player's physics triggering physics reactions in the environment). And using a physics engine tends to get you more behaviour 'for free' which is often a big win when it's just a one person project. But it's very hard to get that proper responsive 'arcade' feel with a physics engine.

What are everyone else's thoughts? Do you prefer to go one way or another or does it depend what you're implementing and how it should feel? Have you ever got better results using (say) Box2d over implementing it yourself, and did it feel good to control?
Pages: [1] 2 3 ... 107
 

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

The first screenshot will be displayed as a thumbnail.

CopyableCougar4 (23 views)
2014-08-22 19:31:30

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

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

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

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

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

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

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

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

Norakomi (41 views)
2014-08-06 19:49:38
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

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

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

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

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

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

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

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