Screenshot of the new (incomplete) editor for the BETA v3 release of Clockwork. Screen shows the editor with a level editor window open, and the configuration panel.
Printable View
Screenshot of the new (incomplete) editor for the BETA v3 release of Clockwork. Screen shows the editor with a level editor window open, and the configuration panel.
Love the GUI buttons as well as the window backgrounds. Very nice work.
Are you using MFC or something else. If so, that is a very nice ReBar control you have sitting under your menu area.
I am also curious to get more information, in general, about the project. Your website doesn't really tell a whole lot. On top of Bubba's question, are you using any APIs or pre-built libraries other than OpenGL? What *type* of game are you looking to build? What type of format are your maps stored to, how are they compiled, etc.
Looks really good though, I'm very interested in viewing your progress, keep up the good work!
Generating GUIs has always been a source of a bit of confuzzlement for me...the only GUI's I've 'generated' have been 'hackish' win32 'buttons,' or simple programs coded in Visual Basic. Anymore information on how you generated yours would be very beneficial!
I'm using .NET and Windows Forms for this release (feel free to hit me Bubba, you know you want to ;p).
No generation here though, folks. I did up a few simple gradients in Photoshop, and set them as backgrounds to all the controls. I considered using generation techniques, but decided I didn't have enough time to play around with image generation algorithims.
The only library i'm using other than OpenGL at the moment is DevIL for image loading, which was actually a recent addition after I decided I was too lazy to add support for formats other than JPEG and DDS myself ;}. In the future, i'll probably use Lua for scripting, and possibly RakNet for networking. The physics, AI, and rendering engines are all my own work.
The engine at the moment is really only capable of FPS games, but I hope to gradually extend that as far as MMORPG capability (key word here is gradually. I do not at all beleive that I can write an MMORPG-capable engine for the first release).
The mapping system isn't all that much at the moment either. Quake3 BSPs can be imported as shells that you can fill with the features provided by Clockwork. I'll write my own BSP compiler, after I get all the core mechanics of the engine working properly.
You're right Bob, the website doesn't contain much info about the project. This is mostly due to the fact that I'm always afraid of hyping or boasting about the project too much. That, and the only features that I have that work well and can talk about are in the rendering engine, and I don't want Clockwork to come off as a RenderMonkey clone. Once I get things like physics and AI down, I'll probably start letting out more information.
Well, keep up the apparently good work!!! I appreciate somebody that doesn't like boasting until they have got more to show, I'm just always interested to see what other ppl are up to!
I'm curious specifically to see how you've implemented physics. I've implemented complex solvers for things like hovercraft and vehicle physics, but all of my collision detection hulls are spheres or 'molecule' coupled spheres, have you implemented the physics for boxes, cones, cylinders, anything of that sort?
errr what is it?
Right now i've only gotten as far as collision with boxes and planes (but even that's broken due to my lack of understanding of quaternions). The collisions system could be easily extended to per-poly collision and collision with numerous other primitives.
For a box, I just set vertices at the bounding extents, and do collision checks for those 8 vertices. If I wanted to, I could use the mesh I use for rendering as the collision mesh as well (but this would be rather slow, so it's really only useful for terrains and things of that nature).
@lilhawk2892: It's a no-programming-required game creation system i've been working on. The screenshot I posted doesn't show much to do with games though, it's more to show the new editor design. Shots of the old editor can be seen on my website, and possibly by searching this board.
I can help you with that. I can answer virtually any question about quaternions you have, show you code, etc...we should collaborate!Quote:
due to my lack of understanding of quaternions)
e.g. I noticed 'runge-kutta' in your physics menu there...I implemented an integrator using a RK4 solver that uses quaternions to accurately predict new orientations (this is for a hovercraft btw), converts it to a matrix, etc etc.
Do you do edge/face tests? An edge being the line connecting two adjacent vertexes of the box, the face being the face planes formed by the sides of the boxes.Quote:
For a box, I just set vertices at the bounding extents, and do collision checks for those 8 vertices.
really thats awesome but how good quality a game can it make?
i mean i dont expect the next WoW hit to be made from it..
@Bob: Yes, we should collaborate! Would you prefer IM, or a forum, or somthing else entirly? (I have a forum set up that I intend on using for Clockwork when the time comes. I can give you access to the private development section if you wish).
The most i've done with Runge-Kutta is the integration of basic forces like gravity. I've gone back to Eulers method for now while I get all the basics ironed out.
I haven't gotten to the point of doing edge/face tests (although I have a basic idea of how to do it). I got as far as checking box contact with a plane, and then stopped to see if it would compile and run properly; ever since i've been fighting with quaternions and rotation related stuff, basically stopping me from getting much further ahead.
@lilhawk: well, really with a tool such as this, the quality of the game would really be up to the user creating it.
However, if you're talking about the possible capabilities of the engine, that's a little hard to judge at the moment.
The rendering engine offers all the usual suspects in the eye-candy department such as parallax mapping, per-pixel normal mapping, etc. through the use of GLSL shaders, and as soon as my new graphics card arrives, i'll add support for HDR, deferred shading, and the like.
However, the other aspects are harder to judge ATM. The rendering is fast, but I still need to make it go faster. The physics engine is still in early development, but will probably be comparable to an engine like ODE when complete. The AI and gameplay will be scriptable, so that's almost entirely up to the user anyway (although I intend on allowing the user to avoid scripting as much as possible, if they wish).
Sorry I can't answer your questions a little better, but it's still a little too early to start talking about the engine capabilities, when it's not even finished. :)
Meh, I've been really busy lately with work and I am going to a strict school in less than 2 months...anyway I can help out until then though, I'll def. try to help you out. I just wrote in my spare time something that converts ms3d models to vertex arrays for shamino (well, not just for him, I'm using it too), so I def. am still trying to be useful!Quote:
Yes, we should collaborate! Would you prefer IM, or a forum, or somthing else entirly? (I have a forum set up that I intend on using for Clockwork when the time comes. I can give you access to the private development section if you wish).
>>The most i've done with Runge-Kutta is the integration of basic forces like gravity. I've gone back to Eulers method for now while I get all the basics ironed out.
You'll hate integrating orientations. Trust me :)