i’m currently using nothing 
.
thats because i dont really create scenes. most of the stuff i did so far where small testing applications to bring panda to it’s limits and see what can be done. in these scenes most objects where places automatically just to have them somewhere at all.
if you run into trouble just drop me a mail. might happen that i cant look into the forum as often since school is aobut to start again.
Hi Thomas,
I still don’t understand why you have to make these small patches to build up a large terrain.
Can’t you just produce an area like a small valley, the equivalent of the Roaming Ralph tutorial only larger and work with that?
I’ve been thinking about having many areas linked together in that fashion.
These patch based areas just seem overly complicated to produce for what they do when it seems you can just build an area to export and convert to .bam and be done with it.
I’m a fan of what Einstein said “Make everything as simple as possible, but not simpler.” If I could just figure out how to do portals, it might make it easier. David Rose explained in a post to me before, but I’m afraid it’s over my head currently.
Steve
of course you can, and for smaler levels it’s the best way to just build and export it.
but in case you want to have huge… and i mean REALLY huge levels you end up with tons of data. if you have a 20x20km area and a 0.5meter ground resolution you most likely have over 3GB data and nobody whants to download this much.
dong get confused over the small patches in the example i posted. you usualy would use patches with around the double size. always depends on the actual usage.
the trick when using smaller patches is that the same piece can be used over and over again to save a lot of data.and the larger the pachtes the more data is saved (well this is balance between datasaving and grafical result/detail richness). also texturing these small pieces is lots more simpler since you can avoid multitexturing. the third benefit is that small pieces can be loaded very fast. fast enough to load them at runtime without letting the user notice so you can avoid loading screens.
to keep it short. unless you want really huge levels;with lots of details;no loading screens;and everyting running on lower class hardware you dont need this.
hm about building these patches. i dont think they are very hard to build. the image i postet was made withing a few minutes and i would’ve need the very same time to build it for “normal” purposes. depending on the environment you want to realize it can be somewhat faster or slower to build.
actually portals are more or less just linked planes to connect level parts which arent actually connected.think of them as magic mirrors which allows you to look and walk through into another world (or level part). they could be used for this but it would make the whole thing pretty complicated.
portals are more usefull when you like to create “impossible” levels where you can walk out a door and enter the same room again. also usefull for indoor/outdoor transitions. i think planeshift is using portals to connect his levelparts ( they are pretty huge like a city or a valley), well you can see each and every transition.using portals you need to be very careful with the leveldesign.
I guess I just need to prototype what I think would be a typical size area in my game and then see how the engine deals with it. I’ve only been working on very small environments like the “Roaming Ralph” environment size to prototype little ideas on gameplay.
I believe one of the major stumbling blocks for new users is having to think of how to do things that other engines have already done for you. Like terrain, collision, etc… Of course Panda3d is really more general purpose then those engines so I guess that is the reason for not doing everything for you.
Using Python is a great plus, the stumbling block is trying to figure out how to do all these little tasks to make a game.
My thoughts on portals was to keep the engine from rendering stuff like the inside of buildings or what have that don’t need to be rendered until you enter them. I guess the same thing could be done by just building the shells of the buildings and then load the interior when you enter.
It would be nice to know all the little secrets Disney uses for their games like ToonTown or the upcoming Pirates game but I realize of course it’s wishful thinking. 
Steve
for the idea with the house and the shell. just set up a seperate node for the interior and attach it to “render” whenever someone opens the door or detach it when you are outside. (same goes with the outside)
should do about the same job like portaling but it’s somewhat more… “einstein”'s way;)
well. I’m shure you’ll find a solution for your level-size =).
perhaps someone else could awnser the original questoins regarding networking and such? this thread became pretty much hijacked by storing a 3d-tilebased environment.
Hehe, good point!
Harry, for networking in Panda3d you can use a generic framework like Twisted Python or Pyro.
There’s an O’Reilly book available for Twisted and it should be all you need to complete the network side of your game.
Just a suggestion of course.
Steve
I have the book! Twisted Python is a good choice, even though I would like to look further into the source code to see Panda’s support for networking (which must be extremely powerful). After all, the “N” in the name isn’t there by chance, is it?
The problem is, physics and collision detection (which is obviously not critical in a MORPG) should be always run server-side; Panda networking code seems to rely a lot on the client, which isn’t good for my project. But once again, even if you design and code the server in Python, you still need to hook it to Panda, in some way. The server should handle physics and distribute them to all clients, and networked physics should be able to deal with lost packets and all other “problems” caused by the Ureliable Data Protocal; each client should be constantly doing client-side prediction, and I am wondering how Panda currently handles this.
By the way, thanks for the suggestion!
Well, to be honest, I haven’t looked at the network functionality provided in Panda3d but I thought I read that it’s very basic.
I believe the N in the Platform Agnostic Network Display Archicture acronym was there for Disney VR but I’m sure I read a lot of that was removed for our use since it was proprietary in nature for ToonTown.
Steve
since you are speaking aobut prediction i remembered the smooth mover stuff i read in the docu’s
http://panda3d.org/apiref.php?page=SmoothMover
in best case you just have to update the player positions and let panda do the prediction… well i dont know how well it’ll work out but it’s worth a try since it looks very easy to do.
ahm do you really think that server sided collision is such a good idea? it causes a lot of cpu usage after all and it’s sometimtes pretty ugly for the players. i think clientsided colission is fine as long as the server checks if the motion is ok (to prevent speedhacks or flying cheats or things like this), a few checks per second should be more than enough and saves a lot of trouble.
if every player calculates his own collision it would lower the server’s cpu usage. the server would just have to distribute the positions.
bdw. what kind of style are you planing to aim for? i recently fell in love with the cute characters from flyff =) although comic character’s faces are hard to model, they are easy to texture 
I was very imprecise in my previous post.
The problem with collision detection in online games comes when you have dynamic items. Collision detection with static objects (like houses, trees, and so on), should be handled client side to reduce bandwidth; of course, at each position update, the server will have to verify that your moves are legal, compatible with the environment in which they are performed. If there is no error, just adjust the player position if needed (smoothing differences using functions like the one included in Panda - thanks for showing it to me!!!); if there is an error, immediately send the player back to the position before the error occurred. Client side prediction on static object is the way to go, I think, to obtain the kind of smoothness seen in games like EverQuest.
In MORPGs, collision detection with dynamic objects should be handled by the client too, but verified by the server, in some way (for example by using a defined amount of time per tick to verify as much collisions as possible). But then again, this means the server must be able to calculate collisions, unless you can afford to prevent cheating with collision indirectly, as you suggested. True difficulties start when you are developing an online game where the experience would be completely ruined if players are allowed to run around while affected by lag or while they are cheating.
That’s why all MMORPGs still use battle systems that pale in comparison with those in offline RPGs; it would be terrific to have Fable’s battle system in a MMORPG, but that would be impossible to handle when you have unknown variables like lag, number of players fighting simultaneously, and so on. But of course, if you are developing a MORPG (with a very limited number of players allowed in each game), and you have no problems using a lot of bandwidth, this would be doable. Or, another solution would be separating completely what is rendered on the screen from its actual effects - for example, player A hits player B, the scene is rendered on the screens of both players, but if the server finds out the hit was “illegal” it doesn’t count it against player’s stats like HP. The problem with client-side collision detection (and position prediction, for that matter) is obviously that the dynamic object collision is always out-of-synch, but then in the end, unless this has some concrete effect on the gameplay, who cares? In the end, what is important is that players see a smooth experience on their screens, while the server validates information critical to the outcome of the game; only when needed, the server, that has always the last word on everything that’s going on in the game, asks the client to adjust positions that have also an effect on the screen.
I have a lot to work in this period and we are still just in the design phase, but I wish I had more time to see how all this could be tested in Panda3D.
Flyff style is really, really cute, I love it! When we were thinking about a 2D game, we were aiming at a dark cartoony style, which we could bring to 3D, maybe!
On a note, the Smoothmover in Panda3D is a confirmation of what I was saying - Panda3D already includes some of the most critical elements needed to make a multiplayer networked game. If we were able to fully understand the network code, Panda3D would do 50% of the network coding job for us (and better than a one-two persons development team could do alone within a reasonable amount of time).
Well Harry, if you can figure out the networking that’s included in Panda3d then by all means, use it and write a manual page on it please
I’m sticking with something I know how to use for my purpose until then (Twisted).
Steve
Yeah, yours might be the right choice, and depending on the game you are developing you could end up with a much simpler and cleaner (easier to debug and optimize) server.
Harry,
Here’s one of the posts:
I still vaguely remember a post from David Rose @ disney or maybe it was someone else saying that most of the network stuff was removed because it was for ToonTown and that they (ETC) were trying to replace it with new code.
Well, it could be the scene editor I’m thinking of, well anyway, you know what I mean.
I’m no C++ wiz so I go strictly the Python route myself.
Steve
Thanks a lot for the info, sw3. I obviously need to go a similar route, and I could use Twisted Python or Ruby for the network code - but then again, will you use Python also for the game logic?
Harry,
Yes, I’ll use it for both. David Rose has said once before that using Python for your game logic is perfectly acceptable and contrary to popular belief will not result in huge performance loss. He did admit to some C++ code additions for ToonTown I believe though but I’m not sure in what areas or uses.
I guess it depends on your application.
You can’t beat Python for rapid prototyping though. That’s all I’ve been doing really at this point, just trying various schemes out in little pieces. Once I get enough stuff working, then I’ll start putting it all together.
Instead of floundering on certain things like terrain and networking, I’ve just gone a different route.
Steve
P.S. You might want to see what EvE online has been doing with Python by-the-way if you want a more professional opinion. I’ve got a post in the “General” forum about it titled something like “Another MMO like ToonTown uses Python…” you get the picture.
@harry: python should do a good job on the game logic. maybe i missread some parts in your post further above but i dont think that collision detection between 2 dynamic objects is necessary at all. most (m)morpg just allows palyer to run though each other which saves a huge amount of cpu usage.
so a few checks on the server side to validate the client-positions are fine. mixed up with smooth mover you should already get some good results.
hitpoints/damage and such should better go on the serverside only, while the effects and animations for attacking should be clientside only.
bdw… what should i imagine under a “dark” cartoony style? any animes based on this style? 
g and i couldn’t stop me from modelling a flyff-like character. just started a few ours ago but it’s only missing hair and a propper texture… maybe some clothing… once finished i’ll post it… maybe you can use it as test-avatar or something like that^^ somewhat under 600triangles… with hair and cloth maybe between 800 and 1000. nothing special…thought
Sm3 - that’s interesting, thanks for the info. I have read good things about RakNet too, but since it is a framework designed for MMORPGs, I fear it would take away too much of the fun. No seriously, I have never tried it, but it could work fine with a python binding.
Thomas, about the cartoony style - the better example I can think of right now is the gothic style of a game like Medievil, just a bit more realistic and not as repetitive. But this is just to give an idea! I would love to see your character, when it’s done!
Harry,
While you’re still searching, there is also the net code from the Torque Game Engine.
I’m not sure if you’ve heard of the indie MORPG game called Minions of Mirth but the guy who created that game uses Python. He’s developed C++ bindings for a modified Torque Game Engine (that’s he released to the public) that allows you to import the Torque Engine as a Python module and is currently working on C++ bindings for OpenTNL to use with the next version of his game.
He currently has about 20,000 registered users that play his game, which is currently using Twisted Python (modified of course).
All done by a very small team (mostly himself as the only programmer) and then of course contracting out for the artwork.
Just trying to share some alternatives that I know about as far as networking and what others have done with Python.
I use the Python bindings that Josh Ritter created to interface to the Torque Shader Engine. It allows me to write the game logic for it in Python instead of TorqueScript for the most part.
Steve
Yeah, Minions Of Mirth is source of inspiration for anybody trying to do a MORPG. I honestly came to know MoM indirectly; I had written a paper listing all the requirements for our project, and started deciding which tools could be used for it. So I decided to use mostly Python or Ruby for the client and the server, with C++ handling graphics, Photoshop and Blender were obvious choices for the artists (since we couldn’t afford a 3DMAx license, and since Blender is a more complete software), and then we had to choose a graphics engine. Torque was one of the first I tried, but I ended up not using it because of its focus on FPS, its price (too high in comparison with other free engines that offer similar features), and its scripting language (I do not like software that forces me to learn a new scripting language when high-level programming languages like Python or Ruby are already around). Anyhow, during my “visit” at GarageGames, I discovered Minions Of Mirth, and I tried it.
I was surprised to discover such a fine game was being developed with some of the tools I decided to use myself. After Torque, OGRE, and Irrlicht I came to Panda - so far, it really seems this is the most powerful engine, even though it lacks the documentation of other engines that were born as open source projects and it lacks some features that are included in other engines (mostly because Panda3D is a generic purpose engine).
The lack of terrain generation could be a problem, and this is one of the things I have yet to decide, so ThomasEgi suggestion is intriguing. Speaking of the network framework - Twisted Python, also from what you said, seems a great choice. While Python alone is good enough to get you going in no time with its networking modules, I bought the Twisted Python book mostly to develop a web based application a while ago, but it seems like it could be really useful in this project! I just don’t remember reading a lot about UDP support in the book, but I guess that is just because it introduced you just to the essentials.
I see from your previous posts you are using Torque Engine - what is your experience with it so far? Any screenshot of your current work with it? What do you think of the tools included in the Torque package?
Harry,
Like you pointed out, Torque is great if your game is an FPS since that’s what it was created for. If you want to make an RPG (like me) then more than likely you’ll have to modify the engine source code which is a bit out of my league, however, not completely out-of-reach because often times you’ll find the code for a particular feature in the resources section of the GarageGames website. People have created all kinds of things for the engines to add the missing functionality you’ll probably need such as day-to-night transitions, mini-map display, 3d picking, 3d inventory, etc…
The problem with these resources though is that 1) they are not always 100% bug-free 2) they may not compile on the current release of the engine. So you will be back to square one with learning how to make modifications to the engine in C++.
Torque also still uses BSP so you’ll need to learn to use a BSP editor to create your buildings and then export to their .dif format. Player models, weapons and other small items are created in Max, Maya or Blender though.
With the new Torque Shader Engine you can create extremely large outdoor areas because of the new terrain engine they’ve called Atlas2 based on the Chunked LOD code of Thatcher Ulrich, however, you still need to make C++ changes to add features not provided in a standard FPS game and the tools for terrain like in the original Torque have yet to be added so you’ll need to use yet another program like L3DT or TerraGen for your terrain.
Another interesting development with Torque is called the MMO Kit. It’s being developed not by GarageGames but by a group of developers who are also community members. The good news is that they are taking care of a lot of the C++ code changes I would have to make (that I can’t) to add the features present in most RPG games these days like graphical inventory, picking, etc… I’m trying to figure out how to adapt the Python bindings to their modified Torque engine so I could continue to use Python with Torque (with little success currently).
I really feel that Panda3d is the solution for me along with a few extra bits: wxPython, SQLite, Twisted, Freeworld3d and Maya.
My stumbling block is the creation of the algorithms for stuff that was done for me in Torque and I just had to manipulate with script.
Steve