• Content count

  • Joined

  • Last visited

Community Reputation

380 Neutral

About 00Kevin

  • Rank

Personal Information


  • Twitter
  1. 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.
  2. 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.
  3. 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?
  4. 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 )
  5. 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)
  6. 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.
  7. 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! 
  8. 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!'.    
  9. 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.  
  10. 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. 
  11. 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.  
  12. thanks for the advice.   I've actually just moved over to the Intel XDK which uses Cordova.   The app preview functionality is really great.    I can test on any device simply by installing the app.  
  13. 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
  14. Hi,   Can anyone here recommend a place where I can find a 2d game artist to help complete a mobile game I've developed?   I'm not necessarily looking to hire someone, but I am looking to find someone to team up with.   At this point, the game is completely functional and just needs a graphic artist to replace all my horrible programmer art.  :)     Thanks.      
  15. Your development workflow

    Having a vision for your game and a small amount of planning is definitely beneficial. You don't want to dive into a game project that is too large in scope and you want to have a rough idea of what you final game will be like but this waterfall approach has a major flaw. You cannot anticipate everything you game needs or even if it will be fun in the planning stages. If you lay out a detailed map of what your final game will be like you will find major problems with the gameplay partway through development. At this point you can scrap all the work you did in planning or just stick to the script and have your gameplay suffer because of it. Alberth describes pretty well what I try to do. Build the game in small incremental steps. Try out the gameplay early with simple prototypes. Be willing to kill an idea that will either take more resources than it is worth or just isn't fun. Identify problems with gameplay and come up with solutions as you find them. Eventually you begin to converge on your final game, which may be quite different from your original idea.     I think that if the above waterfall method is used per feature it won't have such a flaw.   I agree you can't anticipate everything.