   Ubercats big fantasy game
  Hi, guys. I'm a very newbish programmer in the early stages of designing a giant fantasy war game. I could use some recommendations. I have five programming classes under my belt, spread out over years.  One C, two C++, and two Java classes. For what it's worth, I received A's in all of them. I realize that this project is far beyond the scope of my current skill, so I'm breaking it into smaller pieces and learning as I go. It would be almost easy if I were making an FPS. Step by step help in such popular projects is all over the place, it seems, but there isn't so much guidance available for more niche type games like mine.My chosen starting point is a battle program. This is a standalone application which simply carries out a battle between two opposing forces. Each army is lined up, fights round by round, and one comes out the winner. I can hardly expect to finish a game which will include many battles if I can't even fight a single one, eh? Eventually the battle simulator code will be incorporated into the overall game.I'm not looking for code from anyone, just overall advice about the best manner in which to implement certain things. I will write the code and then seek help with specific problems if I need to. This obviously isn't a homework project, and I'm serious about learning for myself.I'd better start with some description. Each army consists of various units.  Units are given default orders before the battle, which dictate the role they play in the fighting. Units will be held in separate areas, based on their assignments. Some units will be "front line" and engage enemy front line units. Others will be in "reserve", waiting to plug holes in the line or exploit enemy weakness. Some will be flankers like cavalry, and seek to reach the "rear area" of the enemy force, where they'll have a significant fighting bonus.  Note: There's no need for player input after the battle begins. It just runs its course, round by round, and returns a winner and casualty reports.There is nothing 3D or graphical occurring. The battle is abstract so units don't walk around. Essentially, all this boils down to is a battlefield of boxes. Each side has duplicates of the same boxes, which contain the units assigned to the role they represent. All boxes will have connections with certain others, which enable the units they contain to attack enemies in the connected boxes. Once they attack, units become locked in combat with their targeted enemy and remain so until one breaks or is destroyed. When a unit is removed from the fight, the enemy unit which was engaged(locked) with it returns to its own box and becomes available for another attack. Each unit is an object which has various stat variables, and possibly methods. I know what the stats are, and have a good idea of their uses, but I haven't yet worked out the specific attack algorithms and the manner in which the stats influence the results. Each unit will get to attack once per round and they attack one at a time based primarily on their initiative stat.I'm wondering a few things. How to.......implement the armies....implement the assignment boxes....lock opposing units in combat together. Sometimes a single unit may be locked with multiple enemies, but in no case will multiple units be locked with multiple units. At least one side in a particular lock will only have a single unit involved. Note: There will often be multiple locks occurring simultaneously. Each lock will be as described above.... where to implement the actual combat methods. Will they be part of each unit object, or in a separate class which uses the stats of the involved units to determine casualties and winners. The second seems more efficient than having each unit contain duplicate attack methods....will each assignment box be a separate class? Or will there be one overall class which operates on all the boxes?I'm guessing that the armies should each consist of a linked list, and possibly each assignment box should be, too. That means the battle would involve about 8-10 linked lists passing objects back and forth as the battle progresses. Does that sound practical? Am I missing a better way? Organizing and manipulating the units, while keeping track of their changing conditions (casualties, etc.) is probably the single most important aspect of the program. I will also be making a GUI so I can see the results of the battle, but I think it's more important and more complicated to work out the actual battle first. The GUI can wait a bit.I'm more comfortable with Java, and plan on one day implementing my game online, so I've chosen to write the game in Java. I figure that if Java can handle a huge online game like Runescape, it shouldn't have any trouble with what I plan. I want to thank anyone who can advise me and I hope this post isn't TMI!   
Quote:Original post by UbercatMy chosen starting point is a battle program. This is a standalone application which simply carries out a battle between two opposing forces. Each army is lined up, fights round by round, and one comes out the winner. I can hardly expect to finish a game which will include many battles if I can't even fight a single one, eh? Eventually the battle simulator code will be incorporated into the overall game.Nice thought, though to be honest I wouldn't worry too much about using the actual code in your larger project - simply carrying over the concepts and experience you get from writing it the first time will likely be sufficient. People write throwaway prototypes all the time, it's a convenient way of trying gameplay and code ideas out without getting too hung up about making the code nice. (Of course, you could always refactor the code once it's working until it's nice and then reuse it - learning how to refactor is a useful skill in and of itself).Quote:I'd better start with some description. Each army consists of various units.  Units are given default orders before the battle, which dictate the role they play in the fighting. Units will be held in separate areas, based on their assignments. Some units will be "front line" and engage enemy front line units. Others will be in "reserve", waiting to plug holes in the line or exploit enemy weakness. Some will be flankers like cavalry, and seek to reach the "rear area" of the enemy force, where they'll have a significant fighting bonus.  Note: There's no need for player input after the battle begins. It just runs its course, round by round, and returns a winner and casualty reports.There is nothing 3D or graphical occurring. The battle is abstract so units don't walk around. Essentially, all this boils down to is a battlefield of boxes. Each side has duplicates of the same boxes, which contain the units assigned to the role they represent. All boxes will have connections with certain others, which enable the units they contain to attack enemies in the connected boxes. Once they attack, units become locked in combat with their targeted enemy and remain so until one breaks or is destroyed. When a unit is removed from the fight, the enemy unit which was engaged(locked) with it returns to its own box and becomes available for another attack. OK, nifty. Have you considered prototyping this as a board game to see how the mechanics work?Quote:Each unit is an object which has various stat variables, and possibly methods. I know what the stats are, and have a good idea of their uses, but I haven't yet worked out the specific attack algorithms and the manner in which the stats influence the results. Each unit will get to attack once per round and they attack one at a time based primarily on their initiative stat.OK, cool. Does every attack last a single round, or will units be engaged in attacks across multiple rounds? Can a unit choose not to attack?Quote:I'm wondering a few things. How to.......implement the armies.Collections (lists, arrays, etc) of unit objects.Quote:...implement the assignment boxes.Also collections of unit objects. Bear in mind that one object can appear on multiple lists: the assignment boxes and army objects can both be referencing the same unit objects, so there's no need to 'pass' units between armies and assignment boxes. You will probably also want reciprocal relationships within the units themselves, so that a unit can quickly access which box or army it is in.Quote:...lock opposing units in combat together. Sometimes a single unit may be locked with multiple enemies, but in no case will multiple units be locked with multiple units. At least one side in a particular lock will only have a single unit involved.For the side with the single unit, which enemy unit is that unit targetting? Is it true that any given unit only has a single target at any one time?Quote:... where to implement the actual combat methods. Will they be part of each unit object, or in a separate class which uses the stats of the involved units to determine casualties and winners. The second seems more efficient than having each unit contain duplicate attack methods.Well, bear in mind that it would be the class that contains the method, not the individual unit. There is an elegance to having some kind of 'game rules' class that decides how to resolve battles, but it can be a bit of a problem if you start using anything more than simple stats to resolve battles. If you want to give any kind of unit a special ability, for example, then it's not pleasant as the game rules class would then have to start encoding knowledge that should really be specific to other classes.Quote:...will each assignment box be a separate class? Or will there be one overall class which operates on all the boxes?All the assignment boxes are really just instances of the same thing, so it should only need one class.Quote:I'm guessing that the armies should each consist of a linked list, and possibly each assignment box should be, too.Wahey, good call! [grin] It need not be a linked list specifically, but defintely some kind of container, yes.Quote:That means the battle would involve about 8-10 linked lists passing objects back and forth as the battle progresses. Does that sound practical? Am I missing a better way? Organizing and manipulating the units, while keeping track of their changing conditions (casualties, etc.) is probably the single most important aspect of the program.It sounds fine. Write it first, make it work, then see if it needs to be optimized.Quote:I will also be making a GUI so I can see the results of the battle, but I think it's more important and more complicated to work out the actual battle first. The GUI can wait a bit.Also a good call.   ;  Thanks for your detailed feedback! I need to work today so I'll respond afterwords if I have the mental stamina left. Otherwise, tomorrow.   ;Quote:Original post by superpigNice thought, though to be honest I wouldn't worry too much about using the actual code in your larger project - simply carrying over the concepts and experience you get from writing it the first time will likely be sufficient. People write throwaway prototypes all the time, it's a convenient way of trying gameplay and code ideas out without getting too hung up about making the code nice. (Of course, you could always refactor the code once it's working until it's nice and then reuse it - learning how to refactor is a useful skill in and of itself).I completely agree with this sentiment. Often the second/third/nth time of writing a similar system will yield better code in a shorter space of time - think of the times when you've written an essay that took 2 weeks and then lost it the day before hand in; you've already done all the thought and mental mapping of the problem/solution, the actual act of writing it becomes almost trivial - the same applies to coding.   ;  I just wrote a long reply and somehow it disappeared before I could post it. I'm too worn to do that again, right now. I'll be back tomorrow afternoon.   ;Quote:Original post by superpigOK, nifty. Have you considered prototyping this as a board game to see how the mechanics work?I drew the boxes on paper and used plastic miniatures from the War of the Ring board game to work out the battle flow. It helped a lot.Quote:OK, cool. Does every attack last a single round, or will units be engaged in attacks across multiple rounds? Can a unit choose not to attack?Units will remain targeted on the first enemy they locked with. There won't be any point where a single unit will suddenly find itself fighting two enemies. The two will engage it one at a time, so it will be attacking the first. Engagements can last more than one round and often will. Units won't always break in the first attack. I don't see any point in not attacking, although it may end up being useful. For instance, if the first enemy engaged is relatively weak and you want your unit to hold off to see if a scarier foe joins in. I'll have to think about that.Quote:Original post by superpigQuote:Original post by Ubercat....implement the assignment boxes.Also collections of unit objects. Bear in mind that one object can appear on multiple lists: the assignment boxes and army objects can both be referencing the same unit objects, so there's no need to 'pass' units between armies and assignment boxes. You will probably also want reciprocal relationships within the units themselves, so that a unit can quickly access which box or army it is in.That's good to know!Quote:Original post by superpigQuote:Original post by Ubercat...lock opposing units in combat together. Sometimes a single unit may be locked with multiple enemies, but in no case will multiple units be locked with multiple units. At least one side in a particular lock will only have a single unit involved.For the side with the single unit, which enemy unit is that unit targeting? Is it true that any given unit only has a single target at any one time?The single unit is targeting the first enemy it engaged. Yes, each unit will focus on one enemy. Special abilities will probably modify that. Fear aura, extreme heat, etc.Quote:Original post by superpigQuote:Original post by Ubercat... where to implement the actual combat methods. Will they be part of each unit object, or in a separate class which uses the stats of the involved units to determine casualties and winners. The second seems more efficient than having each unit contain duplicate attack methods.Well, bear in mind that it would be the class that contains the method, not the individual unit. There is an elegance to having some kind of 'game rules' class that decides how to resolve battles, but it can be a bit of a problem if you start using anything more than simple stats to resolve battles. If you want to give any kind of unit a special ability, for example, then it's not pleasant as the game rules class would then have to start encoding knowledge that should really be specific to other classes.That's going to take some work.I need to focus my study on containers, now, since they're so pivotal to what I want to do. Does anyone know a good, thorough book on Java containers that's also accessible to someone of limited experience? They're covered in the books I have now, but I may need more detail.;Quote:superpigQuote:Ubercat... where to implement the actual combat methods. Will they be part of each unit object, or in a separate class which uses the stats of the involved units to determine casualties and winners. The second seems more efficient than having each unit contain duplicate attack methods.Well, bear in mind that it would be the class that contains the method, not the individual unit. There is an elegance to having some kind of 'game rules' class that decides how to resolve battles, but it can be a bit of a problem if you start using anything more than simple stats to resolve battles. If you want to give any kind of unit a special ability, for example, then it's not pleasant as the game rules class would then have to start encoding knowledge that should really be specific to other classes.I've dumbed down the game mechanics significantly, just to get something basic working that I can add to later. There's no magic, no leaders, no skirmishers etc. There is one complicated item that I think I should include from the get go, as it may have a large impact on the structure of the program.Ranged units are a special case. They can be "guarded" or "unguarded." If guarded, their guards count as being in the "front line" box. They're available for enemies to attack. but don't initiate attacks on their own. While an archer is guarded, no enemy can reach it. If its owner doesn't assign a unit to guard it, or the guard is destroyed, the ranged unit counts as being on the front line. It can still shoot, until an enemy engages it.The guard, of course, has to be linked to the unit it's protecting in some way, which probably means that every potential guard would need an additional field. I think it's best to say that only one guard can be assigned to any given archer.The best way to implement this, perhaps, would be to have the archer in the "ranged" box, while its guard is in the front line box. When randomly picking targets, enemy units would also have the chance at attacking unguarded units from the ranged box. It sounds messy to me. Do you have any ideas how it could be well implemented? If you reply, could you include some key descriptive words/phrases that would clue me into which programming areas or concepts I should focus my study on? That way I can continue to do the work and learning for myself. Thanks!I just got the latest JDK and NetBeans installed on my new PC. I'm going to spend some time going through NetBeans and Suns online Java tutorials. I want to get up to speed as much as possible with NetBeans to make everything go as smoothly as possible. I had some annoying problems in class, mostly dealing withe misunderstood paths.   