• Content count

  • Joined

  • Last visited

Community Reputation

380 Neutral

About 00Kevin

  • Rank

Personal Information


  • Twitter
  1. 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)
  2. 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.
  3. 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! 
  4. 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!'.    
  5. 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.  
  6. 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. 
  7. 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.  
  8. 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.  
  9. 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
  10. 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.      
  11. 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.  
  12. Your development workflow

      Those are some very critical and important steps that are often overlooked. 
  13. If you had to create a workflow to manage your development process what steps/stages would you implement?  Would you keep it small or make it as detailed as possible?   It seems to me that I need a process that starts with a user wish list and ends with a build in production.         Here are buckets I'm planing on using per feature    1. Register  2. Initial Requirements 3. Review ( Approve / Reject) 4. Detailed Requirements. 5. Approved for Development (enters the development backlog)  6. Development 7. Unit Testing 8. User / Play Testing (reject / approve) 9. Build & Release                  
  14. As anyone seen an example of rolling dice that uses 3d canvas and real physics?.      I'm looking to create a die rolling app that uses polyhedral dice.      I guess I could find a 3d physics example that uses simple objects, but I'm sure it has been done before.     I think the trick is how to determine which face value is up.   
  15. AI Bots- Why are they hardly used anymore?

    I loved battlefront 1&2 even though it had stupid AI bots.   Killing them in multi-player was part of the fun in that game.     The more stuff to blowup and destroy the better.