Unity and XNA and now Monogame are probably the big pulls for C# (And mono, Unity is technically some old decrepit version of Mono). It's also a delightful language to program in compared to C++, depending on what you're doing, of course. At my day job, we use it for all our unit tests, because it's much faster to write, and cleaner than C++, so it's easier to write unit tests and easier to grok what the the unit test is supposed to be testing.
Thank you so much .. my concern is about the graphic quality in libGDX , i saw the demos in libGDX by comparing the Graphics quality to those made by Unity .. i noticed some difference ? is that related to libGDX or to the design itself ? Also my 2nd concern is about making the animation effects , would it be easy to be done by libGDX like Unity3D ? or i'll face dark way until i do it ?
I'm not that familiar with libGDX, but Unity, for 2d, it doesn't really do anything special, so I would be surprised if libGDX couldn't match it for effects. Though perhaps we should define what you mean by effects? shaders? animation frames? Getting a good artist will make all the difference.
You have to be careful when hiding mechanics from a player, especially random mechanics. Especially random mechanics that cause the player to die/lose/lose progress. Just because they can't see it, doesn't mean it won't frustrate them any less =) It might frustrate them more. You might try prototyping that mechanic in another game, if you have access to a simple top down shooter, or are good at Unreal Mutators, you can probably whip out a "Random chance of death on hit after Health less than X" rule.
Though a bullet hell shooter where the player has multiple lives, it might very well work, seeing as they still have a concrete amount of retries with no loss of progress.
I'm also reminded of the Pkunk from Star Control 2, with their random chance of respawning after death. It sort works for that game, because that was not the player's only ship.
This gets easier with vector math, instead of an angle, you have a directional vector that you use for the ray. If you have walls, you'll also need to reflect the ray and compute that intersection (and if that ray intersects a wall, you compute that intersection... you'll want to limit the check by distance, or you'll look where the ball is an infinite number of bounces later)
Were comments added after the thread was started? Because there are comments explaining them right in those areas:
// in stands for "incoming"
// out stands for "outgoing"
// I stands for "incident"
// R stands for "reference"
// extent, as in the extent of each OBB axis
But yeah, those variable names... huh...
Yep, just added them in. Unfortunately I didn't come up with the names for a lot of these things. Extent. Incident. Bleh. Also it's much easier to just derive things on paper and copy down into the code the equations, so a lot of abstract symbols come up, like e and whatnot. Apologies if any of that is confusing.
Yeah, when doing straight up math, I often do the same, and fall back on short math variable names over long variable names like fMomentum or whatever. It makes it a bit easier to see the formula. A half measure is a really long parameter name that gets immediately reassigned to a short local name, the nice part then is that someone using an intellisense or looking at the header file can easily grasp the full meaning, but the actual code still resembles the math. The compiler will optimize out the local param.
It's still fairly random, it reminds me of the Halo games that hid the health bar, and just showed the shield meter (I think this was every Halo past 1). The player still had health (which in your case would correlate to the second meter, critical health) But since the player couldn't see it, they would sometimes die early, sometimes die late, if they hadn't been paying attention to how often they'd been hit after their shields went down. It was annoying there, but less so, because the player was at least guaranteed some leeway the first time their shields went down. It mattered less as a multiplayer game where death simply meant respawning. Are you making a multiplayer or singleplayer game? What happens when a player dies?
In an action game, where you only control one character, random chances you die instantly from a hit, while other times you don't, that's just going to be confusing and frustrating for the player. Otherwise, the design sounds interesting, though things with lots of quick attacks are likely to kill the player more than super slow strong attacks, at least once they are down in the second tier of health.
I agree also that random health regen, what do you really gain with that? What gameplay does that add? I'm not entirely opposed, as it's not quite as mystifying or punishing as dying sometimes and not others.
They do it much as you suggested, by casting out 'thick' rays at several different points on a vehicle. Many games do this for humanoids too, casting rays to each of the limbs. I think the newer Fallouts do this, but I'd have to double check by blocking an arm behind cover and seeing if I could still shoot it with VATS
I have implemented the render method myself for an XNA game that I never released. It's a little slow, so I wouldn't recommend it for a real time game, but it's kind of neat how detailed it can get. You can speed it up by using a smaller viewport and rendering only the collisionboxes of the models and not the actual models. I'm not entirely sure how much Ortho really buys you, depends on if you are calculating the to-hit based upon how much is actually outside of cover (ortho), or how much the shooter can see of the target (perspective). But it's not expensive to do things Ortho, so it's mostly a philosophical debate=)
The other method is the X-com style, where you have discrete cover types. Half cover and Full cover, and then you check if there is any intervening cover between the two characters.
EDIT: One other thing I did for the Render method, was different colors for different cover types, I had 'soft' and 'hard' cover as two different color channels and blended everything. (Ie Red == target, Blue == Hard, Green == Soft)
EDIT2: And checking the OP's original link, looks like JRPG/TBS, in which case I'd lean more towards X-com style, it's more helpful for players to know what kind of cover they'll get in discrete chunks over small percentages.
There two problems with that, ferrous. One is that I have had a very, very serious life-long medical condition that I was born with. So serious that less than 20% of people born with it survive childhood. I made it through most of my life very well for someone who has this, but for the last 6 years or so it has kind of taken over. I have had skin cancer 6 times in the last decade, for example, and can no longer go out into sunlight. I live like a vampire, hiding from the sunlight. Because of this, and many other problems associated with it, I have been forced to work only part time (at night) for the last 6 years. It's almost as though my life half-ended about 6 years ago. So I don't make very much money anymore, in fact I barely get by with all the restrictions I have now. So I can't afford to hire a programmer.
Even if I could, I don't see how a simple prototype of a basic empire building game (the game I have for that) that has none of my special magic in it is going to help, It would be no different than games anyone else might make. And I would spend a lot of money for the same exact reaction I always get. Doing the Cold War game as that prototype, it could certainly show some things that have never been seen before... but getting even to that point would be, I am sure, significantly more work that a typical prototype. So it would cost even more, when I haven't had spare money for 4 years now.
So I can't afford to do that, and if I could it would probably cost twice whatever it is you are imagining it would because I would have to get the Event Cards in my cold war game functioning. That is the simplest demonstration of Rube that I can conceive. And, besides that, the design document for the Cold War game already IS that prototype. It's all in there already anyway.
Then it sounds like, at this point, you can't go it alone, you don't have the ability to get funding or pay anyone. It would seem your best options are to either find someone sympathetic enough to your cause to program for free, or realize that at your age and in your condition your best bet is to put your rules and ideas out there for free and hope for the best -- it's better to have a game that you don't profit from and is played to have something that is never discovered or played at all. Maybe a patreon page and a blog to drum up enough support to get some funds? You have stories to tell, and some of your posts on the web manage to hold back your dismissive tone and get information across.
Make a prototype. You don't need millions of dollars. You seem to have some sort of deep seated block against doing it yourself, but you don't need anything but one programmer, so go hire one programmer under a contract.
The most important thing is to understand lighting's limitations. How many lights you can have in a scene, what is expensive to have, etc. For your given platform. Don't want to put a bunch of lights down, have it look amazing in your editor, then watch the slideshow that ensues on your mobile phone.
Something to keep in mind with budgets, is that it's not just salary, but benefits and whatnot as well, the rule of thumb is to usually double the salary to take into account having to pay for healthcare, product licenses and whatnot. At least if it's your own studio, outsourcing you don't have to do that.
And I disagree with only the dialog quality being important, the mechanics used drastically change how the dialog gets implemented and written. The branching dialog for a game like Mass Effect with a custom party would be written very differently than a JRPG with no choices and a static party.
I agree with others that the scope is too large. Assets from the Unity Store only mildly help, you can't rely on it as you end up with inconsistent styles and poly counts, and even assets from the store will probably need tweaking to suit your needs.
The Dreamworld stuff is a nice idea, as you can re-use areas and art with minor tweaks to make it feel new.
And as someone else said, a large sandbox of sameness is not great, there is nothing wrong with making a small sandbox that is amazing and full of fun stuff to play in. (Procedurally generated or otherwise)