Advertisement Jump to content
  • Advertisement

lucem

Member
  • Content Count

    57
  • Joined

  • Last visited

Community Reputation

176 Neutral

About lucem

  • Rank
    Member
  1. lucem

    GameEngine Design

    First notice: Why should a GameState know that something like a GameStateManager even exists? The Manager should query the State if it is finished. Second notice: Static stuff is usually meant as Singletons. Singletons really are bad, so one should avoid them at all cost. (Explanations etc. are to be found in this subforum en masse, so I won't go into detail here) You say you have two games at hand that will use the engine... I would strongly advise you to design the games first, then go the step back and determine what common basic functionality both of them need, and implement that. Then write your games; after that, you can dive into it a bit more and will see more clearly what will belong to your engine, and what not. Don't start with an "engine" that has no clear specs on what it should do and what it's responsibilities are.
  2. lucem

    Suspending a goal

    <unintentional double post>
  3. lucem

    Suspending a goal

    Have a stack where you push on all goal in reverse order; when you interrupt a goal, push it back on the stack, and push the new (interrupting) goal afterwards. Your agent should work something like this to work: Update() if curGoal.IsFinished() curGoal = goalStack.Pop() ... (process environment update) ... (execute code for goal) You will have to have an "idle" goal on the bottom of the stack though. If the environment update generates a new goal, the current goal is pushed, then the new goal and the current Goal is made invalid. The next frame, the new goal will be popped and executed, and once it's finished, the postponed one will be popped and resumed.
  4. Well, basically what is done in DI has been done as a "best practice" since the starting days of OOP. It just got a new, fancy name tag :) DI is simply the old rule to program against interfaces, not implementations. All that DI does is adding the injection part of it - so moving the creation of concrete objects outside of your business objects. This way, the objects are assembled outside of your business classes and are injected at program start, or call preparation. Of course, this enables you to do fancy things like Mock Objects in TDD, but it's nothing new. Just like component based designs are nothing new - at least since "Design Patterns" everyone should know the old rule of preferring composition over inheritance. But it took more than ten years since that book and the general adoption of that behaviour - component based designs became fancy around the mid if this decade in the wide public. My advice would be to do proper designing by sticking to the plain old rules that have been around for years and not run after trendy buzzwords - 'cause you're already doing what they propagate then, they just give it a new name. Btw: Data encapsulation is crucial. There is nothing good in breaking encapsulation and making class data public, as was proposed somewhere up the list. Encapsulation is not "small scale design". Abstration isn't "small scale design" either. The trick is to define interactions between objects through interfaces (unless there is close coupling by necessity). If data is made available by an interface, it's fine. If it's done by a class, it's not. Program to interfaces, not implementations. Mr Neverdone is really wrong at that point (with everything else, I ack totally) - or I just read him very wrong ;) Anyway, all I can encourage people to do is get their reading of the good old standards done. And that particular books is very well one of them :)
  5. I don't believe there is an even closely perfect answer to all the questions and problems depicted in this thread, First problem is, "self taught" programmers seldomly ever scratched the surface of formal methods and software engineering. It's like trying to fly a plane without knowing where the manual is, or even wanting to read it before takeoff. Second one is, changing requirements. That's what design documents should be for - formal specification of everthing that shall be in a piece of software, what i shall do and what not. In customer driven designs, the design documents are the contract; it needs to be treated like that. Thus, if a customer comes and demands requirements changes, you throw the design docs on the table, open up the page related to that topic and say "Well, in our contract it reads this. This is how it will be done, unless you want to pay for the extra work needed to change everything". And that's the way game designers shall be treated, too - sticking to the plan and only changing it when it's needed, not when someone comes up with something new and totally cool - it's called "feature creep", and that's the beginning of the end. Third problem is leadership. If you have people working on your project that refuse to adopt a corporate working process, that refuse to document what they're doing and deny planning ahead (which is the essence of the engineering part in SE), then their project leader, manager or whoever is in charge should go and kick their nuts. They're getting paid for doing what they're told to do, basta. And implementing formal methods and good working processes to make a project controllable and plannable (to a software project's extend of plannability at least) is good leadership; allowing people to work wildly and uncontrolled is "lessez faire", which is considered bad leadership. Foruth problem is, time constraints and problems that pop up down the road, so even a good design shows it's flaws. Hitting reality can destroy any good plan, nevertheless without a plan, it's pointless. So, proper design means planning ahead and detailing on the go, always refining and questioning decisions made earlier - but in a way that improves already done work, not to destroy it. If you stick to a general plan, an outlined blueprint of some sorts, it doesn't need to adress every screw in the ship - nevertheless, even if you move a screw, in the end what will come out is still a ship. People in software tend to forget that planning is their friend, thinking about problems ahead will prevent them becoming problems later. Projects that follow a dynamic plan will work in the end - and if you've stuck to the plan until crunch time, you will notice that problems tendentially won't be as heavy in the last minutes, as you've already adressed most of them ahead of time, just by thinking about your design five minuts longer when you started. Unit tests for example might seem tedious, but in the end of the day you will be glad if you have them. If a test fails, it tells you exactly where something broke, so you don't have to search for it. You will know why it broke, because it must be something you did on that day, and that's easier to track than patches from three months or longer. This way, unit tests, if used properly, will save you debugging time. Plus, by writing the test before the code to test, you will always have a reference inside you code that will tell you what that thing is supposed to do. In the first fie minutes it's more work, in the end of the day it saves you lots of time. But it takes good leadership to enforce use of such techniques. So, to sum it up, no perfect solution in sight, and there won't be any until everyone on the project is going to play by the rules.
  6. lucem

    Strategy game formations

    Complexity of this depends on how you implement it. Re-computations don't have to be done every frame, and mimicking real command structures can be very efficient - in this case, AI decisions fall down the tree automatically, and get concretized on the go. Inside the various stages, existing technology like state machines etc. can be used, and as orders usually stay valid for longer periods than a couple of frames, it can be both elegant and efficient.
  7. lucem

    3D Space Game AI Ideas?

    I'm not really sure if neural nets are applicable in pointing out directions for movement in combat - for the most part, movement decisioning is based on knowledge, not training. So, neural nets can deliver decision parts based on training, but you'll have to consider knowledge (which can change rapidly, this is why neural nets alone won't cut it) as well. Randomizing neural nets is dangerous here, too - it can, under bad circumstances, result in absolutely random and unpredictable steering behaivour, odd things like "Oh, I must attack, let's move away from the enemy, as my brain tells me to do so". That's something to avoid!
  8. lucem

    Strategy game formations

    Attack formations and movement formations can be done by implementing a simulated command chain, meaning organizing your military "units" in military units. (See the quotes?) Military units get orders to operate in certain space restrictions and in a certain way (offensive, defensive, hit-and-run etc.). By graining your military down to heterogenous units formed by homogenous "individuals", and imposing a chain of responsibility, you can apply rules of engagement which in the end will result in your military units organizing themselves autonomously inside the formation - by obeying their space restrictions, and rules of engagement. (Space restrictions can be absolute, like "position x,y,z", and relative like "left to unit 2./34 in a distance of d", always applying to space volumes, not points only; this way, the units will always try to stay at their ordered position, and you only need to do the pathfinding and movement calculations for one unit, which will be either one random "flag ship" or the abstract higher-order unit, like a wing, squadron, flotille, fleet or whatever)
  9. For me this question fortunately didn't arise, as in my studies of "applied computer science" both 'worlds' merge pretty well. It all started off as computer science, mixed with some basic programming courses (C,C++,Java) and some courses covering specific APIs (Qt4, OpenGL). Later, I had two semesters of courses in software engineering, resulting in a compulsory 1.5-semester long project, which I'm currently doing right now. The diploma thesis (German degree "Diplom-Informatiker", somewhere between a Bachelor and a Master) will be a software project again, so in the end I'll have at least those two demos for my portfolio, not counting my own programming work outside of school. I also did some electives like "Mathematical methods in computer graphics", plus a second, more in-detail course in OpenGL (didn't need it, but what you've got on paper...), and last, but not least some basic courses in Operating Systems and web technology. I don't count the usual stuff, like basic electrical engineering, physics and math, everyone has to do those. I'm not too far away from graduation, and looking back I'm quite happy with the curriculum and the choices I made. What's really important for me in that is, I'm not solely in the gamedev thing, though I do consider working in the gamedev field later, but if it doesn't happen, I have a lot of alternatives where I can head to. I really believe, and that's quite important, that one should not specialize too deep and too early, especially not into game development. Having alternatives and other fields of interest as a backup-plan is crucial, IMO. What's your take on that?
  10. I use them quite extensively in a lot of places. Patterns provide proven solutions to common problems, but they do have a downside - sometimes things can be done more elegantly in another fashion, and in some rare cases one can read from the code that at a place patterns have been used just to use patterns, not to solve a problem. The GoF (Design Patterns - Elements of re-usable, object-oriented software; Gamma et al.) is a must-read though for aspiring developers, IMO. Dealing with the subject not only broadens your problem-analyzing and -solution skills, but it makes you think about object oriented design and really changes the way you think about designing software. The result is usually a much sleaker and cleaner design. The only mistake that you shouldn't make is designing your problems around patterns - a lot of peoply do so when they get in contact with the material for the first time ;)
  11. lucem

    Where to start

    Well, certainly not posting the question in "Game Programming". Besides, a good start point is knowing what you want to achieve (what's the game about, how should it feel to play the game, how shall it work in a general sense).
  12. That's exactly what it is - private. Note the difference in standard behaviour to Java! Just wanted to stress that ;)
  13. Quote:Having version control integrated with the IDE isn't that important... If your VC system already integrates with windows explorer (e.g. TortoiseSVN) then there is really no need. I'd rather disagree with that, but for sure, if you can do version control in the explorer, it's better than nothing. TortoiseSVN/TortoiseCVS et al. are great tools, no argue on that ;) The thing is, having version control integrated into the IDE saves you a lot of time, it's less error-prone (you don't forget checkout/checkin when it's automated) and your workflow isn't interrupted by manually triggering version control operations. This way, it's reduced to a transparent no-brainer, which is exactly what it's supposed to be - easy to use, "just there" and not requiring manual attention. (At least once it's set up to work) Another note on that, since I started using Team Foundation in VS, I'd never want to come back to the (mostly) lousy freeware plug-ins like ankhSVN and whatever there else is - I never got it to work in the first place with these. Gladly, TortoiseSVN worked better than that. A good example of SVN and CVS integration itno the IDE is Eclipse - once you've set it up (which is easy), it handles all the operations on it's own, so you don't have to manually trigger checkins and checkouts. I mentioned that as an example everyone, even people not having access to the commercial editions of VS (which support TFS), can look at and see how it can work. The bad thing about Eclipse is, that it sure as hell eats up your memory and CPU power faster than any Windows flavour ever could. Code::Blocks is actually one of the IDEs I never touched, but what I can read from the info I got, it seems to be a nice alternative, especially as a multi-platform IDE. Other options one might consider (on the freeware/OSS market) are Eclipse/CDT, NetBeans 5+ and KDevelop (so far Linux only, but with the latest release getting more closer to actually being useful). Working with emacs and vim is PITA IMHO, since they have a steep learning curve and you really have to invest a lot of time before they actually get useful and save you time. I was forced to work with those during some university courses, though, and it worked after some time, but I never really liked it that way. I have the uttermost respect for people who voluntarily use these editors! I personally use VS2k5 Standard a lot on Windows (obviously), and KDevelop and Eclipse on Linux (and OS X). On OS X, I never got the time to try XCode, which is rather awkward when you're coming from VS ;) But I'm sure it's got it's advantages. At the moment, I have VS2k8 Professional installed parallel to VS2k5 Standard, but haven't found the time yet to evaluate it properly - additionally, the German version isn't out yet, so I'll be waiting for that before I seriously start using that. Oh, and I'm running all of those on XP SP2, I got Vista in parallel, but only for testing, I pretty much dislike it all the way. ( Yes, I got all these licences from my university, so these are all legal; thanks for asking )
  14. - Version control (not only with TFS) possible - Solutions using more than one programming language - Expansibility (plugins etc.) ... need more? Version control alone makes life a hell of a lot easier.
  15. lucem

    Class diagram feedback

    Sorry to say so, but you design has some flaws. You're modelling collisions as associations between classes. You rely on inheritance. And you mix several concepts that should be separated. So, what to do with that? First of all, from your model it reads that the Player class is associated with the Terain class, which in this case means that the Players interact with the Terrain directly. Please work on that, this will run you into trouble. First of all, usually the terrain is split up into several objects, with these objects attached to the scene graph. Having a monolithic "Terrain" object in this case would only make sense as an adapto-like thing for accessing the terrain as a whole, but not for in-game interaction. Secondly, as I read it, all these thing in your model are classes. That's fine, ut some of the functionality should be defined by interfaces, such as the collision reaction. The objects themselves should define their behaviour on collisions. Collision detection is doen by the scene graph, using the spatial information each node contains. Third, there is no need for "Player1" and "CPU" classes, the Player class is sufficient to do the job. It should have a component that controls it, and that component should make he difference between human and CPU. Otherwise, you'd be directly handling input inside a game class, which is a bad idea, obviously.
  • Advertisement
×

Important Information

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

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!