QuickStart Engine

Hello, I am Bradley Leatherwood, I am currently the LEAD of a team which is going to be making a multiplayer ONLY game for the Xbox - 360. Over the past month my team has been designing and researching during this period I stumbled upon your engine. I see that the planned release of .22 suiting our needs. Is their any chance that our two teams can collaborate in reaching our goals.

Concerns:
Physics (is their ray tracing collision?)
Networking (is smoothing planned using momentum)

I read somewhere that your engine is using two cores for physics, isnt this a bit of overkill? My team's game is not physics intensive, one core for physics seems much more realistic, another one for game, and another for networking. In addition is their anyway to build overhangs into cliffs built into your heightmap system. Crisis has an interesting system allowing you to first build a heightmap then build overhangs and cliff on the height map.


How far along is the editor?
Where can I find documentation?
Does Normal and Cone mapping run well within your engine?
How is indoor Lighting?
Does the engine read in XML (or another scripting language to see where objects are placed.
Trigger and Events?

Our teams should work together to achieve our goals.

Benefits for You:
Your Engine Gets Tested for Development of a XNA Game
Much More Optimized for Creating of Games
Tools and Documentation Much Better
Networking Gets Tested
16 Player Networking is Optimized
Spectator System in Networking is Created

Benefits for Us:
An Engine will speed along development
More Technical Minds in Development
A reusable Engine
Patching and Maintaining Will be streamlined


Please get in touch with me:
bradleat@gmail.com

Bradley Leatherwood
PortalGames.org

bradleat wrote:Hello, I am Bradley Leatherwood, I am currently the LEAD of a team which is going to be making a multiplayer ONLY game for the Xbox - 360. Over the past month my team has been designing and researching during this period I stumbled upon your engine. I see that the planned release of .22 suiting our needs. Is their any chance that our two teams can collaborate in reaching our goals.

Concerns:
Physics (is their ray tracing collision?)
Networking (is smoothing planned using momentum)

Physics support is for the Xbox360 must be pure C#, for which we're currently using JigLibX. I know it supports Ray Tracing, but I believe it is somewhat limited.
Networking was started by one member but never finished, and so currently we have none. Good networking would require prediction, but I'm not sure whether we'd do it in the engine, or leave that up to the game developers themselves, as prediction can change based on needs.

bradleat wrote:I read somewhere that your engine is using two cores for physics, isnt this a bit of overkill? My team's game is not physics intensive, one core for physics seems much more realistic, another one for game, and another for networking. In addition is their anyway to build overhangs into cliffs built into your heightmap system. Crisis has an interesting system allowing you to first build a heightmap then build overhangs and cliff on the height map.

One of our members, Shaw, would be the best person to answer that. But I know that the current state of Xbox360 CLR makes for some very unoptimized floating point math, which hits hard on the use of vectors and matrices, which physics uses all over the place. My guess is Shaw thought we could try to overcome this by using two of the 360's cores.

bradleat wrote:How far along is the editor?

It was started, and then recently scrapped because it was poorly written and inadequate. So it is fairly non-existant.

bradleat wrote:Where can I find documentation?

The only documentation is for the old version of the engine, before it was re-written. I hope to submit v0.195 of the engine sometime today, and I will begin soon on some basic documentation. Some stuff may be re-vamped, so I don't want to write too much just yet.

bradleat wrote:Does Normal and Cone mapping run well within your engine?

Normal mapping should work fine, once we support it. We're working on the infrastructure of the engine before we start some of the fun graphics stuff. I'm not sure if we're determining the normals/binormals/tangents of our models yet in the Content Processor, if not then we'd need that before normal mapping could be used on models. I planned to eventually get the terrain saving out normals/binormals/tangents so we can have normal mapped terrain as an option as well. I've setup normal mapped terrain before based on the same terrain system we're using in this engine, and it runs fine, it requires a few more texture lookups and is a little more GPU intensive of course. Cone Mapping I haven't experimented with, so I wouldn't know on that one.

bradleat wrote:How is indoor Lighting?

We were going to concentrate on outdoor scenes before moving to indoors, as indoor scenes require more optimization, and require artists to produce interiors.

bradleat wrote:Does the engine read in XML (or another scripting language to see where objects are placed.

It does read XML, we currently use it for a few things, like reading-in settings.

bradleat wrote:Trigger and Events?

Those are planned for later. Triggers were going to come when basic AI was started.

I've got to be honest with you. The reason I open-sourced this engine was to get more of the community working on it. I am willing to continue work on it, but it doesn't pay the bills, so I do it when I get the chance, which isn't often. Shaw Mishrak, Sturm, and myself have done all of the current engine except the Audio. All three of us have either full-time jobs, full-time school, or both, and some of us are also married and/or have children. Due to this fact, occassionally very little work will get done for long periods of time, or we'll get a bunch done really quickly. We've just agreed to work on it when we can or want to. But, because it is open-source, anyone is welcome to join in and help. The reason we've laid out a coding guidelines document and code submission process is so that we can make sure new work on the engine continues in the direction that we originally had planned. Like any open-source project, anyone can break off from it and make their own versions of it (although the license requires that they publish any changes to the engine). The only changes to the original must go through the standard review process with the coordinators here. If your team would like to contribute to this engine, to the mutual benefit of us both, I am perfectly fine with that, I would just request that we coordinate it through the coordinators so we make sure that these changes are in-line with what we've had planned. For example, we've had someone outside the team recently add skinned animation to their version. This is something we originally planned anyway, but we've had no chance to see the coding style, and if it fits the engine architecture well, so I can't say we could even use it. Without coordination your team's version would likely diverge from this project's version. Let me know if you have any ideas on this. Shaw or Sturm, feel free to chime in on this if you'd like, or you get a chance.

Our lead in programming recently convinced me that he is comfortable in building an engine from scratch.
Although I would have loved to work together our team had to make a decision. A few key components that we would have been looking for are missing and early optimization for a FPS will lead the engine into a different direction than yours. I do believe that you guys shouldn't stop, make a small demo game once a few more features have been added in like Sky Boxes.
Bradley Leatherwood

Engine from scratch is certain a good way to go as long as you have the time. It really depends on the complexity of the game. Some companies can spend quite a long time on just an engine alone.

If it is generic enough maybe you could even sell it, there is a serious lack of good near-complete C#/XNA engines.

Good luck to you guys. Oh, and we do plan on making a small demo game once we have some of the fancy graphical features to show off the engine.

Yes, hopefully we will be able to.
I am just curious, what lead your team in switching away from codeplex?

The main reason was the Codeplex didn't support SVN. Using the Codeplex Client for versioning was pretty terrible. Sourceforge is so much easier.

Also, Codeplex forums lacked quite a few options, and we wanted phpbb.

Codeplex is a great place to get quick info and download source/executables/documents though, so we still keep it around for that.