Draw it last and don't do any depth testing.

Mike

I approve of this, Riven? "Movie of the day"! ;-)

I agree though, this thread is not really productive

Mike

11 steps, doesn't say much when each level is random though

Good enough to keep a 2-3 minute of interest. The best part is probably the intro with the falling blocks.

Mike

No matter if you use lwjgl or slick or java2d or something else it will always be the same idea, just with a little bit different code.

From the thread I posted:

It shouldn't be too hard to implement the above in any engine of your choice.

Mike

This.

The future will tell

I now have plots programmed, now to add the marker that you can buy them and that you actually can own land

Mike

Yes, like guilds

You start with a bit of money to buy a plot of land in the outskirts of the city as well as some (for now) plants and other things you can grow. You then harvest your land and sell it, from which you earn money. That's the smaller start, and eventually there will be several professions and materials, I'm still figuring it out

Mike

This forum has a very nice search function...

http://www.java-gaming.org/topics/camera-zooming-on-specific-point/28713/view.html

Mike

Indeed, that was our conclusion during the messaging as well I personally dislike games where you cannot control your character when it is in the air. I know that it isn't realistic, but it does make it much easier to play.


It is all done, but it won't be online until the first game version is online as well so it will probably take like a month or two. I finally figured out the buyable plot locations, next step is to implement it and then make them buyable. The smallest plots will be 10x10 meters and close to the spawn/auction/npc sales (meant for putting up a small store for example). The biggest plots will be 950x950 meters and will be meant for a group of people.

Mike

We will take this in private messages as to not swamp the forum with posts.

I cannot reproduce it (without letting go of the move forward button as well). I'll try it a bit more and see what I come up with. Thanks!

Mike

Are you saying that while you are falling you no longer move forward, or that you fall in a constant speed instead of the fall speed slowly increasing?

I can't reproduce either of them, but if I know which one you experience I will look into it

Currently trying to randomize the plots you can buy based on lots of of variables, without it taking ages. Might be the most difficult thing I ever programmed

Mike

Okay, that makes sense. Unless someone else has an idea there doesn't seem to be a correct answer so I think I'll play around a bit with the different options and try to come up with what fits me the best

Mike

Said and done, I created a new thread for it
http://www.java-gaming.org/topics/running-several-games-based-on-the-same-code/29453/msg/270347/view.html


Thanks! I added forests into the new terrain generation formula yesterday As for deserts and snowy ground, it'd be doable for the high quality ground setting at least, but it's something for after I did a lot of work on the game mechanics.


That's actually the normals and not shadows. I agree though that they are a bit much, I changed it to use the correct normal instead of the exaggerated I was using to easier see where the land sloped up or down. It looks better now and with the "auto straight land" function the need to see the height difference isn't as big anymore.

I agree that the grass is too simple, I have on my list to add several different kind of grass and improve the quality of the sprite

Mike

Right, creating separate projects and adding the common one in the classpath sounds good (and is probably what Cas meant too, but with a twice of experience, which is very nice )

So, to put it in a simple example that I can comprehend with my limited OO knowledge
Say that I have a project "Common" with a method called "build" and now I want game A (in project "A") to have a couple of extra checks (not only can you not build where there is already a block, but you can only build on your own land). I would then extend the Block class in project Common and overwrite the method "build" and add another check (if (getOwner(p)==you) before calling the build method in the superclass which does the original tests. I'd then overwrite all of the block classes (each block type is one class) and make them extend the new version instead of the copied version, and overwrite the method that add blocks, so it adds the new block types instead of the original ones... starting to sound messy

Does that sound about right? It sounds like a lot of maintenance, but I think that it will make it flexible enough and make fixing bugs in the common project automatically fix them in both versions.

Mike

This is more of a code design than a game design question, but I didn't know where else to post it. Please feel free to move it somewhere if you see the need.

I posted a question in the State of Fortune thread, but a wise man pointed out that people don't look at the thread for generic questions, and therefore this thread is created.

What is the best way forward (from a time/code point of view as well as maintainability) when one has two versions of the same game running, where a lot of the code is shared, but many functions are different?

Should one:
Make a copy of the current projects (client and server) and build on top of that?

• Positive: Easy to separate the projects, the jar for the sandbox will download quicker as it doesn't contain the game content
• Negative: If one fixes something generic one will need to change both versions. Big refactorings needs to be done to both versions separately. Will need a launcher client where you can choose which version to start up

Extend the current classes where necessary and make a game version of them, only overwriting where necessary?

• Positive: Cleaner code
• Negative: I don't know if my programming skills are good enough to keep it organized

Split the game code completely away from the engine code and let the game know where it can inject code?

• Positive: Cleanest code
• Negative: I really don't know if my programming skills are good enough to keep it organized A lot of work to keep the game code separate

Add cases to the code based upon which game version one is playing?

• Positive: Quick win
• Negative: Messy code

Something obvious that I didn't think of?

Mike

Maybe I should have created a new thread with the above question and made it a bit more generic. No one with experience in running several versions of the same code?

Also, adjusted the land generation formula to create fields and mountain areas instead of all flowing with the land. Screenie:


Mike

It's been 4 months since I started on "landscape test" and so far I've spent some 300-400 hours on programming it.

I just uploaded a new version with the changes described in the previous post and I now classify the playground server as Alpha 1.0 or something like that I still have a list of some 30 things that I want to add/fix in the playground but they are not blocking for starting on the game. I will post some updates now and then with how I progress, but I think that the first game version will take a month or two to get ready.

I have a question for the people with more experience than me in regards to programming (most of you ). I am not sure what to do with the code base when I have two versions of the game running, where a lot of the code is shared, but many functions will be different.

Should I:
Make a copy of the current projects (client and server) and build on top of that?

• Positive: Easy to separate the projects, the jar for the sandbox will download quicker as it doesn't contain the game content
• Negative: If I fix something generic I will need to change both versions, doing big refactoring needs to be done to both separately, need a launcher client where you can choose which version to start up

Extend the current classes where necessary and make a game version of them, only overwriting where necessary?

• Positive: Cleaner code
• Negative: I don't know if my programming skills are good enough to keep it organized

Add cases to the code based upon which server you connected to?

• Positive: Quick win
• Negative: Messy code

Something obvious that I didn't think of?

Mike

Good luck with writing it in C++. If you could post a performance comparison when finished it would be great.

Mike

Thanks!

I'm going to do the last update in quite some time tomorrow (add/remove trees, change mouse look speed, lower cpu usage, /goto [playername] to teleport to other players, /goto to go back to the spawn point, log in where you logged out, complete control of the field of view instead of only two fixed settings as well as a couple of smaller bug fixes).

After that I deem the playground server in an acceptable state and I'm going to start on the game server, finally!

Mike

I see your thread and I raise you with this one :
http://www.java-gaming.org/topics/how-do-jgos-social-stats-calculate/24748/view.html

Mike

Seeing as there will be a LOT of methods that read data out of the chunks I prefer to use a fixed size array for it for performance reasons. Just add a couple of shift functions so you can move the relative position of the array when you load/unload data and you're good to go.

Mike

Already uploaded

Mike

I had time but doors were a whole lot more complicated than I thought they would be Everything from adding actions to blocks to dynamic blocks (not having to recreate the display list constantly) to having the correct obstruction and so on made doors quite complex. It'll be a lot easier to add the next dynamic thing now though as I made a lot generic right away.

Screenie (textures by the missus, the second door texture will be switched out somewhere down the line):


Mike

Worked fine, a couple of pointers:
Allow computers to move instantly instead of having to wait for them to slowly move
Don't rotate the board, I constantly lost track of where on the board I was and where the computers were (which is quite important when buying houses)

I love that video. It got reposted quite frequently last few hours. I hope it goes viral to show that everyone can enjoy VR, even... Nate?

Mike

I ordered one two months back to integrate it with State of Fortune (and because it looks awesome!). Hopefully it will come in a month or so, after which I will be able to tell you precisely how it is

There is already a JNI dll (the SDK is windows only for now) created for it as well as lwjgl sample code so it should be quite doable to get it to work.

There will come another development version as well which is closer to the consumer version (full hd screen for example) but they cannot give any ETA on it. If you have the money or want to be one of the first to use it, get one now, otherwise wait until the next dev version or the consumer version.

Mike

There is a thing called private messages on the forum you know

Mike

I just completed and uploaded the following:
Different block types have their own bounding box, walking up slopes is smoother and you can walk up more than one at a time
Stairs (choose height of the stairs by placing several on top of each other)
Fixed direction stairs/slopes, if the automatic direction isn't doing what you want it to, you can now choose the direction yourself, the slope/stairs will face away from you when you build it

One thing I just added to the to-do list before starting with the game mode is mouse sensitivity, the missus is complaining a lot about how fast it is

If I get some time in the weekend I'll have windows, doors and tree removal in the game beginning next week.

Mike

The friction is a bit too low (looks like they are gliding on ice), other than that, nice explosion!

Mike

Thanks for the kind words!

I'm currently adding so each type of block has their own bounding box (so you walk up slopes as if it was a slope and not a stair for example).

After that I'm adding (in no specific order):
Stairs
Fixed direction slopes
Fixed direction stairs
Windows
Doors (that can open! )
Ability to remove trees
Log in where you logged out
Reset position to the spawn point (only for the playground)
Teleport to other players (only for the playground)
Forests
More flat lands and diverse landscape

Once I'm done with that list (2 weeks?) the playground server will be reset (to handle the new landscape generation algorithm) and be deemed complete and I will start with the game part.

Mike

Easy is pretty much always beatable in 3 steps, so I think that's a good challenge.

I'd either improve the loading times with a lot (for such a simple game it shouldn't take more than a second to go from the menu to the game board), or add loading screens.

There is also a problem that the redraw only happens when something changes, so when the applet goes into "sleep mode" when for example being minimized it never comes back.

Mike