Gordon Cole posted:

I believe bitbucket is a free alternative, but I've never tried it myself.

Jewel posted:

And that's pretty much my biggest flaw right there. I don't know the """best""" ways to write the communication between things, end up hacking together a system of passing objects/parents, and then it gets too messy and I stop.

Gary the Llama posted:

Went back to some old code (FlashPunk/AS3) today to fix an issue with diagonal player movement going faster than it should. I should just need to normalize the velocity, right?

code:

velocity.x += acceleration.x * FP.elapsed;
velocity.y += acceleration.y * FP.elapsed;

var speed:Number = Math.sqrt(velocity.x * velocity.x + velocity.y * velocity.y);

velocity.normalize(speed);

this.x += velocity.x;
this.y += velocity.y;

if (Input.check(Key.RIGHT))
{
	acceleration.x = 12.5;
}

if (Input.check(Key.LEFT))
{
	acceleration.x = -12.5;
}

if (Input.check(Key.UP))
{
	acceleration.y = -12.5;
}

if (Input.check(Key.DOWN))
{
	acceleration.y = 12.5;
}

if (!Input.check(Key.UP) && !Input.check(Key.DOWN) && !Input.check(Key.RIGHT) && !Input.check(Key.LEFT))
{
	acceleration.x = 0;
	acceleration.y = 0;
}

// Friction.
velocity.x *= 0.9;
velocity.y *= 0.9;

Any idea what I'm doing wrong? Also, any other recommendations on the player movement stuff would be appreciated, in case I'm doing it wrong.

field balm posted:

I'm thinking about starting a multi-player game soon, which will be turn based. I have little experience with networking. Does it sound safe to develop the game keeping model-control-view separate, with both players being controlled from the same place, then when the game is complete re-tool the control side to be networked? Most likely I would set it up so single player or the person hosting would be running a client and a server, and a person connecting would just be running a client. Is tcp/ip connection the way to go? How high would bandwidth be for a simple game like this for a node.js dedicated server or something?

floofyscorp posted:

That 'low monthly payments' line seems a bit ironic now.

Suspicious Dish posted:

The problem is that nobody can agree on which 10% of C++ that is actually good, so you have to know all of it if you work with a team of four or more people.

OneEightHundred posted:

code:

float grain = 7007.f * 64.79891f;
float pounds = 1.001f * 453592.37f;

How easily can you tell that those two are not the same?

dizzywhip posted:

Sorry, I think I wasn't very clear...I'm not trying to make the general collision hitboxes or figure out how to split up the sprite sheets. I'm using box colliders and the sprite editor for that already, which is working well so far.

What I'm actually trying to do is define additional hitboxes for different portions of the sprite that sync up with the animation, basically like a fighting game. So if the character punches, for example, I'd like to have a small hitbox around the character's hand for determining whether it makes contact with another character. Ideally I'd be able to have the hitbox enabled only for particular frames as well.


That's actually pretty much exactly what I'm looking for, but I'm not sure how to set it up so I can configure it per-frame.

joe_eyemobi posted:

echinopsis posted:

goto always works great


its like sticking your bumber on your car with duct tape. flawless for practicality reasons but ugly 2 look at

Rocko Bonaparte posted:

This whole thing between Unity and UE4 is messing with my head. Two years back, I was making GBS threads out C++ and doodling my own little C++ engine to get up-to-snuff on C++ and game stuff. Everybody was doing Unity then. I was doing a lot of C# at work and really don't have problems with it. I'd rather be writing in that than C++ most of the time. Now everybody is running off to UE4 and doodling in C++. What should I be looking at if my unrealistic expectations are an action RPG or simple RTS, but would probably wind up just making really small, simple things? This because I'm just one dude with some spare time. I think I'm pretty fluent in both C++ and C#, but I'm not really interested in picking up yet another one.

Rocko Bonaparte posted:

ok so to dabble in it, it sounds like I can just plop down $19 bucks, unsubscribe, and see how it goes. If I ever get serious, I guess I can sign up again. Is that right and legit?

What is my recourse for doing some kind of scripting and rapid prototyping? I could only see their visual scripting language, but I was hoping for something that I could monkey in real-time in a text editor.

Nition posted:

Speaking of colliders and algorithms, one thing that's caused me endless headaches in my current game is calculating weapon movement ranges. Every weapon is a turret with some amount of X (pitch) and Y-axis (yaw) movement. Never any Z-axis (roll). Some have full rotation on the X axis. A few examples with rotation ranges visualised:



The blue + red areas combined show the full movement range of the weapon, and the red areas show where it could move but it's currently blocked by something. It looks like it's doing an OK job of calculating those, but there are plenty of cases where my current solution falls apart.

I need to find the limits of where it can move. Some notes:

• I don't want weapons to hit or shoot your own vehicle, so you can imagine the weapon barrel is essentially infinite length.
  
• There are more complex solutions, but all I want is a reduced box for allowable movement - an adjusted Min X, Max X, Min Y and Max Y that take into account surrounding colliders on the vehicle.
  
• All colliders to check against are AABB non-rotated box colliders.
  
• You can assume all other parts are non-moving.
  
• Sometimes there are multiple solutions where you can choose to reduce either X or Y to avoid something. I currently keep track of several options and at the end, take the solution with the biggest remaining area.
  

I've already tried solving this in different ways:

• With raycasts. Relatively simple. Raycast a whole lot, evenly spaced at different angles, and reduce rotation range based on the hits. But I never managed to get a good tradeoff between accuracy and performance. It was either not accurate enough or not fast enough (game is in the Unity engine). I need to be able to update ranges on-the-fly.
  
• Letting physics do it. Just put colliders on the weapon barrels and let them hit the vehicle and get stopped. This behaved in a janky way, wasted performance because I should be able to pre-calculate it, and didn't stop weapons shooting your own vehicle if the barrel missed something but a bullet didn't (extending the collider might do that but then I'd have to worry about other things hitting it etc).
  
• Checking other colliders manually. This is what I'm doing now. Look at every other collider on the vehicle, with early exits where possible, and convert its position into angle limits, then reduce the max rotation range as necessary. This sounds kinda simple, but in practice it's been extremely complicated and difficult to get right, and I still have things that don't work because I'm not doing it perfectly.
  

Sorry for the wall of text. I feel like this is something that must have been done before, but I couldn't find any sources of information on it. It seems impossible to Google but it must have been done. Someone told me to look into robotics research, but I wouldn't know where to start. If we can send people to the Moon we must be able to reduce a rotation range based on some box colliders.

Nition posted:

Vehicles can lose parts in-game, which often means the movement range needs re-calculating on some weapons (I only recalculate if specific parts that were blocking the weapon are lost). Vehicles can get pretty complex and Unity's raycasts are petty slow. To get a decently accurate result on a full turret weapon, raycasting 3 degrees apart say can take 10+ms per weapon, which is too much. The collider checking method is much faster (more like 1ms if that).

The same weapon will always have the same base movement range, but I'm calculating places where it can't aim due to other stuff in the way, which can be in all sorts of configurations. You can place a weapon on your vehicle in any spot as long as it can shoot straight ahead - it's not like Robocraft where the full movement range of the weapon has to be free.


It's highly likely that I'm making this method more complicated than necessary due to having to work out a solution myself. It's easy to say "just subtract the colliders from the range" but the maths involved kills me. Certainly it's gotta be like a type of boolean subtract, but like Rocko Bonaparte said although I know what that is I haven't managed to work out how to actually do it here. Especially since this isn't really comparing shapes against a shape, but more like comparing shapes against one infinite-radius chunk of a sphere.

OneEightHundred posted:

I disagree, what makes game development awesome is all of the things that serious computer scientists don't do, like deal with the fact that everything in the game capable of moving will, at some point in development, be launched into the stratosphere by a physics bug.

dupersaurus posted:

Not to be an annoying (nonpracticing) art graduate here, but there's more to being "painterly" than making a shader to add a canvas texture and makes it look like paint strokes -- paint strokes are almost by definition unalgorithmic. The battle here is going to be won and lost in everybody's favorite things: textures and geometry. I think you're still is actually on a pretty good path (just get rid of the canvas texture). My texture artist skills are next to zero, but the path to go is probably to paint into the textures, to help the lighting out and add some variations. Look around your inspiration for all of the little variations in shading and contrast and stuff.

Not to mention, the inspiration image is an etching hand-colored with watercolors.

orenronen posted:

They don't even lock up mobile publishing in Unity 5. You can publish on any platform, including iOS and Android, for free (with mobile you're stuck with a "Made with Unity" splash screen at startup). If you make a certain amount of money from the game or if you want to get rid of the splash screen you do have to pay, of course.

Shalinor posted:

The animator thing is definitely key. The way we've built the team for Spartan Fist focuses on procedural punch anims, meaning we're not planning on much animation time. We made that choice due to the wide range of fist types. Advantage, we can do procedural trickery to make a single animation work across more fist types and adjust impact positions to be SUPER meaty, disadvantage, the procedural animation itself ends up being complicated, advantage, the Rayman-style fists make procedural way easier than user, disadvantage... etc. Which way you go on that is as much a choice driven by your team composition as it is desired outcome, and we happen to be tech heavy given that it's a proc-gen game already, so there you go.

(EDIT: if we had arms instead of just floating fists, no way would we have gone the 3D / procedural route - but I do want to try the crazy scale gradient someday, to see if it works)

I'm very much not prepared to agree that 2D rather than 3D is the way to go BUT, even so, your uppercut kicks rear end, great work on that.

ShinAli posted:

I've recently adopted putting [SerializeField] property on all things that are going to be serialized as my common practice, regardless if its marked public or not. It helps cement the idea for other people looking at my code.


It's because Unity is a C++ engine and doesn't necessarily run Updates on MonoBehaviours in Mono/.NET land. On each MonoBehaviour derived class, it looks for functions called "Update" (and other things like LateUpdate, FixedUpdate, etc) and grabs their handles. When Unity runs the update loop on your scripts, it loops through all the .NET objects instantiated from MonoBehaviour derived classes and invokes the method handles it grabbed earlier against them. This is why your call stack doesn't get any deeper beyond your Update function when debugging.

It's also why making your own Update manager in .NET/Mono land is faster than letting Unity handle it, since it has to do some context switching when calling into .NET/Mono land.

EDIT:


http://blogs.unity3d.com/2015/12/23/1k-update-calls/ is the one I think? It's a good article and what I was talking about using your own Update manager being faster.

Rocko Bonaparte posted:

I'm beating myself up over ScriptableObjects and serialization. I had a MonoBehaviour that just served to store and build my pathfinding network; Update() and Start() were just empty. I needed the data to persist into the game, so it sounded like a good place to use a ScriptableObject. I changed it from a MonoBehaviour to a ScriptableObject, marked the pathfinding network field as a serializable field, made sure the data type was also serializable, and then tried to use it. I still lose all the pathfinding data when I go into the game, and if I restart Unity.

As it stands the ScriptableObject is attached to a GameObject that I select and use a custom editor I wrote to build the network. That information persists if I switch between objects in the editor. It's just when going into game more or restarting Unity that everything goes away.

Just to give an impression, this is what it looks like at the ScriptableObject level:

code:

[Serializable]
public class MatrixSelfBuildingNavigationNetwork : ScriptableObject
{
    [SerializeField]
    public LevelData LevelData;
    [SerializeField]
    public Vector2 UpperLeftBound;
    [SerializeField]
    public Vector2 LowerRightBound;

    [SerializeField]
    public Vector2 UpperLeftBoundCentered;
    [SerializeField]
    public Vector2 LowerRightBoundCentered;

    // Used by the custom editor to draw the network.
    public bool DrawMap;
    public bool DrawLinks;
    public bool DrawHeights;

    public void BuildLevelData()
    {
        // Tighten up the initial constraints. They are usually given as whole numbers. When
        // GetCentered is called on that, it's tending to search out beyond expected area.
        // For example, if the upper left bound is (0, 0); we'll use (0.5, 0.5). The problem is 
        // that we really wanted (0.5, -0.5). Similarly, if the lower left bound is (0, 0), we
        // want (-0.5, 0.5).
        UpperLeftBoundCentered = (UpperLeftBound + new Vector2(0.01f, -0.01f)).GetCentered();
        LowerRightBoundCentered = (LowerRightBound + new Vector2(-0.01f, 0.01f)).GetCentered();

        // var builder = new OptimizedMatrixNavigationBuilder(new PhysicsWorldTester());
        var builder = new MatrixNavigationBuilder(new PhysicsWorldTester());
        LevelData = builder.BuildLevelData(0.0f, LowerRightBound, UpperLeftBound);
    }
}

Rocko Bonaparte posted:

Those values come from little poles I place in the world to mark off the region. I'm usually typing it in, so they round the right way, but if they're within their respective squares, it will cut off the area I want to cordon off. So, like, if I was cordoning off a 3x3 square, and they were a little bit inside their respective squares, I'd normally wind up only testing the centermost one because that's the first completely enclosed square.

Rocko Bonaparte posted:

Thank you. I am going to be chewing on this soon. After I posted that, I eventually got things working well enough that I could see my pathfinding working in-game, so I was experimenting with it. I have some questions about that now.

I am seeing some bugs in my pathfinding heuristics. I don't mean the A* algorithm itself, but what I am doing with it. There are a few different problems:

1. Monsters getting stuck around tight spaces.
2. Chronic backpedaling when recalculating routes. It will calculate a new route if it's finding that it's getting further than it expected from the player. Well, it's not THAT smart yet, but I'm not really testing that yet. The issue is that when it does recompute, it tries to hit the first coordinates in the route, which are often behind it. It winds up turning around to reach the waypoint before continuing. I was thinking of making hitting, say, straight waypoints be a little loose while corner waypoints will be very strict. This might fix #1. Also, I recalculate too often, which should overall just prevent it from happening as much.
3. The initial waypoint is actually on the other side of a wall. The center of the mob is closer to that place than where it legally can be.

I am trying to come up with solutions for all of these to make the navigation more elegant, and could appreciate any thoughts you might have.

Zero The Hero posted:

I'm not tied to Chromecast. I've got a wireless display adapter from Microsoft, that would do fine.

You think Unity is the way to go, then? I'd need the program to be able to load user content, either directly or through modules. Will Unity support this?

DStecks posted:

Is there any relatively-straightforward way to get the camera in Unity to always be at the right orthographic size for pixel-perfect graphics, for arbitrary screen resolutions? I'm trying to make a roguelike framework, and I want the game display to work like Dwarf Fortress, where the tiles are always pixel-perfect and you simply get a wider field of view if you make the window larger.

Also, what the hell, can I not use Tuples in Unity? Apparently it's not up to the latest release of .NET?

DStecks posted:

That's not the problem; the reason why I wanted native Tuple support was because it might mean all the elements would show up in the inspector.

22 Eargesplitten posted:

Yeah, my current line of thought is to break the loading into different sections. Currently there's one distance from the NPC where everything loads. I was thinking break it into AI, models, textures, skeletons, and animations, as well as anything else I missed. The question is just if that's going to give a ton of tiny stutters rather than one bigger stutter, which would also really suck. There are also apparently some pretty big problems with how they load assets that I can rework after this.

If the multiple loading sections doesn't work, I'll probably be back in here asking how to do what you said. That was my backup plan before the multi-core support was introduced, which I think will make it more complicated. I've only got an AS, so while I know a decent amount of structures and how to do references and pointers, there's a lot that I never did. Pointers should actually be a huge help, apparently the original devs barely used them at all, which is what I was mentioning about asset loading. They load a new, identical mesh every single time that there's a new texture to attach, rather than having an object pointing to a single loaded mesh and a loaded texture.

22 Eargesplitten posted:

I'll check on that. The multi-core stuff isn't my code, and was made by people who seem to know what they're doing technically, but I'm also thinking about generating more threads to do real-time loading, and I'm not sure if it would let another thread grab one of the entities it's loading. Locking down that particular thread should be super-easy, though, if I go with creating and destroying it as needed. I just asked in the C++ thread if that would be a performance-killer, I've never worked with multithreaded C++ before.

Wait, looking into this some more, does the scheduler direct all the traffic? Seiken said I would need to write the code myself, but according to a thread on cplusplus, the scheduler organizes what gets put on each thread, so it seems like if the thread was occupied by the NPCs and their inventories being loaded, everything else would get shunted to the other thread. Or did he mean that after the loading was done, I would need to make the loaded stuff available to both cores? I don't really understand.

Mr Shiny Pants posted:

So for you guys who use Unity, any must have assets?

I've already bought Simple Waypoint System because I needed my enemies to follow a path and it is working pretty great ( for 20 bucks I can't code it myself ).

All in all I am pretty impressed with Unity and the ease of development. Having C# as a language sure helps.

One thing I was wondering though: is there a limit to the amount of scripts I can hang of a game object? Or does all this stuff get compiled into one big script?

ToxicSlurpee posted:

Far as I can tell any amount and I don't think it does. You probably want to keep each object limited to as few scripts as possible to avoid update orders but I'm pretty sure Unity also lets you dictate what order scripts are called in so that's not a huge deal. You can also create classes that aren't inherited from MonoBehaviour and do traditional classes and objects within those scripts just fine.

Chernabog posted:

Is there a more accurate way to measure time in Unity than this? Sometimes the spawns get desynchronized when the spawnInterval gets too small.

code:

void Update () 
{

	elapsedTime += Time.deltaTime;

	if (elapsedTime > spawnInterval)
	{
		elapsedTime = 0.0f;
		SpawnerT.GetComponent<enemySpawner>().spawnHere ();
				
	}
}

Sorry for all the noob questions

darkpool posted:

A few years back I developed a Unity3D-ish engine clone for a small company to try and snatch up source code sales Unity weren't supplying, at the last moment the CEO decided we would actually be going toe-to-toe with Unity instead, my team quit (both of us) and so the project folded. Anyway, due to financial destitution I've been thinking of revisiting the idea with a different approach, I've worked on a few Unity/Unreal projects since and I find the same problems still exist.

Needing to use an engine I downloaded UE4 and instantly found myself immediately overloaded with interface, with no idea how to do what I want quickly. This is despite being an Unreal veteran since version 2, and been lead dev on a UE3 game where I heavily modified the source.

Back when first starting to use UE3 it took a few days to for me to even start working out how to make a game with it, I ended up constructing an UnrealScript framework to do what I wanted. Faced with doing the same thing in UE4, I immediately uninstalled it and re-opened Unity3D.

I've recently left a Unity3D horror show so issues there are still very fresh in my mind, I've been thinking what I would do to fix them.

* Bugs. Using Unity 5 I found the lighting was next to useless. Enlighten produced awful results and brought my machine to a halt for 3 hours while doing it. A lot of forum Unity forum posts suggested the lighting was pretty much broken currently and there are no plans to fix it. So coming up with a workable PBR pipeline in comparison is probably doable.

* The shell development approach is quite at odds with how a lot of game development still happens. Git is designed for the command line workflow, look at the log, make changes, commit regularly, rebase regularly, undo with the reflog etc. However the CTO of the horror show had decided to go with Git without having any experience of it, so the workflow was to do stuff in Unity and then wrangle Git though a GUI that lacked basic commands, then teach the artists and designers to do the same. Unsurprisingly they told me Git had lost a lot of their work when I joined, hmm. Small mobile games companies these days don't want the cost and overheads of Perforce so the Linux dev world and game dev are colliding in an unpleasant way.

It's been a long time since game dev has been the domain of Windows, with most Unity3D users preferring OSX so better shell development integration is possible. I'd for like a new engine I create to have the development centered around the Git workflow, its better to get that right early on than have a hash up later. Sure, the barrier to entry is higher but Unity still exists.

* As projects become larger use for the Unity GUI tools become a lot less and projects become code driven, I'd like to start with a fully code driven interface like Futile and specifically cater for more dynamic-ness. The horror show company was producing a Boom Beach knockoff so there was no need to place things in the editor, and as Shalinor mentioned somewhere above UE4 finds itself very limited with it's FPS, static level orientation.

As far as scripting goes, probably a JavaScript VM with a TypeScript framework. That makes the scripting close to C# and easy to build HTML5 versions. I'll probably go with mixins because I think that's a better way to blend static and dynamic typing over the component model, although TypeScript currently needs some hacking to support mixins better.

Anyway dear SA forum users, let me know if you would use such an engine and I'll arrogantly ignore everybody's suggestions and go ahead, creating my dream white elephant project nobody will else will ever use Derek Smart style.

Just joking, what could I add or remove from that short list?

Vlad the Retailer posted:

Is there such a thing (for rigid body dynamics)?