Let's Code... an MMO
sea-of-memes.com
sea-of-memes.com
1) Students learn about assembly, opcodes, etc. They write programs for an imaginary machine and only run them on paper for now.
2) Students write their own CPU emulator (in C) that can run and test the simple programs from 1.
3) Students write a compiler to a simple HLL which allows them to write more complex programs, and test against the emulator.
4) Students build the processor which was being emulated in HDL, and download it to FPGAs, testing outputs of the programs generated by their compiler against the emulator.
I think most schools already do something like this, but mine missed the compiler part.
The problem with that is that encompasses what have become two disciplines -- computer science, and electrical or computer engineering. I took classes encompassing both sides because I liked the classes, but most people are really interested in one or the other.
My school offers each concept individually, but they're not related.
Can anyone think up a reason why spherical bounding boxes would be beneficial here?
There are some false positives, but as with many things in game development 'close enough' usually works pretty well.
If you're really concerned with efficiency you should look into other data structures than an octree. Octrees are a nightmare for cache performance (like most other tree based structures) and cache utilization is usually the bottleneck on modern CPUs.
If you're interested in the subject this book (http://realtimecollisiondetection.net/books/rtcd/) covers everything extremely well.
Take the code he posted with the article, and modify it to use a box-frustum check instead. Don't forget to test the program's performance before you make any modifications so you'll have something to compare to. Even better, keep the code intact and #ifdef'd out so you can toggle between the two.
Then, compare the differences. Check to see how many false positives there are on average, and how much extra data this means gets sent to the GPU. Keep in mind, however, that extra data being sent to the GPU doesn't matter unless the GPU is actually the bottleneck.
My hypothesis is that the way the octree abuses the cache will overshadow the performance gains (if any) you'll make by using something other than spheres for your test. In the end you'll find that if performance in this part of the code is a problem, you'll need to switch data structures.
It really depends on the library/engine you are using (if you're using one!) OGRE3D integrates well with several packages, Unity has a builtin GUI system that is stupendously inefficient, and the list goes on...
Fortunately, you don't really need to reinvent Qt or CSS to get the job done. A font system and a few hand-coded controls usually suffice.
I think the bigger problem is in sound synthesis and processing. This arena still remains mostly confined to reverb algorithms, crossfaded tracks, and pre-recorded samples, yet the depth of the subject goes about as far as graphics does. So we're really missing out in terms of applying technology to creativity here.
You trade some flexibility and input latency for a simple imperative structure that is easy to implement.
I don't mean to be negative, like the guys friends that laughed at the project - but coding an MMO is several orders of magnitude more complex than putting together an Octree renderer.
Best of luck with it, but, so far, nothing to see here.
However, I'm also cheesed at the misuse of the term MMO, Minecraft is pretty close but the lack of a centralized game world in any way makes it unlike most MMOs, and by extension doesn't really fit the term. It is merely a persistent multiplayer construction set. N8 (Neverdaunt) or Wurm Online (which notch had formerly worked on), for example, are similar construction-oriented games that definitely fit the MMO moniker because there /is/ a centralized persistent game world. Dealing with the side effects of such a architecture does make things an order of magnitude more complicated.
An Octree is just one technique to reduce the size of the Potentially Visible Set of geometry that is sent to the rendering pipeline. While its a quite a natural fit for a voxel-style world, such as minecraft, there are many techniques to achieve this; an octree just being one.
If the Octree was the core technical challenge and data structure used to create every MMO, then I'd have no issue with the article. But its really not - its a simple technique, graphics 101, used to speed up rendering (or collision detection).
Further, just having an octree is not nearly sufficient for handling MMO scale issues - a lot more needs to go into structuring the world - when those larger challenges are solved, I'd like to read his article on it.
If I see an article about coding an MMO I expect to read about the complexities of scale and persistence, and supporting a consistent gameworld for a lot of players - these are the main challenges unique to an MMO.
Those who succeeded all did NOT focus on their technology when talking about their project and seemed to focus more on getting it to a point where you could actually play something.
Of course you'd think that for a mmo a good technology base is key, but it isn't because if you're honest: Your mmo won't attract a that large crowd in such a speed that you won't have time to merge to something better and spend the money you've earned from your customers of the first hour on improving scalabililty.
Find something fun, get it done and then make it work would be my advice to any aspring independent gamedeveloper.
Creation is never to be sniffed at.
I think the most fantastic thing about Pygame is the huge library of open games on its website. I wish these 3D framework sites had that.
I spent a couple days writing wrappers around pyogre to do things like game state management, nice GUI APIs, etc, and after that it was clear sailing. I wish I had more time to work on the game all that stuff was for, really, but such is life.