Jump to content

My New Mantra - keep it simple



After a few of weeks of programming burnout I am now back in action. i think I was starting to feel a bit swamped with the increasing complexity of my project amongst other things however things are looking a bit rosier now. I probably should have sat down and made a proper plan because of all the dependencies of the various elements.


My history with Leadwerks has been somewhat chequered and I have struggled for along time trying to do stuff with it in the past. However lately things just seem to be clicking so I have decided to move my main project over from Xors3d to Leadwerks. Xors is a good, easy to use engine but it has certain flaws which make it less than ideal for my purposes plus I am more of an OpenGL man.


My aim is to make a sort of strategy/vehicle combat type game in the vein of battlezone/armourgeddon/carrier command. Due to my limited programming skill I am trying to make it as simple as possible at the moment.(Still seems pretty damn complicated)


What I have so far:.


Vehicle mesh loading - Had to write my own mesh loader to overcome certain problems


Vehicle navigation - nothing fancy just point to point. I will probably have to add some simple(if there is such a thing) obstacle avoidance at some point. I have a sort of an idea about a passive avoidance system but haven't experimented with it yet.


Order System - only 4 order types at the moment (only 1 thats actually working!) - vehicles and other entities will be controlled by orders


Turret system - controls turret rotation/aiming - turrets attach to vehicles


Gun system - controls the firing ie when to fire,where to fire from, reload times, etc - guns attach to turrets


Projectile - guns fire projectiles - deals with collisions - projectile types and effects. One thing I am particularly keen to have is proper lighting on missiles and explosions ie so the landscape will light up when they fly past or explode.


Arbitrary world partition system - manages vehicles and other entities - vehicles need to know about other vehicles and buildings in their vicinity whether they are friendly or not. I call it arbitrary because the world sectors can be any position, and theoretically any size, in 3d space. There are probably better ways to do it but in keeping with my mantra i am keeping it simple,


Things to do.


Next step is probably create some different particle effects for projectiles and explosions.


Implement some actual vehicle behaviours - now that I have the order system in place vehicles should be able to issue their own orders under certain conditions ie aggressively pursuing detected enemies.


I am kind of excited as I feel I am actually quite close to having something that will soon have a life of its own, just a couple more hills (mountains) to climb.


Recommended Comments

Guest Red Ocktober


whether you choose Leadwerks or XORS is really irrelevant to managing the complexity of the game you've described...


first a question... do you think it's easier to program an entire game at once, or do you think it's easier to program a single element of a game...


would focusing on a single element of the game (the car for example) make it easier to manage and develop the logic... i mean, as opposed to trying to focus on many things at one time (scenery, game objects, effects, ai, navigation)...


i think it would...


an objective programming approach would allow you to focus on one aspect of the game at a time... the vehicle for example, develop it so that it can exist as an independent entity within the game world that you're creating...


only give it what it needs to be a vehicle... nothing else...


then, when you need it you can just drop it into a game (instantiate a vehicle object) and it'll work...


and... when you're ready to add ai, you can just create the type of behaviors you need in a aiVehicleController class, focusing just on that part...


the important part of the object oriented approach is that it allows you to to focus on one thing, and just that one thing... breaking a complex set of tasks into smaller, discrete, and more manageable ones...


good luck...


on yeah... there is one caveat...


object oriented development requires a lot of thinking be done before you start coding... in short you've got to have a well thought out plan...



Share this comment

Link to comment

Mike that comment could be another blog post in itself :D


But I do agree with Mike - object oriented is the way to go but plan plan plan! if you fail to plan you plan to fail...

Share this comment

Link to comment
Guest Red Ocktober


whoa... that is a looooong one, isn't it...


sometimes i do get a lil carried away... sorry...

my only excuse is that when it comes to OOP programming, i proclaim... I Am The OOP Evangelist!!

:D :D



Share this comment

Link to comment

Evangelise away :D it was a good read. I'm not sure why you think I haven't taken an OOP approach to this, I thought I had spelled it out pretty clearly.

Share this comment

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Blog Entries

    • By Marcousik in Marcousik's Creations Blog 3
      I updated the moto I was working on and now the physics let having fun with this.
    • By Josh in Josh's Dev Blog 24
      Current generation graphics hardware only supports up to a 32-bit floating point depth buffer, and that isn't adequate for large-scale rendering because there isn't enough precision to make objects appear in the correct order and prevent z-fighting.

      After trying out a few different approaches I found that the best way to support large-scale rendering is to allow the user to create several cameras. The first camera should have a range of 0.1-1000 meters, the second would use the same near / far ratio and start where the first one left off, with a depth range of 1000-10,000 meters. Because the ratio of near to far ranges is what matters, not the actual distance, the numbers can get very big very fast. A third camera could be added with a range out to 100,000 kilometers!
      The trick is to set the new Camera::SetClearMode() command to make it so only the furthest-range camera clears the color buffer. Additional cameras clear the depth buffer and then render on top of the previous draw. You can use the new Camera::SetOrder() command to ensure that they are drawn in the order you want.
      auto camera1 = CreateCamera(world); camera1->SetRange(0.1,1000); camera1->SetClearMode(CLEAR_DEPTH); camera1->SetOrder(1); auto camera2 = CreateCamera(world); camera2->SetRange(1000,10000); camera2->SetClearMode(CLEAR_DEPTH); camera2->SetOrder(2); auto camera3 = CreateCamera(world); camera3->SetRange(10000,100000000); camera3->SetClearMode(CLEAR_COLOR | CLEAR_DEPTH); camera3->SetOrder(3); Using this technique I was able to render the Earth, sun, and moon to-scale. The three objects are actually sized correctly, at the correct distance. You can see that from Earth orbit the sun and moon appear roughly the same size. The sun is much bigger, but also much further away, so this is exactly what we would expect.

      You can also use these features to render several cameras in one pass to show different views. For example, we can create a rear-view mirror easily with a second camera:
      auto mirrorcam = CreateCamera(world); mirrorcam->SetParent(maincamera); mirrorcam->SetRotation(0,180,0); mirrorcam=>SetClearMode(CLEAR_COLOR | CLEAR_DEPTH); //Set the camera viewport to only render to a small rectangle at the top of the screen: mirrorcam->SetViewport(framebuffer->GetSize().x/2-200,10,400,50); This creates a "picture-in-picture" effect like what is shown in the image below:

      Want to render some 3D HUD elements on top of your scene? This can be done with an orthographic camera:
      auto uicam = CreateCamera(world); uicam=>SetClearMode(CLEAR_DEPTH); uicam->SetProjectionMode(PROJECTION_ORTHOGRAPHIC); This will make 3D elements appear on top of your scene without clearing the previous render result. You would probably want to move the UI camera far away from the scene so only your HUD elements appear in the last pass.
    • By Josh in Josh's Dev Blog 6
      A new build is available on the beta branch on Steam.
      Updated to Visual Studio 2019. Updated to latest version of OpenVR and Steamworks SDK. Fixed object tracking with seated VR mode. Note that the way seated VR works now is a little different, you need to use the VR orientation instead of just positioning the camera (see below). Added VR:SetRotation() so you can rotate the world around in VR. The VRPlayer script has rotation added to the left controller. Press the touchpad to turn left and right. Any arbitrary rotation will work, including roll and pitch. Here are the offset commands:
      static void VR::SetOffset(const Vec3& position); static void VR::SetOffset(const float x, const float y, const float z); static void VR::SetOffset(const float x, const float y, const float z, const float pitch, const float yaw, const float roll); static void VR::SetOffset(const Vec3& position, const Vec3& rotation); static void VR::SetOffset(const Vec3& position, const Quat& rotation); static Vec3 VR::GetOffset(); static Vec3 VR::GetRotation(); static Quat VR::GetQuaternion();  
  • Create New...