FreeGameDev Planet - Development

I’ve linked my Twitter account from the OGRE Team page for a while now, but I’ve been told that’s not really obvious enough!

So, if you want to follow my tweets related to OGRE, graphics & tech in general, and occasionally some random other stuff, here’s my Twitter page. In the interests of making it easier to find in future, I’ve added a link to the navigation bar on the left too.

Enjoy!

It has been brought to my attention that the LICENSE file in orx's package is an incorrect one.

 

Orx is currently licensed under LGPL (and NOT GPL) and the LICENSE file will be properly updated in the next release. =)

 

If you'd like a special licensing scheme so as to modify orx's source without having to publish your modifications, please contact us!

 

- iarwain 

Our procedural terrain demo (see kambi_vrml_game_engine/examples/vrml/terrain in SVN) got a lot of improvements this week:

• Heterogeneous terrain (idea from Ken Musgrave) implemented, this makes more realistic terrain (smooth valleys, noisy mountains).
• Terrain is rendered with nice blended texture layers, normals are calculated for fake lighting, fog may be used, all by simple GLSL shader.
• Simple LOD approach for rendering is used, this is an ultra-dumbed-down version of geometry clipmaps. The way I simplified this is unfortunately painfully visible as LOD "popping" artifacts. But, hey, at least I can view really large terrain.
• You can test various noise interpolation methods, including Catmull-Rom splines.
• 2D noise can be blurred, which (may) improve the terrain look.
• You can switch camera to Walk mode.
• You can add a heighmap from grayscale image to generated terrain.
• Rendering uses VBOs for speed.

Finally, the programmers may be interested in my my notes and links about basic terrain generation methods.

Sony just unveiled a few more infos and pictures of their new motion controller, the thing will be called "Move". Some key points so far:

• the thing is not symmetric, you get a special Nunchuk controller for the left hand just like on the Wii
• the Nunchuk lacks motion detection
• the Nunchuk features L1/L2 shoulder buttons, a dpad and an analog stick, it also seems to duplicate the X and O buttons from the main controller
• the main controller has a large main button, only a single trigger, no analogstick and the four classic face buttons, Start and Select are on the side of the controller
• counting all buttons together it is the same number as on a regular PS3 controller

Overall I am pretty disappointed by the lack of a second analog stick, which will likely result in ugly and broken camera control in the games to come, as it already did on the PSP and the Wii. The lack of motion detection in the Nunchuk and the non-symmetric controller design is rather disappointing, as it would have allowed simple two player games to work with a single controller setup (each player gets one half of the controller). It also means that games can't make use of two virtual hands, which would have been much more natural. The choice of having a single trigger on one controller and two on the other is a little weird, but shouldn't be that much of a problem, as you got a new face button on the main controller. I would however have preferred a Gamecube like button layout, as the current layout doesn't seem all that comfortable or logical.

Update: Looks like Sony has no clue what they are doing. First they create a controller without dpad, without analogstick and without face-buttons that could be abused for directional control, then they develop a Nunchuk (officially called sub-controller) that lacks motion sensing and then they still end up demoing gameplay where the player needs two Move controller instead of the Nunchuk, see this and this.

For quite some time we've had our default world Mason. While Worldforge is a project aimed to provide basic tech for any kind of virtual world, we still need to have a showcase world in which we can try out different things. The default world has had some issues however.

• It's not using much of the new media provided by Jayr, and the media used is often outdated.
• It's confusing for newcomers. There's not clear direction of what new players should do in the world.
• The steep mountains surrounding the area are hard to manage in a client, as the steep cliffs makes level-of-detail optimized rendering hard.
• It's a quite small world.

All of this is changing as I've been working on a new default world. There are a couple of improvements to both the server and client which allows for this.

• Persistence on the server. As cyphesis is a work in progress, it's possible that bugs are uncovered when developing the world which will cause a crash. Having the whole world disappear when the server crashes is quite unproductive. With constant database persistence there's no risk of that.
• The ability to take a snapshot of the world on the server. This snapshot is saved as an xml file, which can then be added to a versioning system. This way it's possible to try things out, and revert to older versions if needed.
• Freezing the world on the server. When designing the world it's important that it doesn't change. That means that trees shouldn't grow, animals shouldn't move, living things shouldn't starve. Through a new feature which allows the server to be frozen any world author can first design the world, and once that's done unfreeze it.
• Advanced entity editing on the client. It's important that it's easy to edit all aspects on the fly on the client. The advanced entity widgets available in Ember allows for this. Aspects such as terrain areas or terrain modifications are easily editable through a point and click interface.
• Easy entity creation. Just as important as editing entities is making sure it's simple and quick to create new ones. The Entity Recipe system in Ember allows for entities to be created with point and click, with a powerful scripting environment in the backend.

The new world is therefore created in a series of steps. The first step involves working with a frozen world, where all entities are placed, and all terrain is sculptured. Once the world is complete it needs its npcs and creatures to be given behaviour and goals. This should be done using the existing python scripting in cyphesis. Once that's done the world should be available as both an xml file defining all entities and an accompanying python script file which defined behaviour.

When creating the new world there are a couple of goals I've had in mind.

• Use as much of the new media as possible, while clearing out any out of date media (i.e. media which simply doesn't look so good any more).
• Provide a large enough world that it will take some time to traverse it.
• Make the terrain friendly to any clients. That means avoiding too steep cliffs as that brings havok to any LOD mechanism.
• Provide a clear path for any new player. There should never be any confusion of what the player is supposed to do once he or she has entered into the world.
• Provide new game play. Apart from our current pig herding and fishing game play we have many ideas of additional tasks. These tasks also require a larger terrain, and new media.

So far things have gone very smoothly. Working with a much larger world is also good for Ember since it really pushes the engine in terms of memory usage and performance. Our current world is simply too small to really take advantage of the many dynamic paging features in Ember.

Below are a couple of screenshots of the work in progress. Some of them show the new starting area, which is on a peninsula with a clear path to the main area. Together with a couple of helpful signs and a greeting npc it should be much more clearer for any newcomer where they should go.

AMD announced that it’s giving away a free version of Pixelux’s DMM2 material physics engine to selected game developers. Pixelux has also just announced that its DMM2 physics engine now includes Bullet Physics as the default rigid body physics system.

“”We’ve enabled tight integration of our DMM2 system and Bullet Physics, giving developers a sophisticated, yet easy-to-use physics pipeline they can use to create things that have never been seen before.”

See the press release at http://www.amd.com/us/press-releases/Pages/amd-ecosystem-2010mar8.aspx
Related link: http://www.thinq.co.uk/features/2010/3/8/amd-gives-away-gpu-physics-tools/

We are applying for Google Summer of Code 2010. Everything you need to know about jME’s involvement in GSoC will gradually appear on our dedicated GSoC wiki page as things progress.

Right now our top priority is nailing down certain essentials before we’re ready to send in our application, which deadline is 13. March. The bulk of these essentials are explained in our newly created roadmap. You might not have seen jMonkeyEngine 3.0’s feature set ‘bulleted’ in full like this before, so give it a peek!

Most important is the ideas list, and we need your help! Please drop by the board and share any feature suggestions you might have! Some additional guidelines are on their way.

Orx + iPhone from iarwain on Vimeo.