Community Sandbox Game Spec

Business and Project Management Discussions Community & Volunteer Projects
#61

1 - I can’t say much either way on the 2D / 3D front either than the fact that I have no experience loading 3D models and doing pretty much any 3D algorithms, aside from 3D vector math. So however you guys decide, if it’s 3D I won’t really be able to help much.

But it seems to be that if we can get a 3D engine working so that we can just throw in models in some format, then our lives will be easier because animations are a lot easier in 3D - you make the model once and then you drag the body parts around. in 2D you’ve got to individually animate every frame, and although you can do some stuff with dragging certain body parts around like a keyframed animation, for any rotations you’ve got to draw a totally new thing.

2 - If we go with 2D, I think Slick is a good call. And with 3D probably jME.

3 - Yeah that’s unnecessary at the moment. But if we’re going Applet then I think 800x600 is mostly safe.

4 - How is control going to work? Straight up keyboard like WASD or maybe some sort of mouse interaction?

#62

  1. I vote for isometric 2D which is backed by a 3D model, similar to Wakfu (see the pictures of their map editor here and here), so that it would be possible to have height differences, maybe even some physics and dynamic lighting.

  2. If we want the game to work also as an applet, something which does not require the ugly security dialog would be nice.

  3. The resolution should be scalable, so that if you have a larger screen then you can view a larger area. 800x600 or 1024x768 would be the minimum resolution. Personally I use 1920x1200, so I would like it to work also on large widescreen resolutions.

#63

  1. Agree.

  2. Do we want an applet as the primary distribution method? My experience is that folks around here prefer webstart and “normal” windows users prefer an exe (trivial to create an exe wrapper for a webstarted game). An applet without a security dialog limits us to only java2d, which is too limiting IMHO. I guess if the security dialog is too annoying we could scrape up some money between all the contributers to get a proper cert.

  3. Agree.

  1. Which is one of my reasons for wanting to stick with a 2d api. We’d get much greater community participation if it’s easy to jump in and start adding code/content. Anyone can pick up Slick in an afternoon, but JME is a much bigger (and quirkier) beast to get to grips with.

I would like to start with 2d characters and see how it goes in terms of code and art effort. If it doesn’t work out then irreversible_kev’s suggestion of 3d characters within the iso world could be worked in with minimal disruption and wasted work I think.

  1. 800x600 would be a good baseline/minimum I think.

  2. I don’t think it would be too tricky to support both. Are we going to have a player inventory to manage? If so then I suspect mouse as the primary method would make sense (since it’s a pain to do inventory management with a keyboard). But basic movement and actions could still work on the keys.

#64

OK it looks like we’re going for 2D isometric graphics. Upgrading to 3D could be another project way down the line but I guess it’s not for now. It comforts me to think that this decision will increase the chance of completing the game. There are alot of great ideas we have talked about that I would love to see implemented and 3D is not a critical factor for them.

I guess if you don’t want security popups you need to go for something like Java2D, JavaFX or Pulpcore. Although I hope applets make a good comeback, I also don’t necessarily think that this is a game that should be played in a browser. If we have a lot of content, Wakfus deployment method seems pretty good.

I only really have experience with JOGL but going for Slick sounds good.

My initial thoughts are that I’d prefer traditional keyboard controls for player movement rather than point-and-click movement. I think if done correctly (simple up/down/left/right/accept/back), keyboard controlled menus (perhaps key labelled menus) would be really intuitive.

I feel that having keyboard controls makes you feel as though you are they player rather than giving orders to the character by point-and-clicking… but I might just be going crazy here lol.

EDIT:

I just tried wakfu on both 800x600 and 1280x1024 and the size of the character on my screen is the same on both so it seems they are scaling their tiles. Mouse scrolling zooms in also.

#65

After thinking about this I’m inclined to agree that keyboard for movement feels more immersive. Since we’ve not got as far as considering inventory yet maybe we should go for keyboard control to start with - once we’ve got a better idea of how items and the inventory are going to work we can reevaluate them

#66

If you’re intending to use keyboard control be aware that if you come to network it that can make things considerbly more complicated.

Kev

#67

I don’t understand! (feel free to elaborate)

How can the (type of) user input have any effect on networking?

Events will be passed into the engine, go through a nice abstraction layer, at which point the engine cannot know what caused the event (keyboard, mouse, created file, etc), only that it did occur, and that it should act. Whether is should change the model, or make a request to the server to change its model (probably a database) is completely detached from user input.

I’m probably totally misreading what you said Kev, as I really can’t wrap my head around it ;D

#68

Because if you’re doing mouse driven events you’re operating on a higher level (“walk player to target X”) rather than directly wired up via the keyboard (“left one pixel, up one pixel, left one pixel”). The mouse approach gives you much more slack for resolving lag and paradox (no-one cares if two characters walk around each other in sightly different ways on different screens if they get where they’re aiming for at the right time).

Since we’re aiming to get a solid single player game first with “bolt on” online elements rather than direct peer-to-peer interaction I’m inclined to ignore this complication for the time being. What do others think?

Semi-related, what do people think the movement should be like? Tile-by-tile (like Harvest Moon, where each tile can only be occupied by one character at a time, and you’ve got to wait until you’ve entered a tile before you can change direction) or free-form (like Animal Crossing, where the underlying tile divisions don’t affect your movement).

(rapidly becoming aware that we’re devolving into picking apart every minor decision. Is it time to finalise Phase One on the wiki and actually get started?).

#69

Ah, I understand. I already assumed it would be tile-based, in which case the keyboard input causes no such (serious) networking problems, as with pixel based movement. The gfx would be detached from the tiles (avoiding chess like movement), so you can freely walk (pixel by pixel) but the tile(s) you are walking on are [sent to] / [verified on] the server.

Allowing only 1 ‘item’ per tile is a bit too restrictive, giving an item a property whether or not it blocks access to a whole tile might be better.

That way you can effortly drop items (tools? materials?) on the floor without it blocking your way.

#70

What he said. I’ve tried both.

The one truth about networking is there will be a delay between sending and recieving the actions of the player. My opinion, which I've been trying to verbalise for years now, is that the hard part of networking isn't getting the data from A to B (which in the most part is trivial), it's how you hide/smooth/integrate the unavoidable network lag time.

So, point and click granularity of events gives you much more room to hide the lag, to delay actions in a repeatable way the player can adopt as part of their user model.

Have to agree btw, getting way too low level now. Time to build a first phase plan and get some code cut?

Kev

#71

Yeah, I think that sounds good. Who’s heading this shindig?

[EDIT] Just read this:

So I guess I’ll put a simple layout of phase 1 in the wiki tomorrow. If anyone wants to do it earlier than that, go right ahead.
[/EDIT]

#72

To be truly honest, the most immersive feeling I find is using the mouse to move by holding a button down to walk/run and the direction you’re pointing. Would this be a plausible idea?

#73

Do you have any examples of games which use this control method?

For an FPS game mouse+keyboard works fantasticly (FPS games can be extremely immersive) because you really need the extra accuracy of the mouse. For a 2D isometric game I think 8-way{up, upRight, right, downRight, down, downLeft, …} using four keyboard keys is enough… but it would be nice to see some existing examples of the control method you proposed.

Hopefully Sandbox:PhaseOne will become a reality soon ;D.

#74

Does Diablo use a control scheme like that?

#75

Yeah, that’s how Diablo works. It is an easy adaptation if we just want you to be able to do it both ways at once. We could try them both out and see how they feel.

#76

Diablo is a good example. An even better example would be like Ultima 7, where the mouse is close to the character they walk, but if they move the mouse farther away, they run.

#77

Sorry for not getting that spec up this weekend, guys, I’ll try to get to it tomorrow.

#78

Surely the project will not die !? :’(

Mabey we started the project when everyone had time and now nobody has any. :’(

#79

Yeah, I haven’t had any. Sorry.

#80

I haven’t had any time either, nor will I have any in the coming months. :frowning:

Do we have any people interested in this sandbox, who also have time? :persecutioncomplex: Please report your status.