Canardia

Yeah, it's a lot like the latest LCP1, but much improved, especially art wise. I like how fast the lifted objects are positioned in front of the player, because in LCP1 using normal engine functions it takes much longer. About loading screen, I have done it like this: double LoadingScreen_i=0; bool LoadingScreen_done=false; void LoadingScreen( void *dummy ) { HWND hWnd = game.window.hwnd; HDC hDC = GetDC( hWnd ); HGDIOBJ original = NULL; original = SelectObject( hDC, GetStockObject(DC_PEN) ); SetDCPenColor( hDC, RGB(0,255,0)); while( (LoadingScreen_i<game.window.sx-200) && (!LoadingScreen_done) ) { MoveToEx( hDC, 100, game.window.cy+10, NULL ); LineTo( hDC, 100+LoadingScreen_i, game.window.cy+10 ); LoadingScreen_i+=0.00004; } SelectObject( hDC, original ); ReleaseDC( hWnd, hDC ); _endthread(); } int main(int argc, char* argv[]) { ... game_logo.Load("abstract::gamelogo.dds"); // show some loading screen picture SetBuffer(BackBuffer()); DrawImage(game_logo,game.window.cx-BufferWidth(game_logo)/2,game.window.cy-BufferHeight(game_logo)); DrawText(game.window.cx-TextWidth("Loading...")/2,game.window.cy-FontHeight()/2,"Loading..."); Flip(0); _beginthread( LoadingScreen, 0, NULL ); game.scene.LoadMap("abstract::map1.sbx"); ... all other setup code here ... LoadingScreen_done = true; // tell the loading thread to end // main loop while(!done) { ... } }

I can make a demo soon, but first I need to optimize it a bit more. It's still too slow when used in a real game, even when it seemed not to take too much FPS in the tech demo

Only the dynamic setting is new in LE 2.3, but the command is also in LE 2.28.

It's only esoteric knowledge, since I wrote also the netwerk headers and noticed this behaviour while testing it The reason is probably somewhere deep inside the way how BlitzMax's garbage collection works, and it will be fixed when LE 3.0 is written in C++. Garbage Collection languages allow so many hidden bugs that you can never know how many bugs your program still has, since it doesn't crash immediately but completely randomly depending on time.

It might be, I have to try different methods and see which takes the least FPS. Also the cube physics shape might not be the fastest, although I heard that the primitive shapes on Newton are much faster than any custom composed shapes. I could still try if a tetrahedron physics shape would be faster than a physics cube.

http://www.leadwerks.com/wiki/index.php?title=Entities#EntityShadowMode

I'm using physics rain, it doesn't look as good as graphical rain, but it works better. For example the rain drops don't fall inside buildings, and you can look out of a window and see rain outside, and no rain inside. What also works better is that the rain drops can cast shadows like real rain does, and the rain drops can be lit by lights, which makes it look good in the night also. Around 1000 cubes doesn't slow down the FPS too much, but it depends how low your FPS originally was. With 100 cubes you still get decent rain, but not so heavy of course. Of course the center of the rain area always follows the camera, so you don't need so much rain drops. Maybe if it was possible to write a smear shader, then the rain drops would pull tails behind them.

Networking is not only for entities, it's basically just a hack to exchange data because not all computers are tied together via the same RAM memory.

You need need to initialize netwerks before the engine, and terminate it after the engine.

I think nvidia is faster than ati, for example in the Toshiba Qosmio series.

I don't think you can export IK animation from 3DSMax, or maybe it exports something which they call "IK", but it's not real IK. Real IK, or should I say IK+, is based on a lot of AI, where each limb is moved separately, and no hardcoded animations are needed. The AI alone makes the character walk and the physics gives the IK+ feedback from collisions, to which the AI must respond too, for example by taking balancing maneuvers when the model is hit from the side. One of the Havok addons has something similar too.

Well, you don't really import anything into Leadwerks Editor, but you just link to them and access them directy. The sbx file is a text file which has links to all assets used in the scene. A gmf model needs also a minimal Lua script (2 lines) to enable the GUI properties menu for the model. It also needs a mat file which tells which textures to use. Usually also a ini file is needed to populate the model with some keys, like collisiontype, model group, etc... Those are custom keys which are used by your game code. If the model is mobile, then you also need a phy file which tells the engine what kind of physics shape the model has. If the model has also IK animations, then you need to add some code for the assembly of the ragdoll's physics bodies and joints to the Lua file.

There's 3 main methods to import models to LE, which means that you have anykind model format which will be converted to gmf (game model format) model format: 1) Using the converter tools from the SDK. There are about 10 different converters from various formats to GMF in the SDK/Tools folder. 2) Using UU3D. Commercial software, costs around $60, but is way worth it since it allows you to convert hundreds of formats to gmf, and also shows you all kind of errors (vertex normals, face directions, texture assignments, bones, etc...) in the mesh which you can fix in UU3D too. 3) Using 3DSMax direct export to gmf script.

It doesn't work with Newton that way, I've tried it already. It just starts to shake and Newton goes nuts with the forces when you try to lift an airplane from its wings. What you have to do is to assume a UFO flight style and then degrade it to an airplane flight style. So you just use a global vertical lift to the body of the airplane, no matter in which rotation it is, and control the altitude that way.

Shouldn't physics stop it from going through obstacles too, and how would physics collision affect the waypoints then?

It looks like you're basically just filling areas with waypoints, probably somehow automated so that you don't need to set each of those waypoints manually. When there's an obstacle between the npc and the target, then there would only waypoints around the obstacle, unless you have a waypoint on top of the obstacle too, which would allow the npc to jump over the obstacle. Then you only need an algorithm to connect all the waypoints between npc and target, which is probably similar as walking directly to the target, but each waypoint would be a subtarget.

http://leadwerks.com/forum/viewtopic.php?f=32&t=4580&start=0

Yeah, I had similar things in Uni also, and it felt stupid and ineffective at that time, but today I find they did the right thing. Uni should focus on theory only, and forget about practice, since you're not supposed to code yourself anyway if you are smart, because then your skills are much more effective at a manager position where you just design theoretically and the (outsourced) programmers do what you say. Another thing which is good when doing theoretical design, is that you have the documentation in Nassi-Shneiderman diagrams already before the code was written. It forces also the code to be correct and bug free, since in theory you can't make non-working programs using that diagram. At least you can't make endless loops and paradox jumps. Flowcharts are strictly forbidden at Unis for software documentation, because they are not meant for that. Even in Visio Flowcharts don't belong to Software documentation diagrams, but Nassi-Shneiderman does.

You posted it on old forums on 2009-07-01, and edited it last 2009-08-29. Considering that you probably worked around 1 hour each day on it after initial release, and 2 hours each day for one month before it, I would estimate that it took around 1 month to write BallWars using 4-hour days (=indie days).

Haven't tried that yet, but yesterday I found something similar: You can add a class to a C++ project, and it creates the .h and .cpp file via a Wizard. The amazing thing was that the formatting was 100% correct according to global standard, I didn't have to edit a single character as it was perfect: tabs, intendation, line spacing, pragma, void parameters. LEO is using the same style standard, so it works much better with VS than some wild coding/formatting style.

How long did BallWars take on each of those steps? It would be a good reference to add to the chart.

They work fine, but you need to put the hardware acceleration level to basic if you don't have a SoundBlaster Live! or better card. Vista and 7 does not have this setting, so you can't use a embedded sound chip with those OS. With XP you can use any sound card.

Here's a first attempt:

Well it shows that time plays the most important role when making a finished game. I could try to make a list of how much time is needed for certain game features.

It's a standard feature in VS2008, you just click on the button to show your project's classes as UML.