Jump to content
Sign in to follow this  
  • entries
    12
  • comments
    10
  • views
    10475

Journal #11: Combat Update

Sign in to follow this  
MagForceSeven

996 views

Combat

In my last entry I mentioned the few things that were really remaining for my tactical gameplay. I spent the time since working on the weapons issue. I added a few more weapons definition entries and updated the ship definitions to be the owner of the weapon slots. Those slots define limitations of that weapon location on the ship like the maximum available firing arc. I also updated my prototype harness so that a bunch of the testing stuff that was in there has been removed and all that remains is stuff that should move forward as part of the tactical game. I make a copy of it first so that I still had a version with that testing stuff that I could go back to though if I need it.

Seemed like a good idea to include some new pictures. The red tiles are those in the arc, a blue tile is the cursor highlight when it's within the arc and a green tile is the cursor highlight when it's outside the arc. The lower right still has the text indicating which player's turn it is and the upper right has a display string indicating the name of the arc being used.

hexwar1.jpg

hexwar2.jpg

Here you can see multiple weapons & weapon selection with two different firing arcs coming from the same ship.

hexwar3.jpg

hexwar4.jpg

I think I have a some technical debt to address before I move onto either of the other two tactical features I mentioned in my last post. The main one is support for STL containers in my reflection system. I need it for a few cases, but the bothersome case right now is that I can't properly initialize my ship definition weapon slots from the data file. And the temporary solution involves a const_cast which is usually an indicator you're doing something weird.

Random

I did a few other random things


  • I switched all the copy constructor or assignments from private & unimplemented to public and using the "= delete" modifiers (see Readings section below)


  • I added some macros to make it a little easier to use my function delegate object. There was a bit of type data duplication, especially when creating a pointer to a class member function. It's a lot easier to use and look at now.


  • I added a placeholder for localization. This may sound a bit crazy, but I'm having to add a lot of to-be localized strings at work so it's at the forefront of my mind and it's one of the things the Unreal makes pretty painless to do when you're working in UnrealScript. Since I don't actually need localization quite yet the entirety of my localization header consists of: typedef std::string localized_string. This way I can at easily identify the things that are display strings and when a real solution goes in (if ever) the compiler should catch just about everything that needs to be updated for me.


    Readings

    I've had a few technical books on my desk to read for quite a while and have spent a good chunk of the new year working my way through them. They've been Effective Modern C++ and Effective STL, both by Scott Meyers, and C++ Gotchas, by Stephen Dewhurst.


    • C++ Gotchas was a little tough sometimes because it was written in 2003 so it's pretty ancient for the tech world. It would have been a better read for me while in college and a few of the "gotchas" aren't really as big of an issue if you're using C++11 or C++14.
    • I've only just started Effective STL but it looks like it's also pretty ancient by tech lifetimes (2001) but I've only just started it so we'll see how well it actually holds up.
    • Effective Modern C++ was pretty great. There were a few things I knew in the back of my head from looking writeups about the new features. My home codebase is still pretty small so it's easy for me to blast in some types of language changes. I had previously already gone through my code and replaced NULL usage with nullptr. As I mentioned above, using "= delete" instead of private unimplemented functions I'm on board with (since it more clear on intent and generates a compiler error instead of a linker one), so I made that change as well. I added a couple of things to my todo list for improvements that I might be able to make to certain things using certain features. I'll probably make a pass to add the override keyword in all the appropriate places as well as start using it for all new code.
    • While reading C++ Gotchas and Effective Modern C++, I've played around with the notion of writing up a coding style guide for my home codebase. I contributed a bit when we revamped the one at Volition to bring it into the world of C++ and it was kind of fun. It would be nice to have something like that around if I ever tried to get someone else to contribute to my projects.

      Random C++ Gotchas musings


      • The "Pimpl Idiom" is also called the "Cheshire Cat Technique"?! How did I never hear this?! That is such a cooler name!
      • The example code for the pimpl idiom was pretty standard except that the structure used as the implementation had private members and accessor functions. What is the purpose in that? You're already isolated from the client code through the private-ness of the pointer and the API of the public data structure. I seems weird to then force your own code to go through a second API for data access. Maybe it was just copy/paste.
      • It suggested using 0 over NULL due to implementation differences in the macro. I couldn't get behind that. NULL indicates intent to the reader in a much clearer fashion. Shouldn't be an issue going forward as everyone should be using the built-in nullptr.

Sign in to follow this  


3 Comments


Recommended Comments

Agree with the NULL, though yeah, nullptr is better these days.  I could see still having private/publics, just to make tracking down where data is being accessed, and ensuring that code doesn't get too spaghetti like.   If I suddenly have to stop and write a bunch of accessors, which I hate doing, it usually has me stop and think if I'm doing the correct thing, or if I'm heading down a bad road.

Share this comment


Link to comment

Items seem to get lost in the bright tiles beneath.

 

They do a little.  I haven't made any effort in that area quite yet, partly because I'm pretty sure I need to do something drastic like swap out my whole rendering solution to something else.

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!