Just thought I'd raise a few points about how we're approaching this in general, since its starting to look like a game now =D
First off, I'm getting confused by the number of files there are with multiple class/interface definitions in them. Was wondering if this was a temporary measure or the way you guys want do it. I never put more than one class definition in a file unless its a private class (which is rare as-is). Mainly just a concern as it makes it hard to follow where things are. I have a multitude of files ready to be synched, but I can't integrate them properly because of said definitions for things I have that clash with what's there.
Second, and mainly - I don't want to step people's toes by rearranging stuff the way I like it, so I think it would be a good idea to have a discussion about core standards. I'll go ahead and upload what I can right now, but its going to take a bit of fiddling. I feel that a stronger approach to organisation at this stage will prevent problems from arising in the future.
Tower class structure is about 50% in place, though I've made a few assumptions at this stage about what we might need which you will see reflected in the outline implementations and interfaces. Provisions are there for upgradeable entities (towers/weapons), selectable objects (towers/monsters) and (guess work here) some kind of unified update() interface.
Regards.
Subscribe to:
Post Comments (Atom)
What is clashing at the moment? With regards to the objects, I had planned to create a generic GameObject superclass with collision built-in, since most of our objects will have pretty much identical attributes and behaviour.
ReplyDeleteRegarding the class/file thing- I'm not too bothered TBH. If we start using a lot of files it will get messy though and we weill need a clear directory structure.
Also before implementing the Towers and such maybe we should all have a talk about how everything in the game will interact.
ReplyDeleteMy thoughts-
We should have a Bullet class and a Gun class - Towers and Enemies can own Guns, Guns own Bullets. When a tower gets an upgrade, should we not just give it a new Gun? Tower doesn't need to know anything else (perhaps tower.addHealth()). Guns have range, rotational scope, and firing properties. We can stick any combination of guns to a Tower or Enemy. This way upgrades are supported by default with no additional code. All we would need is a 'Decorate this GameObject with these Guns' call to the GameObject superclass.
I'm thinking aloud, these are just ideas. Let me know your thoughts.
I've been putting the interface definitions next to the classes when there's only one implementer - the interface is there really for testability. If there were to be more than one I'd probably split the interface into a different file.
ReplyDeleteSam - as far as the Tower/Gun/Bullet structure goes, that sounds pretty much exactly what Niall and me were discussing the other week. Makes sense to have guns being pluggable - no special case code for the Monsters.
How does a video chat to sort this out on Wednesday sound?
I'm game for that, not a big fan of message boards/forums etc - can never get my point across properly. Feels a little passive-aggressive, like leaving notes on the fridge you know lol..
ReplyDeleteSo when's good for you Sam? 20:00?
ReplyDelete20:00am or 20:00pm? PM is fine
ReplyDeleteSounds good. also, couple of things to read in the mean time:
ReplyDeletehttp://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html?page=1
and
http://stackoverflow.com/questions/28160/multiple-classes-in-a-header-file-vs-a-single-header-file-per-class
When you're moving things about a lot, as I was when I started writing code in this project, source control adds an overhead to dealing with multiple files. Every time you rename/move a file, you have to exclude it from the project, do the source control operation, then re-include it in the project. When these interfaces become useful (some of them don't even have anything in them), then i'm all in favour of splitting them out - by that point we'll know where they should go.
ReplyDeleteI agree with Gary. I checked in Code Complete 2 - and it says that classes should always be put into their own files; but when I'm developing and constantly switching up the class structure it is much, MUCH easier to stick to one file.
ReplyDeleteSo we should move the classes into files when we finalise the structure of a particular element. Otherwise we end up with source-control hell.