I almost got on a rant about how conservatives try to call it "special rights" when we get access to a subset of the rights they've always enjoyed, but also I needed some time away from a screen.
Is there an easy way to set the center of mass of an object to it's origin in Unity? It gets really complicated and glitchy doing that in SketchUp, but when I don't, the model rotates around the worst possible point.
CodePlex archives will be shut down after July 1st 2021.
We still have a bunch of links to it.
I'm sure there is a bunch of projects that were hosted there are now hosted somewhere else, like on GitHub. The project page will often advertise as such.
If you folks have the time and want to have you...
Oh, and I see now why it is so hard to make games. The sounds, models, and then scripting. Because such enjoyment from a video game comes at a cost.
Heh, almost everything in game making comes at a fair cost. For example, I want higher fps in my game. So, I need to: Spend time and effort and maybe sanity by creating a copy of a model, and then greatly decreasing its complexity, then doing so again, making 3 layers of complexity; for every 82 variants of my 1942 Willys Jeep => much-improved fps, less game crashing. Cost: 27 hours of time, 200 effort points (where 10k is required to make my detailed B-29), and 12 Sanity points.
Fair trade? Maybe.
Why 82 variants? A cataract of 50 jeeps (which would be more like a "herd" of jeeps) that are all the same exact thing is very, very boring. And also abnormal. But, having multiple variants that actually existed in real life? Amazing! Cost: some game crashing (loading too many things at once), a bunch of fps. Fix: Layer my LOD for each jeep.
I just had to go and make some jeeps because they appear, and are driven by the player very early in the game. When I say "early in the story", I mean they need to use one to get over to the B-29. They basically take only 300 steps before getting involved with the jeeps.
...Or, should I have the player ride in the 1942 Dodge WC62 3/4 ton 6x6 instead of driving? Yeah... That'd be better for the prototype, and also the player, since they just started. It's easier for the prototype because all the player has to do is sit in it. Great.
@Tyyppi_77 actually, I suck at making sounds, and my brother really wants to help my game, so he is making me sounds. he is actually great at that. He has some real nice explosions, flair sounds, and he made walking sounds for basically every material you could think (like sand, mud, etc.) So I'm not actually doing this alone.
So, I get to ask what in the world I am going to do about my 250 bullet chain for my M1919 Browning Machine Gun After I have a very basic, functioning prototype?
right. I am going to begin scripting. Great for this case, Multiplayer won't be a thing until far later, so I don't need to rig a character at all for the prototype.
I hate rigging characters, so at least I don't have to do that.
@Almo @Tyyppi_77 what exactly would be a prototype? I don't want to go too far, but I don't exactly know where I should call it a good 1st prototype. So, I know I need player actions, like moving, and... what else?
If your first gameplay is about being a gunner, then start with 1: aiming the reticle, 2: shooting a bullet, 3: detecting when that bullet hit something, 4: having some moving targets to hit
With those 4 steps, you can already make a decently engaging little game (Missile Command, or the whole genre of lightgun shooter arcade games, are pretty much just this)
You can upgrade that to a projectile sprite later if so desired.
Game content is often built as what's called "greybox" first. Where we build everything - the level, the props, the characters, out of literal grey boxes (or sometimes capsules or other primitives). They just have to be roughly the right size on screen to convey the layout and let us test the gameplay mechanic.
As you go along, you gradually replace some of the boxes with early rough art, focusing on the ones that make the biggest impact on the experience first. Then some of that rough art can later get replaced with better art.
The idea is that we prove out the gameplay with minimal up-front spending on assets first. Then if we find out that actually this thing needs to be 1.3 meters high instead of 1.2 to look right in the in-game camera view, we can fix that with one scale number, without re-making an expensive asset.
By the time we get to making the polished art assets, we've nailed down exactly what assets we need / don't need, we know where they need to go and exactly what dimensions they need to be, and we're able to prioritize which ones are seen up-close or get more focus and need higher detail, versus which ones you barely see so we can make them more cheaply.
At typical engagement distances for the kind of combat you're talking about, I'd bet you could get a very long way treating the enemy planes as cubes/capsules. Or maybe a sprite plane with just a silhouette of the vehicle.
Unrelated: I thought this question was just going to be a simple "you can't" - but it turned out to be more interesting than I'd thought. 😃
A rather simple question, how do you check equality of a scriptable object without references?
For example, I have a weapon class that holds a list of damage types the weapon deals, which consists of a float and a ScriptableObject class (Element).
[System.Serializable]
public class DamageInfo
{
...
You can use something like a skybox to have a surrounding to help orient yourself, and you can use simple sprites for clouds to gauge how you're moving.
I have a question about Unity's ScreenToWorldPoint. Whenever I use ScreenToWorldPoint(Input.mousePosition) and display the output in console this always gives me the same coordinates.
MyCode:
Vector3 screenToWorld;
void Update()
{
screenToWorld = Camera.main.ScreenToWorldPoint(Input.mouseP...
I have a question about Unity's ScreenToWorldPoint. Whenever I use ScreenToWorldPoint(Input.mousePosition) and display the output in console this always gives me the same coordinates.
MyCode:
Vector3 screenToWorld;
void Update()
{
screenToWorld = Camera.main.ScreenToWorldPoint(Input.mouseP...
