I just have some questions about making RTS with JME.
So i have an idea for an RTS game. I have many years Java knowleadge, but from the business software side not from the game developing side.
Is it possibble to make an RTS with JME?
Why i ask:
is it to possible to optimize the code for a good performance when i have hundreds of units, that move, shoot, etc?
like supreme commander: for example, if i have a tank, i want to near to see it's detail like tower, but i can look the battle field from big distance, see hundreds of units (water and flying based units)
Should i worry from the very big memory usage when i have many units on the battle field at the same time?
Have anyone some experience making RTS with JME? Could you tell me some tips?
For start, what camera type should i use for scrolling up and down (near/far from a unit)?
Is it okay to do the modells with 3DStudioMax?
How can i use LOD for units when i see it from far away or very near to it.
How can i use some animation? For example: fire effects when a units are damaged.
I suppose it is possible to do a RTS in Java with Jme, but I prefer someone with more experience in RTS’s answer.
About the other questions, yo can use ChaseCamera to scrool near/far from the unit.
I recommend to use milkshape or md5 for the models/animations and the MD5ModelImporter http://code.google.com/p/md5importer/, because them work very well.
I saw a robots game the other day in the forum, search for it, may be you can use some ideas from it.
I suppose it is possible to do a RTS in Java with Jme, but I prefer someone with more experience in RTS's answer.
About the other questions, yo can use ChaseCamera to scrool near/far from the unit.
I recommend to use milkshape or md5 for the models/animations and the MD5ModelImporter http://code.google.com/p/md5importer/, because them work very well.
I saw a robots game the other day in the forum, search for it, may be you can use some ideas from it.
Goodbye.
milkshape look very good. it has many tutorials so i think i will use it.
Go step by step… always check the tests, as they show valuable techniques.
For different terrain textures, have a look at TestIsland. It uses a technique called Texture Splatting which allows you to show different textures for your terrain. As always, there are some limitations.
If your terrain is very big, you will need to use a Terrain manager so you can load terrain "pages" (blocks) on-demand. Forget about this initially and just go for a simple map (a single terrain is large enough to startup).
Textures for models will be automatically loaded when the model is seen for the first time. You can prefer to cache or pre-load textures (so player doesn't notice something has been loaded). But forget about this initially: just load the models you need and don't worry about perfomance now.
You can use MonkeyWorld to define a map. I don't know how good it is in terms of managing texture splatting, or mutliple terrain pages, but as I mentioned above, I believe you shouldn't care about those for now.
May I suggest, just take TestIsland, inspect it, and start putting something together. This way, you will be familiar with JME and some techniques, and then you can start extending your game (bigger terrain, nicer graphic effects…).
I'd say it's quite powerful, yet far from state-of-the-art engines. Check the tests that come with JME and you can also have a look at this video or any of the other JME videos:
Well with the right art and the right amount of shaders you can make things look pretty darn cool. Will it be like the next gen games where its mind blowingly realistic? Probably not, because that's a lot of technology under the hood in order to get that look + performance to boot (e.g. as a single developer you probably won't have the luxury to go with middle ware stuff like speed tree to make that extra bang).
As far as Tiberian Sun goes…you can blow that game out of the water graphics wise (probably with any modern engine out there…afterall TibSun was released in 1999, wasn't a true 3D game nor did it have the benefit of what we have on modern GPUs). Really, JME won't make your game look shiny and cool…it'll help, but its all up to how you make your art, and utilize OGL through JME. The engine's here to build you a foundation to keep your scene organized, free up hassles of having to build your own framework, and to improve performance of how everything's rendered (e.g. leveraging the scenegraph). There's still going to be a lot of custom work involved on your end however.
Now with that said…you could theoretically make anything with JME, an RTS game in a way is no different than Pong - all games share some similarities. Just there's a lot more complexities involved (e.g. making an RTS-like camera, being able to select and move units, being able to place structures on the map, having a responsive GUI where you push build buttons new units are spawned, having a end-game state where if all the enemy is destroyed the game ends, having menus, etc). Break down what you want in your RTS game into manageable tasks or modules and implement them. There isn't a right way or wrong way to make a RTS (well…in implementation, of course there are crappy RTS' out there and superb RTS' in how well their gameplay is executed ;)), it's really just a collection of modules working together to simulate troops on a battlefield that can be controlled by the user.
Break the problem down and work from there…you could probably prototype it using the flag rush tutorial…create a RTS-like camera, re-work the bike so you can select it rather than drive it and let the user select points on the terrain that the bike then moves to…etc.
Promise i don't ask it anymore but i must to know.
So put that case. I have some very good graphic artist, and some very good programmer (know opengl, java).
In this case we can make a game with using Java, OpenGL and Jmonkeyengine that looks like nowday's game?
Is it possible that this game will looks like the big game studio's games?
So i know this is very-very hard…
Not a nowday's game but if we want the game graphics like supreme commander it is possible or not?
Think for that, in this game don't rare that i have hundreds of units and thousand of units in the whole game.
so you think, java and opengl is good for this?
no performance problems?
the only think that i worry about that in the half of the game development we realize that we must start it again write it again in C for example because the performance or the graphics quality is very bad…
I have seen some very nice works done with Java and openGL, and I have also seen some pieces of garbage done in C
jME is simply a tool that makes getting going with Java and openGL much easier and helps avoid some potential pitfalls (found in ANY language). Having said that the outcome of your project will probably have more to do with your input than with what language you write it in. If you feel you have to drive necessary to see a project, of the magnitude you are talking about, to the end then I would say go with jME. It will get you off to a running start ;).
The performance hit is more dependent on your skills than the language (sound familiar?); even if you are writing an entire game in assembly language (kkrieger anyone?). But basically, using Java is less of a performance hit than you might think…
Well, I think this depends on what you synchronize and how.
Imagine you want to update every unit, every frame, every second. 5000*60 is 300000 pieces of information per second. With a (conservative) size of 32 bytes per piece of information, this accounts for 9.1 MB/sec. This is clearly unacceptable, and it doesn't even consider other messages, TCIP/IP headers, etc…
Some suggestions:
If your game allows for this, instead of considering 5000 individual tanks, you could handle them in groups. Each group would have a position but each individual unit position would be deduced from group's. This may not work well for positions but could work for other attributes… depending on what kind of gameplay you have.
Updating every frame is never an option. You need some flow control… a possibility is to set a maximum, but also stop sending updates to a client if it doesn't respond to them.
Update only what is needed. A common approach is to keep track of what "state of things" a client knows, and send only differences (usually called "deltas").
When representing things, have each client interpolate between the data it has received and what you can "predict". For many attributes, this will produce a better gameplay experience.
Related to above, when moving units, interpolate between what you are currently showing and the prediction you have done. This improves the laggish feeling you get if you just apply new data directly.
If i make 5000 piece of tank unit, for example. All have basic AI, can fire, move, etc…
It will run on an avarge PC? In practice these units are 5000 instance of an object (may many of objects), no need more memory? What about the CPU load when GC start to work and 5000 units are moving, fireing, etc
