Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (109)
games submitted by our members
Games in WIP (537)
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]
1  Game Development / Game Play & Game Design / Re: MVC pattern on: 2004-10-05 17:42:38
In my case, I'm the only developer, so no communication problem.  In general, I find that if you can establish one sensible, robust pattern, and then use that over and over again, your system will be pretty easy to get around for new coders - once they understand the major pattern you're using.
2  Game Development / Game Play & Game Design / Re: Pathfinding in multiplayer online games on: 2004-10-01 16:55:20
I just want to emphasize what others have said - don't confuse path finding with execution of the movement.  Let the client find the best path it can with the information it has now, and let the server worry about whether the path is valid as the avatar moves.
3  Game Development / Game Play & Game Design / Re: MVC pattern on: 2004-10-01 16:46:52
My first cent - never forget that the purpose of all these software design patterns is to make life easier for the people actually writing and maintaining the code.  They aren't for performance, or for software correctness, etc.  If you're working on a solo project, use the patterns in whatever way makes the most sense to you.

Second cent - I've been using a pattern like this lately, which is MVC-derived and pretty useful.  I have four types of classes - Game Objects (Model), Renderers (View), Managers (Controller - pt 1), and Controllers (Controller - pt 2).  

Game Objects for the most part are just data structures.  I usually have one class of these per entity in my world - in my case characters, towns, dungeons, etc.  Getters and setters abound

I typically have one renderer for each 'screen' - so one for the menu, one for drawing the 'in town' display, one for drawing the 'world map', etc.  Renderers just takes a list of relevant game objects and draws them to the screen.  They have logic, but it's all focused on rendering - culling, etc.  Right now I just have renderers running in their own thread, but you could synchronize them with the game loop.  Renderers may have data structures that parallel Game Objects (such as vertex data), but I try not to put that data into the Game Objects themselves.

Managers conceptually should contain all the game logic.  Lately I've been orienting these around game states - which correspond to screens - same as renderers.  There is one master manager that keeps track of game state and calls an update method on any active 'children' managers.  

What I call 'Controllers' are assigned to any autonomous entities in the game world, and are responsible for choosing actions for the entity they represent.  So the player's Game Object, and any monsters or NPC's are each assigned a Controller.  Controllers are responsible for querying the world around their assigned entity, formulating a good action, and returning that to whichever Manager class is asking for an action.  Controllers have no ability to update the world - they just return instructions to a manager class such as 'Walk North' or 'Open Door'.  The manager class is responsible for checking the validity of this instruction and actually moving the game object or opening the door.  

There is one special controller for the player that basically maps keyboard and mouse events to instructions in the controller 'instruction set', which may be returned to a manager class.  If you're making a turn based game, you have the player controller stall until the user enters an action.  If you're making a real time game, you have the player controller just return NOOP if the player isn't pressing a button or whatever.

So the basic idea is that you have all these Game Objects that represent the things in your world.  Alone these objects don't do anything.  You add on top renderers that show a list of game objects.  The list of game objects they display may be limited by a manager class (to eliminate nearby but hidden enemies for example).  You add on top of this a layer of manager classes which are responsible for updating the game state (Game Objects).  Finally, controllers are responsible for *suggesting* to the manager classes how to update the game world.

Anyway, that's the architecture I've been using lately.  I've found this model very flexible and easy to extend.  Let's say I want to add gravity to my world - that belongs in the manager class ONLY.  I may choose to enhance a controller class to compensate for gravity, but that's an independant chunk of work.  Let's say I want to improve pathfinding - I add that to a controller class.  If I want to switch to a different rendering engine, I swap out the renderer class for the relevant game state(s).  If I want to make the game network enabled, I just create a new proxy controller class which communicates across to some client over the network (which is of course not at all a trivial task).
4  Game Development / Game Play & Game Design / Re: Geographically large game-worlds on: 2004-09-30 17:21:09
Thanks for the good input.  I should have mentioned up front that I'm working on a single player RPG, but many of the concepts from the online games apply.  Here are the things I've picked up which I'll try to incorporate into my game....

- Travel should never feel like a chore.  The designer needs to ensure that travel is either skipped or made worthwhile
- The game should provide 'short cut' option to skip over routes the player traverses frequently (with a pretty low threshold on the definition of 'frequently')
- When you do force the player to take the scenic route, be sure to present the player with things to do (encounters more interesting than random wandering attack sparrows)
- Free instant travel will dilute the experience of a large game world.  Make the player pay for the service (doesn't need to be a high cost - just enough to make the player think before jumping through the teleporter)
- Instant travel options should make sense in the context of the game world.  Travel that is instantaneous for the player may take a fair amount of time in the game world.
- Make sure the player doesn't get lost.  The big problem isn't so much not knowing how to get where you want to go - the real problem is not understanding the significance of going north as opposed to south.  While this is more a consequence of open-ended game design than a big world, the two go hand in hand.  Give the player some way of really orienting themselves.

Thanks again for the input.  Here's one other link I found that is related to the OP...
http://www.gamedev.net/community/forums/topic.asp?topic_id=261605

5  Game Development / Game Play & Game Design / Geographically large game-worlds on: 2004-08-17 21:59:55
I'm working on an RPG that I'd like to be fairly realistic, and I'm a little worried about inducing travel boredom on the player.  By realistic, I mean the world will be large, and travel will generally be slow (i.e. foot or horse).  Travelling between points of interest would generally take about 5-15 minutes in real time.  

I want travel through the wilderness to be a bit of an adventure in itself.  I'd like setting out for a new location to require a little planning and a induce a little trepidation.  But I don't want the wilderness travel to feel stale or tedious.  The only solution I've come up with so far is to give the player a quick-travel option to places he's been before, with the possibility of random encounters interrupting the travel.  Travel to new locations would still require walking.  To keep with the theme of the game, the auto-travel would be presented as a time-compression kind of thing, no magic portals or teleportation.

Has anyone played a game that implemented travel in a large world really well?
6  Discussions / Miscellaneous Topics / Re: JavaOne on: 2003-06-04 20:48:08
Chief Gaming Officer - not too shabby Chris!  I hope they give you hordes of minons along with the cool title.
7  Java Game APIs & Engines / Java 3D / Re: custom LOD subclasses on: 2003-05-06 21:37:16
isn't there something called a SwitchGroup that does that exact thing (allow you to pick one of several BranchGroups)?  I'm not very familiar with the LOD classes, so maybe it does some other nice things for you too that the SwitchGroup (or whatever it's called) doesn't.
8  Java Game APIs & Engines / Java 2D / Re: Questions about the way Java handles graphics on: 2003-05-02 14:39:07
its just my cheap work laptop.  its something like 800mhz.  i tried it at home and got much better results.
9  Java Game APIs & Engines / Java 2D / Re: Urgently need basic 'asteroid' code! on: 2003-05-01 20:16:43
does it have gas?
10  Java Game APIs & Engines / Java 2D / Re: Questions about the way Java handles graphics on: 2003-05-01 19:26:54
Egon - I checked out your globe (very pretty).  I was getting ~18 fps on my machine.  How does that scale with increasing window size?  If you displayed the same globe in a window twice as wide & high, would the fps drop by 4x?  A while ago I was doing some pixel plotting for a voxel engine.  It was fine when I had a small window (300x200), but once I got to a size usable for a game, it ran terribly slow.  (or slowly, one or the other)  
11  Java Game APIs & Engines / Java 3D / Re: Down with J3D, Software rendering rules! on: 2003-04-24 17:14:41
EgonOlsen alluded to this, but I think it bears repeating - different technologies/approaches are best for different games.  For example, if you're writing for hardcore twitch gamers, you'd better be taking advantage of as many video card tricks as you can.  If  you're writing a game in one of the many genres that doesn't carry the expectation of flashy graphics, awt is all you need.  It's an important design concept, rarelt is there a generically best choice - what's best depends on the context.  

On another note, how good a game looks probably depends far more on how good your artist is than the technology you use.  A 2D game with good sprites/backgrounds/menus will look far more attractive than a 3D game with three repeating textures.

12  Discussions / Miscellaneous Topics / Re: Rogue class file - Outer$1.class on: 2003-04-24 16:36:14
It's a class generated to send information to the CIA.  That's why when you decompile it you dont see anything.  True story
13  Java Game APIs & Engines / Java 2D / Re: special character problem on: 2003-03-25 14:50:18
Have you found a nice way to compute the size of a string?  I tried to once, it was nasty.  You have to walk a long road - font, font metrics, etc.  Has anyone found a nice way to do that?
14  Discussions / General Discussions / Re: Contest ? on: 2003-03-20 12:57:46
Hey Chris, any word?   This contest sounds like a lot of fun, I'd hate for it to get delayed indefintely waiting for some cool prizes.  It sounds like the group had pretty much sorted out some good rules for the contest - why don't we just officially start it?

Game on!
15  Java Game APIs & Engines / Java 2D / Re: align algorithm for org chart on: 2003-03-17 21:04:47
maybe its an org chart for a division of space marines?  Tongue
16  Java Game APIs & Engines / Java 2D / Re: 2D graphical GUI on: 2003-03-17 15:48:35
has anyone tried building a custom swing look&feel implementation?  It looks like nasty work, but at least you'll get to keep all the event handling & controls swing provides.
17  Java Game APIs & Engines / Java 2D / Re: Terrain on: 2003-02-18 18:28:06
The three common pseudo-3D techniques I know of are isometric tile-based engines, ray casting engines (ala wolfenstein/doom), and voxels.  the ray casting engines are realy designed for indoor settings, so you can probably ignore them.

Isometric tile-based engines are reasonably easy to write.  Someone mentioned populous, I think they used this model.  The older XCom games also used this to good effect.  Basically, you draw your tiles with an offset along the (screen) y-axis based on how 'high' the tile is.  The trick is to make the altitude transitions look nice, no staircase effect.  I think gamedev.net has a whole forum dedicated to isometric engines.

Another pseudo 3D technique you could look into is voxels.  The nice thing about voxels is they can be very smooth & good looking.  But they have lots of problems - they are memory and CPU hungry, and CPU usage scales very quickly as you increase your image resolution.  I spent months trying to get a decent voxel engine running in Java and it was pretty tough.  My final results were pretty good looking (IMNSHO), but it ran too slow to use in a game (~20 fps on a 1.2 Ghz machine).  That's not to say it's impossible, just probably not worth the effort.

Sorry I never played C&C so I can't comment on that.  From some screenshots it looks like the 3d appearance just comes from the way the artists drew the maps.  If elevation affects combat they probably store a second bitmap (heightmap) with the elevation at each point on the map.
18  Java Game APIs & Engines / Java 3D / Re: Where to start with 3d on: 2003-02-13 19:22:05
I used the Sun J3D tutorials at http://developer.java.sun.com/developer/onlineTraining/java3d/

The tutorial is a little tough to navigate, but it's pretty good, and covers the API pretty broadly.  I copied and adapted some code from chapter 7 to get some textured planes moving around.
19  Games Center / Archived Projects / Re: F-15 Strike on: 2003-02-12 15:29:00
Quote
Is there any programatic way I can tell if a Linux box can do full screen mode?


Can't you use GraphicsDevice.isFullScreenSupported?
20  Java Game APIs & Engines / Java 3D / Re: Where to start with 3d on: 2003-02-12 15:05:04
I tried getting into java3D several times without success.  I think I tried to do too much at once.  What finally worked for me was to create a 2D game using java3D (textured squares for my tiles & sprites).  Anyway, it helped me get into java 3d, maybe an approach to try.
21  Java Game APIs & Engines / Java 2D / Re: Terrain on: 2003-02-11 17:56:55
Are you familiar with fractal terrain?  It sounds like a good fit for your needs.  There are many different techniques that fall under the umbrella of fractal terrain, but they generally all use rather simple algorithms, repeated many times to produce a 2D array of elevations that look very realistic.

Another technique that will work if you will have a set of predefined maps is to use a decent paint program.  Most of the good ones can create 'plasma clouds'.  These can be saved to a file and again read as 2D arrays of elevations.  Nice thing here is you can edit the heightmap by hand.  If you have Gimp, check out Filters/Render/Clouds/Solid Noise.  

In either case, the tricky part is then to 'decorate' the terrain.  I've been able to generate good looking terrain, but when it comes to placing buildings, forests, roads, vegetation, etc, I don't have any advice to offer.
22  Java Game APIs & Engines / Java 2D / Re: Terrain on: 2003-02-10 13:45:46
What do you mean by the bitmap comment?  That you don't want to have to draw your terrain by hand, or that you don't want to have to dedicate a lot of storage to the details of the terrain at runtime?

What perspective are you using?  Isometric?
23  Java Game APIs & Engines / Java 2D / Re: game backgrounds on: 2002-12-11 16:14:49
I found a bunch of tile graphics on some sites for build-your-own-rpg applications.  I think there's one called RPG Maker and another that's called something like rpg2k (?).  Anyway they should be easy to find with a search engine.  I remember they had lots of different tile sets for download, you're bound to find one you like.  
24  Game Development / Performance Tuning / hotspot inlining on: 2002-11-19 13:53:42
Does anyone know the rules governing what code hotspot is able to inline?  I have several method calls in tight loop.  The code will start to get pretty nasty looking without them, so I'd rather not do the inlining myself if I can.

Has Sun published any information on what code you can expect will be inlined, or is there any way to determine this with a profiling tool?  I guess I can do it by hand and measure performance, but I'd rather not if there's a way involving less work  Grin
25  Java Game APIs & Engines / Java 3D / Re: Data format: storing world object information on: 2002-10-17 21:20:21
any screenshots available?
Pages: [1]
 

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

The first screenshot will be displayed as a thumbnail.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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