Muse

Members
  • Content count

    200
  • Joined

  • Last visited

Community Reputation

254 Neutral

About Muse

  • Rank
    Member
  1. A completed game with actual gameplay and perhaps even a victory condition always impresses me, even if it's written in TI-Basic. You are correct that it will tell your prospective employer little about your facility with C++. Expect for them to test you, either with a take-home test, interview problems, or both. That will likely be their primary consideration, but a project that shows a genuine enthusiasm for game programming may help you get the interview in the first place. I glanced briefly at one of your source files. If I had been interviewing you, I would have asked you to defend your decision to store block position in matrix form in your Block class. Can you propose something else that is cheaper in memory and about equal in time? As far as being tested goes, study up on problems that require facility with pointers, like implementing standard operations on a linked list. These often trip up programmers who come from a pure Java/C# background.
  2. Infinite Loop at Quit

    Maybe Direct3D is trying to warn you about memory it thinks might have been leaked by the process? If I were you I would probably try to debug this by breaking at that address in kernel32.dll and then exploring what is living at the address being warned on (01785980 in the first example). You may see a vtable symbol, which would be a dead giveaway. Besides that, you have the size (0x38), and whatever patterns you can deduce from what is in memory. The other thing you can do while broken in the debugger is try to look up the function names for the addresses given in the stack trace. That might tell you a lot as well.
  3. Wheel of Time MMO and Eye of the World movie

    Well said about Jordan's dedication. I'm sure he kept on creating to the bitter end, and no Aiel waiting to spit in the Dark One's eye on the last day could say any more. Tai shar manetheren. I've enjoyed Sanderson's Mistborn trilogy and I look forward to seeing what he does with book 12, but I'll still miss the old master (grain winnowing chapters and all). Also, I think a WoT will make a brilliant MMO. There's a license I'd kill to have. They have, not only a fantastic world, but a fantastic assortment of classes that readily suggest themselves from the source material. Who has read the books and not thought of being an Aiel, or an Aes Sedai, or an Asha'man, or a Seanchan with a frikkin flying mount. Not me! I hope Red Eagle is up to it. If the game stinks I'll cry.
  4. Well That Shatters My Entire Universe...

    well, every non-zero number has 2 square roots. In this case, -4 has the two roots {2i, -2i}. When you plug those into your equation (i * sqrt(x) ), then you can see how you wound up at the answers {2, -2}. But you seemed to prove this yourself pretty effectively, so good job.
  5. Quote:Original post by CodeZero So, I still have classes defined that handle the specific data and methods associated with a certain ability set. Instances of these classes get appropriately created then passed to a unit through RegisterUnitAbility(). Does the unit then store away that instance in a list of abilities? Then when the game needs to know whether a unit can do a certain thing, it looks through its own list for an instance of that ability type? Are there any drawbacks to doing it this way? Would performance suffer? This sounds like it might be what I'm looking for. Right, what I was imagining was, the BaseUnit class would maintain a list of references to all the AbilitySets that had registered with it. BaseUnit would own them for the rest of their lifespan and be responsible for cleaning them up in its destructor. For unit abilities that the user invokes, such as "Make Marine", the BaseUnit::RegisterUnitAbility method would need to associate that ability with the user input that activates it. BaseUnit would need to maintain a table like: Input Ability Name UnitAbilitySetIndex AbilityIndex ------------------------------------------------------------- '1' key "Make Marine" 0 0 '2' key "Set Rally Pnt" 0 1 '3' key "Fly Mode" 0 2 '4' key "Fire Cannon" 1 0 '5' key "Siege Mode" 1 1 ------------------------------------------------------------- If the '3' key were pressed, BaseUnit would then call something like: m_AbilitySetList[0]->InvokeAbility(2); (note that it would definitely be possible to improve this to get rid of the heavy use of numerical indices, which could become a problem if you started needing to do inserts into your list). For some kinds of passive characteristics like "Piercing Damage Resistance: 0.5", it might make sense for BaseUnit to maintain a list of resistances and vulnerabilities and then assemble a set of values out of the union of all its AbilitySets, but of course you'd need to think carefully about what happened if ability sets had contradictory characteristics. If you need to implement a method like BaseUnit::AmIUnit(string unitName), the easiest way is definitely to scan the BaseUnit's list of registered AbilitySets, just as you said. It's possible this could become a performance liability but I doubt it. Optimize last :-)
  6. This doesn't sound like a job for inheritance to me. You really only have one unit type--it just happens to be able to do everything, except for certain abilities which are disabled in a text file. You can still break it up into sub-classes for convenience and reusability, and then use aggregation to glue them all together. I imagine something like: class BaseUnit { static BaseUnit& BaseUnitFactory(set<string> UnitAbilitiesList) { BaseUnit* bu = new BaseUnit(); if(UnitAbilitiesList.contains("Barracks") { bu->RegisterUnitAbility(new BarracksAbilitySet())} if(UnitAbilitiesList.containsZ("SiegeTank") { bu->RegisterUnitAbility(new SiegeTankAbilitySet())} //...etc if(bu->NumUnitAbilitySetsRegistered == 0) { /* error! must have at least one ability set registered */ } return *bu; } } //abstract class embodying the interface of an AbilitySet. Would contain methods //allowing for generic ways to call unit abilities, like ::ExecuteAbility(index i) class AbilitySet { } //implementations of AbilitySet class SiegeTankAbilitySet: public Ability Set { } so I guess I would use a little inheritance. It wouldn't be the main dish though :-)
  7. Dear Developers

    Quote:Original post by jbadams You just missed the point. The programmer who produced the instructions isn't expendable. The coder who gets given those instructions next is. OK, I can agree that a coder in the sense that Oluseyi defined him is an expendable resource. I just haven't met anyone working professionally who meets that description (outside of transitional ramp-up exercises, which are meant to be didactic anyway). I don't think I've seen any job reqs for "human encoders" either; what sort of companies do they work for? I'd guess really big, process-heavy ones; maybe IBM or Sun has some use for people like that. Alas, I've exhausted my limited rhetorical powers in arguing why building bridges and building software are inherently different exercises, but I happened across an interesting article making much the same points. I offer it in lieu of further sparring :-) And for the record, I don't endorse the view quoted at the bottom of that article (and mentioned elsewhere on this thread), that software is the most complicated of engineering disciplines. Our discipline is built on a well-defined logical system (a computer); electrical engineering, applied physics, et cetera need to concern themselves with an infinitely more complicated system: nature.
  8. [java] Java for game dev?

    My first experience with JNLP/Webstart was the Bang! Howdy demo, and it really blew me away (maybe I just got lucky because I had the right JRE version installed...). But clicking on a link and getting a 3D-accelerated game pop up in its own window was just awesome. Does anything else emulate that experience outside the Java ecology?
  9. Dear Developers

    Quote:Original post by Driv3MeFar <...snip...> I don't think so. Code is a means to and end; ultimately, the goal is an application which can be used by your customers. They don't care what your code looks like, and in most cases you're not selling code, you're selling the final application built from that code. I don't mean to say that source code is the typical deliverable that gets shipped to customers. What I mean is that compiling source code is a machine-task. It is not interesting to talk about it as part of the responsibility of a software engineer, or a programmer for that matter. Literally anyone could walk up to a fully configured, complete and correct software project and hit "Compile"--it's a null task for us humans.
  10. Dear Developers

    Quote:Original post by Oluseyi Source code is an intermediate product, not an end result, so comparing source code to buildings is wrong. Correcting that analytical error, it becomes clear that the parallels between software development and other engineering disciplines are very strong. So I'm going to have to stand by my original statement: software development is a young and primitive discipline. I continue to disagree. Source code is the final product of the software engineer. There is no need to extend this discussion to the trivial final step of converting that source code into machine instructions; that is not a human job, and we are discussing humans here. Quote:Original post by Oluseyi Blueprint -> building : immense amount of labor UML diagram -> software artifact : immense amount of labor You've juxtaposed the work necessary to transmute a blueprint into a bridge to that necessary to transmute a UML diagram into a complete software project, implying that they're the same sort of thing. But are they? In the software project, what does that "immense amount of labor" consist of? If you spend 8 hours programming, what did you spend all your time doing? Were you banging out code as fast as you could type? Or were you thinking "Hmm, should I use a list or a hash for this temporary storage I need?" or "Well, I need to make this latent call at this point, should I block on it, or loop over it until it's done?" Those are all fine-grained design decisions. It's not that it doesn't make sense for a software project to have a few high-level Software Engineers in charge of the overall design (in direct analogy to civil engineering, where a few engineers are in charge of establishing the blueprint for a large project). It's that, even after the SEs have finished their design, an enormous number of low-level design decisions remain to be made by the programmers responsible for the implementation. Another way of reiterating my argument: If you wrote a software project design sufficiently precisely (to use your own term), that no more design decisions needed to be made, then the blueprint you wrote would be the software. This is why I can't stomach the argument that programmers are fungible: for them to do useful work they need a certain creativity and a certain perspicacity, which needless to say differentiates them. Frob: you said that you worked with an excellent coder, but also that coders are essentially interchangeable. Doesn't that seem like a contradiction to you?
  11. Dear Developers

    Quote:Original post by Oluseyi The only reason that this bifurcation and economies of scale don't reliably apply in software design is not because software is special, but because software development is a young and relatively primitive discipline. I disagree. There is an important distinction between software engineering and other engineering disciplines: in software engineering, the difference between the design and the product is not very profound. If you're a civil engineer, there is an enormous difference between your blueprint and the bridge you're building. You need an immense amount of labor to translate the blueprint into the bridge--and there's essentially no way to translate the bridge back into a blueprint. For a Software Engineer, your product is source code, and you can easily convert your UML diagram into the skeleton of a solution, and your solution back into a pretty good blueprint via source documentation tools. The only way to design a solution so thoroughly that any low-value programmer could accomplish it is to specify it explicitly in psuedo-code--but there is not much value in doing this, because generating real source code is nearly as easy. Meanwhile if the SE leaves his method bodies blank, then inevitably he has to trust the implementor to make a large number of small, intelligent design decisions--in this case the programmer is a designer, just as the OP said (albeit a designer with a lower-case 'd', not necessarily on the same level as the Software Engineer who is architecting the whole project). Also: Quote:Original post by frob Programmers are interchangable and replacable. Two programmers are not equal, of course, and some excellent developers may even need two or even five low-quality programmers to replace them, but the point is that they CAN be easily replaced. I've only been in the industry 3 years, but I can't imagine a case where replacing one solid developer with 2 or (even worse!) 5 mediocre ones would in any way benefit the project. I remain politely skeptical.
  12. Learning how to build projects without IDE support is an admirable goal! I would start by trying to build the project from the command-line, without any fancy build tools. This will teach you a bunch of things, including; 1) The command-line arguments your compiler needs to run 2) Probably a thing or two about a host of other compiler options you never thought of before, as you'll likely need to inspect the online help for your compiler while setting things up. 3) The LIB and INCLUDE environment variables that need to be set so that your compiler can find everything it needs (which you can find from inspecting the Project settings of the solution in your workspace). Once you've done that, you may well just decide to go back to the IDE with the happy knowledge that you more or less know what's going on under the hood. If you do become intoxicated with the power of building from a shell, there's a number of next steps you can take. For a large project with many individual source files, you might want to check out Jam.
  13. I believe MrCheese was answering the OP's second question. As for a way to do the first part, you can achieve a very similar effect with default parameters. For example: class Vector2 { float x,y; Vector2(float x = 0.0f, float y = 0.0f) { this.x = x; this.y = y; } }
  14. Alternately you can make some base class BaseLocation, that Location, Province, and ProvinceBorder all inherit from, and then pass that as the argument. Then you only need one method signature: virtual Location* nextStop (BaseLocation* goal) = 0;
  15. That game looks to be of commercial quality, which is just about the highest compliment I can think to give. Well done.