Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Everything posted by 00Kevin

  1. Did you have any game in particular in mind that did a good job at that? I'd really like to review it. There is no redoing, but I could add it. My only concern with allowing that players might abuse it to reveal hidden creatures, traps, hazards, and unexplored areas of the map. My original design included an action queue of sorts. In this case the action queue could be executed at any time, and if actions are queued in a particular order, combos and special bonuses would fire. For example, if you decided to jump and attack the two creatures beside you the "Sweeping Leap" combo would be activated. In this way, the player would focus on building combos for extra effects and damage. Players could discover these as they play. Of course, there will be mechanical reasons to make individual weapon attacks that are not queued, for example it might be easier to hit with a non-queued action. The problem is that I'm not sure players would appreciate this. Many might simply want a single button to activate the special maneuver and not build them during their turn. I do know that I plan on creating a magic system that works on a queue. In this case, you can add in special regents other trinkets to your spells as they are being cast. For example, if you want to add a fire effect , the player can add in sulfur or coal to the spell casting queue.
  2. Can anyone knowledgeable in turn-based combat games share their insight into how targeted actions are best implemented? Specifically what is the best sequence of events for the selection of actions and targeting. a. Select target -> pick an action -> action executes (no confirmation box) b. Select target -> pick an action -> action executes upon confirmation from user (via dialog, double click, or right click) c. Select action -> cursor changes to attack icon-> click on target- > action executes d. Select action -> cursor changes to targeting icon-> click on target -> action executes upon confirmation from user (via dialog, double click, or right click) Selecting a target first has advantages in that you can filter out invalid action icons based on the target selected. The user doesn't need to hover his mouse over the enemy to determine if it's attack-able. The player only needs to cycle through each target in range (via next target or prev target buttons) once, and since there are generally less targets than actions (attack types, targeted spells, talents, etc) it's far more efficient a process. Selecting an action first is more akin to how games many strategy games like Panzer General work. Once the action is selected the player can move the mouse over a target to evaluate the details of the action. Any thoughts? Are confirmations really all that important?
  3. So what I've decided is to embed the confirmation into the very nature of the menu system itself. What I mean by this, is that you can hover over a unit to display all available options, click on the unit to activate the selection of those options and inspect them in more detail, and then finally select the option. In other words, all actions always have two clicks.
  4. If you had to make a game that didn't use icons for inventory (like WoW , Diablo, etc) what solutions would you propose? My current game has an inventory system that is icon and paper-doll based, very similar to WoW, but I'm considering innovative alternatives. For one, I like the idea of allowing the player to manipulate actual 3d objects. My thought is that the player could drag and drop the object onto the character directly. The game might spin the character/camera around, zoom into an equipment location, and/ or highlight valid equipment locations for the selected object Of course, this means that characters would have actual backpack objects on them that would open up to reveal their contents (3d objects). It certainly nods to realism, but that might be fine if it's done correctly. Any thoughts?
  5. oh right, I totally forgot about that weapon wheel. The RPG game I'm creating allows the player to create robot / cyborg characters only. I made this choice because I didn't want to create a ton of clothing options. With robots, equipment slots are reduced to hand held items and a few augmentation items. It's also a multi-character party based game, allowing the player to create up to 6 characters. So the total number of items a player must deal with is distributed across many characters, allowing for more realism. With that said, I do like the idea of looting corpses and chests. I just have to think about how that would work with such a system.
  6. Yes, I'm actually considering the U7 approach. It would certainly reduce the level of coding required. I also really like a feature of Utlima Underworld's inventory, which allowed you to have containers inside containers. Inventory Tetris is something I'd like to avoid, but I can't deny the fact that some players love organizing their inventory.
  7. I'm looking for solutions to a Line of Effect system I'm creating. Specifically, I'm looking for a real-time algorithm that helps an AI unit find the closest tile in range that has a line of effect to its target At the moment, I'm using raycasting (in Unity) to determine what tiles have lines of effect (no obstructions) to each other. This information is then used by the AI to locate an unobstructed targeting position within range. The end result is that every tile has a list of other tile locations it has a clear line of effect to. The problem is that it takes forever to scan and makes the map far too static for my needs. Anyone implement something similar? Thanks
  8. As for my previous solution, it fails when the correct action is to maintain maximum range. Maybe players won't like that, but I'll leave that to them to decide.
  9. That is very true, but ranking actions against the creatures intelligence score is something I've already written. My hope is that play testing will end up curtailing my stupid . Of course, I'm not trying to make the AI overwhelming, I just don't want it to perform stupid actions. For example, if the player is at the back of a building with a single window, It makes far more sense if the AI doesn't walk down the stairs, open the front door, and run around the building to attack. I'd rather see the AI simply move towards the window and start shooting.
  10. So the solution I've settled on for now is to let my path-finding system do all the work. You simply find a path to the target. Then you scan that path for points within range and loop until you find the one with a line of effect via a ray cast. The problem is that this solution ignores things like windows which might be closer. One solution to this is to create a second grid with a much smaller granularity (0.25 size squares) and use it for the initial path-finding. This would allow the path-finding system to pass through windows and small openings.
  11. That's interesting I'll have to give this some thought. To be honest, I'm still trying to visualize this solution. As an alternative to ray casting I wrote a Bresenham 3D line drawing algorithm that returns a list of tiles. In fact, my tilemap already has obstructions and occupied squares identified.
  12. I'm not sure that helps all that much considering the positions of units often change. Known positions are rarely useful. In addition the environment can often change as well. With that said, an initial raycast towards each opponent is useful. I'm considering compressing the bit array because quite frankly it's the ultimate solution most of the time. I'll need a compression method that still allows for the data to be read without un-compressing the entire file.
  13. One other complication is that the correct way to test for line of effect and cover is to use the corners of each square and not the center point. This makes this problem even more cpu intensive when raycasting.
  14. Thanks for your help. I will definitely give these constraints a try. One complication I didn't mention is that in my case the tile grid is 3d. Which means if I have a small level that is (50x25x50) for example, I'm looking at 3,906,250,000 combinations (50x25x50x50x25x50) for a static scan. Yikes! that's a 3 GB file per level, assuming I store byte (bool) values and not bits to the file. The bi-directional property will reduce this, but at the moment I'm not sure about the proper algorithm to implement it. Iterating over a 6 dimensional array is easy, but it will certainly take forever and it's not optimal. I know there is a way to iterate over all the possible combinations taking bi-directional factor into consideration, but I haven't worked out the structure for such a loop yet. Ray casting will definitely need to be avoided if the the line was previously scanned from the opposite direction. Regardless, it is still a monster to manage in either case. I might have to re-evaluate the need for such a system and consider less optimal solutions for the AI. The initial system I wrote picked up all the tiles at a radius out from the target and performed pathfinding on each tile. The problem is that the longer the range the slower the system (more tiles need to be scanned) .And if you limit the tiles to those between the attacker and the target, some wall shapes (like U shaped walls) cause this technique to fail. Thanks
  15. I guess it depends on how complex the combat system is. If it allows for burst attacks or multi-target attacks it's much more difficult. Highlighting all possible targets isn't easy, especially when many of them are off screen. In addition, a single action might work very differently against each target. Multi-target attacks like picking 1 to 3 enemies within an AoE is more difficult. Of course, it all depends on how much control you want your player to have. There is also the problem of hitting invisible units . For example, if you suspect there is an invisible / hidden creature in a particular square you might need to use an area attack or select the square to attack and not the creature. I personally don't like confirmation dialogs, but for some reason XCOM uses them extensively. I guess play testing revealed that it was necessary.
  16. I agree, confirmations can really get in the way. XCOM uses the right mouse button for some confirmations and it has' become the expected format for many modern TB games. I'm trying to design my game without confirmations or at the very least have it as an optional feature. IMO, three clicks is way too much. Anything that slows down game play in the TB game is to be avoided. Selecting the target, the action, and then a confirmation button is just too many clicks. At the moment, I'm looking at Field of Glory 2 for some ideas. I really like how all the action icons are displayed in context near the cursor. When the mouse is button is clicked the action icons pivot vertically and enlarge. At that point, you can hover over all the possible actions and evaluate the action in context with the selected target via the tool tips. Clicking on the icon again is like a confirmation. This is a good solution since it reduces the number clicks down to 2.
  17. 00Kevin

    Rats and Holy Hand Grenades

    Over the past few weeks I worked on a new Animation Controller and refractored the Unit Action system. It was a ton of work, but the code was getting out of hand and in order to move forward I realized I needed to reorganize the class hierarchy. Every time I do this it seems like I'm having to take a step back to take two steps forward. I'm starting to think that this is just the nature of game development. There are times when you feel like nothing is getting done because you have nothing to show except nice code. In addition to adding rats (which no RPG should be without), I managed to implement object/grenade throwing, It ended up being a lot more challenging than I had anticipated. In this case, the requirement to extrapolate backwards from a target location and create a projectile arc demanded an entire class full of projectile math. Of course, it wasn't the math that was the challenge, it was linking animation events, inventory, actions, collisions, UI, etc.. Hence the need for the refractoring mentioned above. (not sure why the rats are floating, they are 50 KG each) I've also decided that the turn based game will make use of physics and ragdolls. I'll just have to find a way to seamlessly re position/centre units to the nearest square once rigid-body movement is complete. As for other features completed, you can now swap out equipment during combat. Available unit actions are updated on the fly. I might make changing weapons during combat cost action points. Opening your backpack will cost even more action points, this will encourage the player to be prepared. Of course, armor won't be equip-able during combat and quick items (things located on your belt or across your back) will be less costly. (note the character sheet is a mess, and I'm still pondering its layout and functionality. Unit stats are still under development )
  18. 00Kevin

    Flying High Again

    Looks like I've been neglecting this blog a bit too much lately so here is an update. I've been working on the Combat system a little more. Flying After cleaning up the unit action system, I've finally had time to work on the flying feature. I really need to find the right type of camera for this game or it might be a bit too confusing for the player. In addition, it's clear to me that I need to add height/position indicators so that the player knows what tile the movement selector, targeted unit, and selected unit are over. Perhaps a translucent pillar of some sort will suffice. Guarding The game will now allow you to spend action points to guard with one or more weapons attacks. The number of readied attacks is only limited by your action point total. When an enemy enters your weapon reach, you attack first (gold box game style) It's setup right now so that all your guarding attacks fire off at the triggering enemy. I might change that by giving the player an option or only allow one attack per enemy. Adding over-watch ability (guarding with ranged weapons) is next on my hit list. Hopefully both systems will play nicely together. Coding this was really complicated too, especially when several units are guarding the same square. Without the internal Event Messaging System I created the task would be near impossible. (Don't mind the Animations or the UI as I haven't focused on it. The artifacts in this Gif are from GifCam, which I'm not using anymore)
  19. 00Kevin

    Project XSYS - WIP

    THE GAME: Project XSYS is an untitled indie game that features world map HEX crawling, turn based combat, and multi-character party RPG adventuring. Features thus far: Hex Crawling World map hex crawling is a unique feature. It's up to the player to ensure his/her party is well prepared and provisioned for each journey. Like many 4X games,time controls allow the player to speed up, slow down, and pause the passage of time. As time passes, various events will occur such as combat encounters, interaction scenarios, inter-party personality conflicts, discoveries, etc. The screenshot below is the most current view of the hex map. It is auto-generated by stitching smaller hand crafted Terrains together. But, yes, it's pure programmer art. Tactical Turn Based Combat The combat system was built to satisfy the itch of tactical turn based enthusiasts. In addition, I've worked hard to ensure that the combat grid is truly 3D. This means that characters can climb, fly, crawl, and jump over and under obstacles. The action point based combat system is designed around the concept that your character can try to do anything. For example, if you want to fight with two weapons, trip, guard, parry, or disarm you don't need a special skill to try it. There are no talent trees just proficiency levels. Character Party The character creation system is extensive and is a multi-step process. Steps include selecting Class, Race, Ability Scores, Interaction Skills, Combat Skills, Exploration Skills, Spells, Appearance, Personality, Backgrounds, etc. At the moment, the system allows you to create up to six characters. At the moment, the graphics are nothing more than prototypes / placeholders. I don't plan on hiring or partnering with an artist until next year. One of the first things I will have commissioned is a base character model and various pieces of equipment for each race. For the moment, Adam and a pair of Mixamo thugs will do just nicely. Development Thus far, I've spent many long nights coding and refractoring the games numerous subsystems (true 3d grid pathfinding, sqlite database, event message system, animations, personality system, combat mechanics, inventory, character sheets, items, vendors, character creation, terrain based hex map, encounter system, survival mechanics, campaign events, etc). The game has truly become a labor of love and I'm quite happy with the code thus far, but of course it's not perfect... yet. My current focus is developing the content pipeline and assessing what Unity assets (if any) I will be integrating. In fact, I can't wait to start adding more creative elements to my game. The game is now moving from being a game framework to an actual game, but there are still many detailed decisions that have not been made. Anyway, I hope you enjoy watching my game take shape. I really need all the feedback I can get as I have much to learn.
  20. btw,  you gotta love coders who, before they even begin to make modifications, waste half the day or more changing the coding style.       One guy I worked with changed all the database commands to upper case.   I was like really?   As for camelCase or PascalStyle,  my pinky has been brutalized on this shift key because you! 
  21. This is a subjective opinion presented as an objective fact. ...and it's not even a popular opinion.   Lowercase with underscores is actually the most 'official' style that C++ has, as it's used by the standard library (and many other projects). The people who choose it would say the opposite opinion: that CamelCase is bad style and makes code less readable..   I work with one programmer who hates underscores.   So we all try to add a few extra once and a while just to hear him scream "I hate f**king underscores!'.    
  22. The problem is that this kind of convention is brittle. It encodes information about scope into the variable name, but if you refactor to change scope the encoding is wrong and the variable must be renamed.  Forget or neglect to rename the variable and now you've got misleading information.   A far more robust convention is to require the use of this-> for members and to require full namespace naming for globals.  The compiler can then help you by catching incorrect usage.  In an ideal world C++ would have had these requirements from the outset.   this, a thousand times this (pun absolutely intended). I sometimes wish c++ had gone the same route as python or rust with an explicit self/this parameter. which could also enable things like templates based on the reference qualifiers of the object.     shortly after the wheel we invented find/replace and yet things still get missed.  
  23. Actually there is. Be consistent, at least in your own codebase. If I know something is called a foo bar I should be able to deduce its name without having to check on which day it was written. FooBar, CFooBar, TFooBar, foo_bar, ... are all somehow acceptable provided they follow a clear pattern. I still wished C or T prefixes would remain in the dustbin of history though.     That doesn't happen.    The point I'm making is that readability (for the next guy) is far more important than a bunch of strict coding styles that are largely subjective and change over time.    I'm talking from years of experience developing large enterprise level systems that evolve.  Code bases developed by multiple developers often contain mixed styles. That's the reality regardless of how idealistic you are.    As programmers we deal with what IS and not with what should be.  The fact is most successful business systems contain mixed conventions and poorly written code anyway .  So unless you are the sole developer for the entire life of an application, there's no sense in being strict in regards to programming style.  For success, focus on the architecture of your product, which is the true measure of success,  and don't be guilty of using meaningless notations.    Now, I'm not trying to write a book here or publish a thesis to become famous, I'm just telling you the way it really is.   With that said, I'm frequently reminded of all those jokers in my class that couldn't code very well.   I found out the hard way that they are busy writing endless lines of bad code for us all.  :)  So in the grand scheme of things, stylistic conventions are the least of our concerns as programmers. 
  24. This reminds me that many years ago it was also common to use the prefix letter 'T' for the class definition...    I wonder what happened to that.     And the prefix 'C'?  don't remind me the horror that is MFC.       With that said, after working on a several large business system across many different languages I hate prefix / Hungarian notation with a passion.      I find that coding conventions (especially prefixes) are rarely enforced, change over time, and are usually only grudgingly accepted (if at all) by subsequent developers who inherit your work.   In the end, everyone tries to adopt their own conventions and the code base becomes a complete mess.       IMO, just make your code readable.  There are no strict standards for success.   In fact, sometimes the variable name 'i' is more readable than a long description and sometimes it isn't.  If you write your code for other people to read then you'll be successful.   If you code for yourself and include your own bullshit or the latest fad conventions you won't.  
  25. Hi,   I've created a game using HTML5 / javascript, box2dweb and createjs.    My plan is to publish the game to the playstore and the appstore by using PhoneGap/Cordova.       If you have any experience publishing and supporting a game using any of the above technologies could you could share your experiences?   Is there anything I should lookout for?      Thanks
  • 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!