• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

1321 Excellent

About markypooch

  • Rank

Personal Information

  • Interests

Recent Profile Visitors

8439 profile views
  1. I'm not sure how Total War does it (Also a huge fan of the series) but if everytime I attacked a province, and l do a quick save (Cause I got whooped by an AI), and reload, and decide to tool with the composition of my army (before the next attempt at assault), only to find that the AIs army changed without them using a scout (Remember Total War uses these types of units, Shogun = Ninjas, Warhammer = Heros, Rome = Centuari, ect. even the AI uses them making me believe TW takes a more organic route), or anything else, Id find that a bit mood-killing. You can still make it work, but you'd have to be crafty for your average RTS player not to catch on. Also, terrain makes a HUGE difference. In Total War if I route my units through certain terrain I suffer attrition, and movement penalties (Enemy Territory, moving during the winter, ect.), and on the battle map soldiers can suffer fatigue when being asked to run everywhere they go, or being asked to run to the top of a hill. In fact, side topic, one of my favorite tactics in Shogun 2 was placing my yari/yari samurai men at the top of a hill, and having the opposing AI charge their troops towards me (Shogun 2s AI was easy to antagonize into bad decisions ). By the time they ran into my wall of pikes their morale was gone, and they were exhausted. I could stretch 1 troop to 4 troops of the AIs (in most scenarios) Now, for a risk style game I still feel like you can factor this in. Tanks (and most vehicles to be fair) work best when you have flat, level, non-treacherous, dry terrain. Mountain ranges, regions that are experiencing rains (muddy), ect. should incur a penalty of movement (Have you seen a truck in the mud?), and a penalty during battle. These can be as simple as arbitrary deductions of base-line stats depending on the environment.
  2. One organic way to approach this is to leverage terrain, and it's limiting factors. Suppose you have a country that's surrounded by treacherous mountain ranges on several flanks, you could impose penalties on world map movement (Based on the composition of the army), or in battles to certain units (tanks, vehicles, ect.) a stalled tank is a sitting duck Also, while tanks are powerful, they should have at the very least one set back; they aren't cheap. Further still, they shouldn't be so easy/time conducive to construct that a player can throw 12,000 tanks at any problem This way the AI chooses it's units to best fit it's home terrain, or the terrains of the adjacent nations it seeks to conquer. Also, you should leveraging scouting as well. AIs shouldn't be able to cheat, and know the composition of an army, and vice-versa for the player. But, with a successful, but dangerous (for your expensive scout) mission, why not? Panzer/Tank hunters should be relatively cheap to make as well, considering that the weakest part of any tanks is it's tracks, and a well placed sock covered in axle grease, and filled with c4 can blow the tracks off a tank (So essentially just infantry soldiers running around with sock bombs)
  3. You should check out specular maps. Builds off of the logic of normal maps, except you are determining the specular intensity of each pixel leveraging your bumpmap normal, and an additional texture for your specular map. It's been a bit since I've last implemented it, but, depending on your environment, Rastertek did an article on it for D3D http://www.rastertek.com/dx11tut21.html
  4. How to start learning machine learning

    Machine Learning is a large field, and often gets mixed in with Deep Learning (Which is a subset of the field). Machine Learning really is open to anyone who can code, and has a basic understanding of linear algebra (though a more fundamental understanding doesn't hurt). It all comes down to the problem you are trying to solve, the model that best represents that problem, and the entailing solution, and how much visibility you want into the process of that algorithm. There are two general classes of Machine Learning that algorithms typically fall into. Supervised Learning, and Unsupervised learning. Supervised learning requires that you present the algorithm with labeled training examples for the feature extraction, and processing. Unsupervised learning involves no training data, but an unmarked data set, and letting the algorithm attempt to cluster similarities in the dataset together. Two common algorithms that are used heavily in Machine Learning (Under the context of supervised learning) is Naive Bayes, and ID3/C4.5. The former being quite good at giving classification results with minimum training data, and excels at generalization, and doesn't suffer as much to over-fitting (Too much correlation with your training data entailing losing the ability to generalize effectively about new data). One draw back is the naive part due to variables in a feature set having independence from one another. This normally would pop up in a dataset where features are highly correlated by nature, though, Naive Bayes can still give good results in any case. ID3/C4.5 are decision trees. You know the kind management bring up in conferences? These are admittedly a bit different then that, but follow the same general logic of: If x then this, if y then this. Yeah, they can also be considered under the machine learning umbrella due to how they are built from using labeled training data, and distilling said data with entropy formulas to find optimal splits in the tree. One common issue for most decision trees however, is over-fitting your training data. (The process of which your tree has become perfect at classifying your training data, but is unable to classify/or generalize new data as the "progression-ary" logic of stepping down the trees nodes/Selected features has become too correlated to the initial training data). This problem is normally combated with keeping a subset of the training data on hand, and running it against the tree as if it were unseen data to find nodes that you can potentially prune to give better generalization results. The cool thing about both of these algorithms is that I feel even a motivated beginner could homegrow/code these out without substantial help. However, there are all sorts of other algorithms, random forests, SVMs, linear regression, and the list goes on, and on. ANNs usually fall into the deep-learning categories, and excel in certain tasks (image detection). However, using them for Sentiment Analysis, or Text classification is usually a bit much when a Bag Of Words/Bayesian Approach can give similar results, with similar accuracy, less probability of over-fitting, less black-boxish (though arguably multiplying thousands of probabilities together when computing the algo isn't much better ) and easier in general to code/tweak. I'd recommend checking this out as well. It gives a good, non mathematical perspective of a typical bayesian classifier. It's beginner oriented, and the author articulates himself well enough that what he covers is easily transferable to code. https://monkeylearn.com/blog/practical-explanation-naive-bayes-classifier/
  5. R&D Advanced AI in Games?

    I suppose one metric that could be gauged by modern, "Deep Learning" in game development is adaptive difficulty. The trick would lie in the Goldilocks zone where the player is challenged, but not over-whelmed, and not given so much leeway as to lose interest. Arguably though, one would not even need to leverage an ANN for this. A whole other slew of (examinable) non-black box Machine Learning algorithms could fit this bill.
  6. Animating characters on sloping ground

    Maybe having an up-vector for the models that points in the same direction of the face normal of the underlying polygon? And Orientate your model to coincide with that?
  7. Hmmm, I believe both styles you mentioned are examples of 3rd person cameras. The only qualifier being the Playable Character being rendered in a 3D environment within the view frustum so as the player can see them. Usually the PC (or the camera) will be latched, and offsetted so that they both stay within a relative position of one another regardless of where they are in World Space. Insofar as turning the character with the camera being turned is a matter of gameplay, and style. I wouldn't care for such a feature in a platformer, but in other genres, or sub-categories (actually thinking of the Hog vehicle in Halo) it works ok. I don't know your background in Game Development, or what experience you may have in any frameworks/engines/APIs, but if you want some nitty gritty on camera systems this site has plenty of articles
  8. What's wrong with being a Sonic Ripoff? The early Sonic games kicked butt. Unless you're ripping off the new ones O_o Take what they did in Sonic, and improve on it. Taking in what they did, distilling it, see why it worked, and do it better. Greatness is usually achieved by standing on the shoulders of those who came before you.
  9. It's almost impossible to find design that is 100% unique in this day, and age. Art Style, Good Design, and more important than all of that is the fun factor. If the game is fun, that's all you really need. Of course, the former certainly lend their hand to the latter. But game design should never be focused in making it as "Unique" as possible, but as intuitive, and fun as possible. If that's a philosophy that is echoed a lot, than maybe there is a science to that.
  10. 3D Shadow Map Jiggling/Shimmering

    kinda looks like a bias issue. the depthmap is of limited precision, so shadow acne (shimmering), or peter-panning (shadows that are biased too much, and become dis-attached from the occluder) are usually related to biasing. What value do you have in your second pass pixel shader that serves as the bias? Maybe try toggling that a bit, and see what it gives you, it can be very scene dependent.
  11. How to protect yourself and your game?

    This is the nature of contracting out your workloads for a, "confidential product" If you simply cannot trust anybody with the workload you plan to give them, than you simply need to learn how to do it yourself. You could always attempt to STIFF the workstation they are likely to use. I.e. disable USB ports, setup web-proxies, ect. But even than, there is always a work around.
  12. How to protect yourself and your game?

    Don't outsource beyond your legal departments jurisdiction? I'm sure there is a lot of untapped talent all around you.
  13. How to protect yourself and your game?

    Have them sign an NDA. It really will come down to Contract law. Obviously, once they have access to the source, they have access to the source. You can't force your contractors to not be nefarious, but you can certainly promise legal repercussions to such actions. You may want to get an Attorney, or at least schedule a consultation with one. At the end of the day, "trust" is the keyword here. If you have any reservations of the people you are onboarding, then simply don't bring them on.
  14. haha, manually tagging each one would be a pain for a large map. When you initially create your tiles, loop through them, and assign the respective tile type. So let's say, a trivial example, I'm utilizing an array for my data set for tile creation. 0 = side_walk, and 1 = road like so: int map [] = { 000000111000000 000000111000000 000000111000000 000000111000000 000000111000000 000000111000000 }; You may be using a different data set for your map creation, an image, a text file, whatever, but the key is to know what data you're working with to generate your tiles, and to give it meaning within your application. So with the above example, since I've denoted 0 = side_walk, and 1 = road. I can loop through my dataset, and create my tiles with those appropriate types in mind like so: for (int i = 0; i < MY_ARRAY_SIZE; i++) { if (map[i] == 0) myMapVector.push_back(new Tile(SIDE_WALK)); if (map[i] == 1) myMapVector.push_back(new Tile(ROAD)); }
  15. Are you talking about excluding the road from a search area? Say like excluding it from the Open List of an algorithm like A*. If so I'm assuming you already have some internal structure representing Tiles. You could expound on this by adding an enumeration for type. like, uh, say enum tile_type { ROAD, SIDE_WALK, DIRT, ECT }; And than just conditionally parse through your tiles come search time and omit the tiles you don't want in the proposed search area.
  • Advertisement