Game Development Megathread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Game Development Megathread

«‹›622 »

The King of Swag: Nov 10, 2005; To escape the closure,
is to become the God of Swag.

xgalaxy posted:

This is exactly the thing I'm battling now with my posts in another thread regarding SeviceStack. The stock library functions fine under Xamarin.iOS and Xamarin.Android but didn't work on Unity. Luckily this particular library was really easy to port. However, other libraries which utilize .NET 4+ that work perfectly fine on Xamarin are not portable to Unity without tremendous amounts of effort, especially if they make heavy use of new .NET features like tasks and async / await.

It seems like Unity is trying to get rid of the problem by developing their C# to native compiler. My biggest fear is that this will just make things even more incompatible, or worse, their native implementations exhibit inconsistent behavior with the "reference" implementation (Microsofts).

And why are they doing their native compiler when Microsoft is already working on this very thing. Just seems like they are falling into the same trap.

You basically just summed up why I'm so scared about the direction the Unity team is going, the future of Unity if they continue down that path, and why I have the sinking feeling that I hitched my horse to a sinking ship.

# ? Aug 4, 2014 10:28

Adbot: ADBOT LOVES YOU

# ? May 12, 2024 21:16

darkpool: Aug 4, 2014

Inverness posted:

It seems Unreal Engine 4 already has preview notes for 4.4.

They're just wrecking the competition. One of the advantages Unity had over UE4, 2D support, is a gap being closed by the Paper2D extension.

I've been at a bunch of Unity events this year, once I was at dinner with the management just after the UE4 source announcement and the discussion went something like this.

"Should we care about UE4 source being available?"
"Eh, who gives a poo poo?"

Some of their big partners are getting upset by this attitude too.

I took the engineer test once, and I can tell you without any doubt it's the worst interview test I've ever seen. I'm sure the reason for all the bugs, and that it's taken so long to do simple things like make Mechanim work at all, is they have no idea who they're hiring. The size of their engineering team is insane and the inefficiency is mind-blowing.

# ? Aug 4, 2014 11:20

Jewel: May 2, 2009

They have such simple things like their curve editor not even supporting longer handles making them near-useless. Providing the source would allow the community to easily fix and extend all these things but nah let's just hide everything away so nobody sees just what a mess the codebase is.

Edit: A recent version of unity has a bug where if you don't delete a thumbs.db file it will output an error to the console thousands of times a second. What is the error? "ok". That's it. That's all it says. Good job unity.

# ? Aug 4, 2014 12:22

Wilko: Dec 3, 2013

darkpool posted:

I've been at a bunch of Unity events this year, once I was at dinner with the management just after the UE4 source announcement and the discussion went something like this.

"Should we care about UE4 source being available?"
"Eh, who gives a poo poo?"

Some of their big partners are getting upset by this attitude too.

I took the engineer test once, and I can tell you without any doubt it's the worst interview test I've ever seen. I'm sure the reason for all the bugs, and that it's taken so long to do simple things like make Mechanim work at all, is they have no idea who they're hiring. The size of their engineering team is insane and the inefficiency is mind-blowing.

We had a group of Unity reps come meet everybody at the Melbourne Arcade, and their attitude was pretty much the same too. Their attitudes about the whole thing were that they're counting on people not wanting or caring about source code access, and sticking with Unity because of familiarity instead of switching and learning a new workflow, engine, etc. I hope they pick up their game a bit in the future, because I know a lot of people who would be very happy to be able to fix some of the long standing bugs if they could get source code access.

# ? Aug 4, 2014 12:22

Jo: Jan 24, 2005; Soiled Meat

Inverness posted:

Can you elaborate on what you mean by stuff feeling masked behind a bunch of boilerplate?

Let's take this example. I want to create an item which is visible, has physics, and can be picked up by the player. In Unreal I'd probably subclass Actor, right?

code:

#pragma once

#include "GameFramework/Actor.h"
#include "Pickup.generated.h"

UCLASS()
class APickup : public AActor
{
	GENERATED_UCLASS_BODY()

	/** True when the pickup is able to be picked up, false if something deactivates the pickup. */
	UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = Pickup)
	bool bIsActive;

	/** Simple collision primitive to use as the root component. */
	UPROPERTY(VisibleDefaultsOnly, BlueprintReadOnly, Category = Pickup)
	TSubobjectPtr<USphereComponent> BaseCollisionComponent;

	/** StaticMeshComponent to represent the pickup in the level */
	UPROPERTY(VisibleDefaultsOnly, BlueprintReadOnly, Category = Pickup)
	TSubobjectPtr<UStaticMeshComponent> PickupMesh;

	/** Function to call when the Pickup is collected */
	UFUNCTION(BlueprintNativeEvent)
	void OnPickedUp();
	
};

code:

#include "TutorialCode.h"
#include "Pickup.h"


APickup::APickup(const class FPostConstructInitializeProperties& PCIP)
	: Super(PCIP)
{
	//The pickup is valid when it is created
	bIsActive = true;

	// Create the root SphereComponent to handle the pickup's collision
	BaseCollisionComponent = PCIP.CreateDefaultSubobject<USphereComponent>(this, TEXT("BaseSphereComponent"));

	// Set the SphereComponent as the root component
	RootComponent = BaseCollisionComponent;

	//Create the static mesh component 
	PickupMesh = PCIP.CreateDefaultSubobject<UStaticMeshComponent>(this, TEXT("PickupMesh"));

	//Turn physics on for the static mesh
	PickupMesh->SetSimulatePhysics(true);

	//Attach the StaticMeshComponent to the root component
	PickupMesh->AttachTo(RootComponent);

}

void APickup::OnPickedUp_Implementation()
{
	//There is no default behavior for a Pickup when it is picked up.
}

The code above doesn't even actually do the measuring to see if something is picked up. This is just an abstraction. I still have to do a raycast to check if it's picked up.

The Unity code would be something on these lines. (I'm writing off the top of my head so there may be some compilation errors.)

code:

using UnityEngine;
using System.Collections;

public class PickupHandler : MonoBehaviour {
	public float pickupDistance;
	private bool pickedUp = false;
	private Transform playerTransform;

	void Start () {
		player = GameObject.getObjectsWithTag("Player");
	}
	
	void Update() {
		float dist = (playerTransform.position - this.transform.position).magnitude;
		if(dist < pickupDistance && !pickedUp) {
			pickedUp = true;
			SendMessage("PickedUp");
		}
	}
}

code:

using UnityEngine;
using System.Collections;

public class PickupObject : MonoBehaviour {
	void PickedUp() {
	}
}

# ? Aug 4, 2014 12:51

darkpool: Aug 4, 2014

Jewel posted:

They have such simple things like their curve editor not even supporting longer handles making them near-useless. Providing the source would allow the community to easily fix and extend all these things but nah let's just hide everything away so nobody sees just what a mess the codebase is.

Edit: A recent version of unity has a bug where if you don't delete a thumbs.db file it will output an error to the console thousands of times a second. What is the error? "ok". That's it. That's all it says. Good job unity.

Wilko posted:

We had a group of Unity reps come meet everybody at the Melbourne Arcade, and their attitude was pretty much the same too. Their attitudes about the whole thing were that they're counting on people not wanting or caring about source code access, and sticking with Unity because of familiarity instead of switching and learning a new workflow, engine, etc. I hope they pick up their game a bit in the future, because I know a lot of people who would be very happy to be able to fix some of the long standing bugs if they could get source code access.

Coming from experience, it's very unlikely you would want to see the source code. They price access to it extremely highly because otherwise they're unable to support it. I worked for a while trying to provide a Unity alternative with manageable and affordable source access, but then UE4 took everybody by surprise, among other things.

With all this said, I use Unity instead of UE4 at home, I'm still a bit burned on using UE3 from source even though I'm sure it's a million times better.

# ? Aug 4, 2014 13:50

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

UE4's "flappy chicken" demo appears to be 28MB on Android. As some kind of person from medieval times this makes me sad - you could totally have played a game like that on a machine with 16K. Even allowing for higher resolution graphics and a reasonable amount of bullshit 3D interface wrangling surely we shouldn't be excusing this "everyone has infinite everything" approach to modern software development. We'll never get nice things if we keep making the same old poo poo take up the full hundreds-of-times expanded capacity of our computer-machines. Get off my lawn.

# ? Aug 4, 2014 14:07

Jo: Jan 24, 2005; Soiled Meat

roomforthetuna posted:

UE4's "flappy chicken" demo appears to be 28MB on Android. As some kind of person from medieval times this makes me sad - you could totally have played a game like that on a machine with 16K. Even allowing for higher resolution graphics and a reasonable amount of bullshit 3D interface wrangling surely we shouldn't be excusing this "everyone has infinite everything" approach to modern software development. We'll never get nice things if we keep making the same old poo poo take up the full hundreds-of-times expanded capacity of our computer-machines. Get off my lawn.

Did you build it yourself? Not that it would make a difference in file size, but I'm curious about how much more difficult (or easier) the process is than Unity.

Jo fucked around with this message at 14:49 on Aug 4, 2014

# ? Aug 4, 2014 14:47

Dirty: Apr 8, 2003; Ceci n'est pas un fabricant de pates

The King of Swag posted:

You basically just summed up why I'm so scared about the direction the Unity team is going, the future of Unity if they continue down that path, and why I have the sinking feeling that I hitched my horse to a sinking ship.

I wouldn't worry too much. At some point, things become obsolete and are replaced by new things. I'm not saying this is happening to Unity, although it will die a slow death if they keep up this current pace. UE4 won't be pushing out big updates on a monthly basis forever. People leave, priorities change, markets shift. Flash developers are a dying breed, and Silverlight devs had the rug pulled from under them. I put quite a bit of time into figuring out XNA, only for it to no longer be supported by Microsoft. It happens.

My attitude is just to use whatever works best at the time (which can include your skill level as well as project requirements). If the future looks bleak, you've still got plenty of time to finish your project(s) and move onto the next thing. I only properly got into Unity last year. I'm glad I did, but I know that in two years I'll consider my alternatives before I start my next project. I may stick with Unity, I may not. At some point, you'll find that knowing two or three engines gives you resilience against one of them "going bad".

Point being, rather than being concerned about hitching your horse to a sinking ship, assume that all ships are sinking at different rates, and keep more horses in reserve.

# ? Aug 4, 2014 15:52

seiken: Feb 7, 2005; hah ha ha

roomforthetuna posted:

UE4's "flappy chicken" demo appears to be 28MB on Android. As some kind of person from medieval times this makes me sad - you could totally have played a game like that on a machine with 16K. Even allowing for higher resolution graphics and a reasonable amount of bullshit 3D interface wrangling surely we shouldn't be excusing this "everyone has infinite everything" approach to modern software development. We'll never get nice things if we keep making the same old poo poo take up the full hundreds-of-times expanded capacity of our computer-machines. Get off my lawn.

You misunderstand the point of computers getting more powerful. It's not so that we can make use of it, it's so that programmers can be lazier.

# ? Aug 4, 2014 16:16

xzzy: Mar 5, 2009

My archive folder is a two decade long trail of unfinished code, every single project targeting a different language or technology that doesn't exist or isn't relevant anymore. Computers are a really fast moving world, you gotta be willing to throw stuff away every couple years and try the new hotness.

# ? Aug 4, 2014 16:16

dupersaurus: Aug 1, 2012; Futurism was an art movement where dudes were all 'CARS ARE COOL AND THE PAST IS FOR CHUMPS. LET'S DRAW SOME CARS.'

In a competition of capability vs barrier to entry, Unity's still and likely will be top dog for awhile. We the regulars are often of a level in which Unity's deficiencies compared to UE4 might start to matter (and even then a lot of us are still using Unity); but to someone coming in new as a "making games sounds fun" person, or even an experienced hobbyist, how likely are you actually going to recommend UE4 over Unity? I can't imagine that's something that's going to change soon or very easily, no matter how much Unity might (a big might) screw things up.

# ? Aug 4, 2014 16:34

poemdexter: Feb 18, 2005; Hooray Indie Games!; College Slice

xzzy posted:

My archive folder is a two decade long trail of unfinished code, every single project targeting a different language or technology that doesn't exist or isn't relevant anymore. Computers are a really fast moving world, you gotta be willing to throw stuff away every couple years and try the new hotness.

Your situation sounds like an extreme outlier. Your projects sound like they are too big or you're working too slow. Even though things change constantly, you should still have time to finish projects in whatever tech you choose in a reasonable amount of time.

# ? Aug 4, 2014 16:36

Yodzilla: Apr 29, 2005; Now who looks even dumber?

Beef Witch

xzzy posted:

My archive folder is a two decade long trail of unfinished code, every single project targeting a different language or technology that doesn't exist or isn't relevant anymore. Computers are a really fast moving world, you gotta be willing to throw stuff away every couple years and try the new hotness.

George Broussard's account spotted.

# ? Aug 4, 2014 16:39

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

roomforthetuna posted:

UE4's "flappy chicken" demo appears to be 28MB on Android. As some kind of person from medieval times this makes me sad - you could totally have played a game like that on a machine with 16K. Even allowing for higher resolution graphics and a reasonable amount of bullshit 3D interface wrangling surely we shouldn't be excusing this "everyone has infinite everything" approach to modern software development. We'll never get nice things if we keep making the same old poo poo take up the full hundreds-of-times expanded capacity of our computer-machines. Get off my lawn.

How many ABIs does it support? It'll likely include multiple (3?) copies for different ARM variants, unless they do the work of splitting it into multiple packages.

# ? Aug 4, 2014 16:44

xgalaxy: Jan 27, 2004; i write code

Unreal executables are notorious for being very large. It is definitely a concern for mobile. Of that 28MB, only 2MB is actual content.
This lists different sizes per platform: https://wiki.unrealengine.com/Tappy_Chicken

xgalaxy fucked around with this message at 16:56 on Aug 4, 2014

# ? Aug 4, 2014 16:54

Shalinor: Jun 10, 2002; _{Can I buy you a rootbeer?}

Dirty posted:

I wouldn't worry too much. At some point, things become obsolete and are replaced by new things. I'm not saying this is happening to Unity, although it will die a slow death if they keep up this current pace. UE4 won't be pushing out big updates on a monthly basis forever. People leave, priorities change, markets shift. Flash developers are a dying breed, and Silverlight devs had the rug pulled from under them. I put quite a bit of time into figuring out XNA, only for it to no longer be supported by Microsoft. It happens.

My attitude is just to use whatever works best at the time (which can include your skill level as well as project requirements). If the future looks bleak, you've still got plenty of time to finish your project(s) and move onto the next thing. I only properly got into Unity last year. I'm glad I did, but I know that in two years I'll consider my alternatives before I start my next project. I may stick with Unity, I may not. At some point, you'll find that knowing two or three engines gives you resilience against one of them "going bad".

Point being, rather than being concerned about hitching your horse to a sinking ship, assume that all ships are sinking at different rates, and keep more horses in reserve.

This is why good engineers are flexible / learn fast. Languages and technologies change constantly, so it's less important that you know a specific language and more that you're able to quickly move between them and continue architecting reliable code. This was less true back in the days where you could conceivably land a job wanting one specific thing (say, C++) and work there for a decade, but... :sigh:

(though even then, those types weren't "engineers", they were "programmers" - and I suppose these days they're all in web coding hell)

Transition points still suck rear end, though. We're still going back and forth on our next project. "A decade of institutional knowledge and experience with C# and Unity workflow and caveats" VS "switching to the hip on-the-rise engine, away from the one that very clearly peaked and is starting its downward spiral."

Shalinor fucked around with this message at 17:03 on Aug 4, 2014

# ? Aug 4, 2014 17:00

xzzy: Mar 5, 2009

poemdexter posted:

Your situation sounds like an extreme outlier. Your projects sound like they are too big or you're working too slow. Even though things change constantly, you should still have time to finish projects in whatever tech you choose in a reasonable amount of time.

I'm a perpetual tinkerer, calling me a developer or anything I work on a "project" would be pretty generous. I just like exploring ideas and move on when I get bored.

The point remains though, the tools are constantly changing.

# ? Aug 4, 2014 17:10

Hughlander: May 11, 2005

Grocer Goodwill posted:

I don't understand the Free Software mindset. I don't see why being able to modify the software that someone else wrote is some fundamental human right, but whatever. The GPL license was designed with a specific goal in mind and it accomplishes it.

The BSD license, though, is just useless. "Yeah, use it how ever you want, just put my name on it somewhere because I am literally a child and need the ego boost." Use just MIT or zlib if you really are only interested in protecting yourself from liability.

I think that the thought goes, modifying something you brought is a fundamental right of purchase. If I buy a house the manufacturer can't tell me not to cut through the wall here to make a new door. If I buy a car the manufacturer can't tell me not to put in an aftermarket sunroof. If I buy a database the manufacturer is telling me I can't use it as an in memory datastore because I can't legally recompile it to do so. It's about the purchaser/end-user, not about the author.

That said, all I release under is MIT, but I understand their point.

# ? Aug 4, 2014 18:28

poemdexter: Feb 18, 2005; Hooray Indie Games!; College Slice

xzzy posted:

I'm a perpetual tinkerer, calling me a developer or anything I work on a "project" would be pretty generous. I just like exploring ideas and move on when I get bored.

The point remains though, the tools are constantly changing.

Ah, one of THOSE people. :v:

Game jams were made for people like you. I also agree that tools are changing constantly. About 13 months ago I was doing XNA and now I'm on Unity wondering if I should start to look at other platforms or try to hold on to this.

# ? Aug 4, 2014 19:25

Shalinor: Jun 10, 2002; _{Can I buy you a rootbeer?}

poemdexter posted:

Ah, one of THOSE people. Game jams were made for people like you. I also agree that tools are changing constantly. About 13 months ago I was doing XNA and now I'm on Unity wondering if I should start to look at other platforms or try to hold on to this.

Switch. Staying with Unity at this point is really only a good idea if you're a hobbyist, or you've got too much work in it to just abandon. The games you make are the ideal little short-sprint ones that aren't too bad to change engines while making, and then you'd be enshrined somewhere (UE4) with a not-horribly trajectory.

(EDIT: we're stuck with Unity unless HTR / other game are successful enough that we can take an extra 6 months of lead time on our next project, to cover all the transition time there always is... going Unity was still the right plan, just, tech cycles)

Shalinor fucked around with this message at 19:39 on Aug 4, 2014

# ? Aug 4, 2014 19:28

poemdexter: Feb 18, 2005; Hooray Indie Games!; College Slice

Shalinor posted:

Switch. Staying with Unity at this point is really only a good idea if you're a hobbyist, or you've got too much work in it to just abandon. The games you make are the ideal little short-sprint ones that aren't too bad to change engines while making, and then you'd be enshrined somewhere (UE4) with a not-horribly trajectory.

You say this, but I just started a long term 2D project targeting the XBox. I think I'm stuck on Unity until I'm done with this. (Also I got a free ticket to Unite 2014 so I should at least hold on until end of August)

# ? Aug 4, 2014 19:31

Stick100: Mar 18, 2003

Shalinor posted:

Transition points still suck rear end, though. We're still going back and forth on our next project. "A decade of institutional knowledge and experience with C# and Unity workflow and caveats" VS "switching to the hip on-the-rise engine, away from the one that very clearly peaked and is starting its downward spiral."

I'm not sure Unity has clearly peaked. In Unity 5 they are introducing most of the advantages that UE4 has (reflections, real time lighting). The real question is how good is it, how buggy and if they are going to stick with closed source + $1500 as the only price point.

All indications are that it will stay janky with closed source at that pretty expensive price point. I'm really hoping they either annouce a pivot or get enough of an earful at Unite to start talking about it.

UE4 is just crushing currently (every single week they have a new integration). FYI now twitch streaming is just built it to both any game you build and into the actual IDE/Editor. Yup didn't even bother talking about it because hey, that's not big news. Unity won't have that for years.

Oh and speed tree will just be built in + extremely affordable in a couple weeks. I think unity might have that in a couple of months/ then not be buggy in a year. I didn't catch the live stream but apparently they also made a deal with Miximo to get a bunch of Miximo stuff built-in/free but I didn't watch the livestream.

ARGH com'on Unity open the source and give us a 5-10% option please!

# ? Aug 4, 2014 21:08

Shalinor: Jun 10, 2002; _{Can I buy you a rootbeer?}

Stick100 posted:

I'm not sure Unity has clearly peaked. In Unity 5 they are introducing most of the advantages that UE4 has (reflections, real time lighting). The real question is how good is it, how buggy and if they are going to stick with closed source + $1500 as the only price point.

Those aren't the advantaged of UE4. That's "Unity finally catching up with everyone else." UE4's advantages are source access, a toolset that scales well with team size, data storage structures that don't explode at the drop of a hat, an extensible toolset that works consistently and is powerful to boot, etc.

... which is why I'd say they've peaked. They're trumpeting "WE CAUGHT UP!" as their selling point with U5. There is SO much other crap they would have to do to actually be competitive, like fix all their half-baked systems that they sold 4.X on the back of, which they seem to have zero interest in doing.

# ? Aug 4, 2014 21:58

SuicideSnowman: Jul 26, 2003

Stick100 posted:

UE4 is just crushing currently (every single week they have a new integration). FYI now twitch streaming is just built it to both any game you build and into the actual IDE/Editor. Yup didn't even bother talking about it because hey, that's not big news. Unity won't have that for years.

They did mention it. It was just in a little tiny one line fix, "oh hey we did this" type of thing.

quote:

Oh and speed tree will just be built in + extremely affordable in a couple weeks. I think unity might have that in a couple of months/ then not be buggy in a year. I didn't catch the live stream but apparently they also made a deal with Miximo to get a bunch of Miximo stuff built-in/free but I didn't watch the livestream.

Speedtree is already there for UE4. You pay $20 a month for the modeler. If you cancel you'll no longer be able to use the modeler but you can still use the assets you've created.

# ? Aug 4, 2014 22:37

FuzzySlippers: Feb 6, 2009

Unity devs hedge on whether a lot of features are 5.0 or 5.x so I'm expecting like 4.x half the features will be strung out over the cycle and many won't be usable till later. The point release thread is good but they've also been silently breaking things in it too. Unity also seems to be in one of those "fix things with acquisitions!" head spaces which I tend to think is a bad sign. It didn't turn out well with mecanim.

U5 does mean that it won't look embarrassing next to UE4 without a butt ton of finicky asset store plugins at least.

# ? Aug 4, 2014 22:57

Inverness: Feb 4, 2009; Fully configurable personal assistant.

xgalaxy posted:

This is exactly the thing I'm battling now with my posts in another thread regarding SeviceStack. The stock library functions fine under Xamarin.iOS and Xamarin.Android but didn't work on Unity. Luckily this particular library was really easy to port. However, other libraries which utilize .NET 4+ that work perfectly fine on Xamarin are not portable to Unity without tremendous amounts of effort, especially if they make heavy use of new .NET features like tasks and async / await.

It seems like Unity is trying to get rid of the problem by developing their C# to native compiler. My biggest fear is that this will just make things even more incompatible, or worse, their native implementations exhibit inconsistent behavior with the "reference" implementation (Microsofts).

And why are they doing their native compiler when Microsoft is already working on this very thing. Just seems like they are falling into the same trap.

I forgot about their C# to native compiler, or I probably would have mentioned that too. Of all the dumb things to do. :bang:

There's a point where it would just be better to clean up the source and make it, or at least an API available.

If they have the resources to sink into making a C# to native compiler or maintaining their own version of Mono they should drat well have the resources to pay up for the latest Mono version.

darkpool posted:

I've been at a bunch of Unity events this year, once I was at dinner with the management just after the UE4 source announcement and the discussion went something like this.

"Should we care about UE4 source being available?"
"Eh, who gives a poo poo?"

Some of their big partners are getting upset by this attitude too.

Maybe they don't realize that companies would pay Epic six digits for access to the full UE3 source. Getting UE4 source code for $20 is an incredible benefit.

You don't really need anymore evidence than this that Unity is on a downslide that will require a management change to get off of their asses.

Jo posted:

Let's take this example. I want to create an item which is visible, has physics, and can be picked up by the player. In Unreal I'd probably subclass Actor, right?

*snip*

You shouldn't need to do a raycast to check if its picked up, just check for an overlap collision with the sphere or whatever you're using. I don't remember how UE4 handles physics events so I can't recommend anything there. You wouldn't hold a reference to the player either, just give the item to whatever pawn collided with APickup.

Your unity example has you holding a permanent and then checking the distance between the player and the pickup for each pickup while ignoring any possible collision volume or mesh. Yet your UE4 example is doing it more properly by creating a sphere for collision and specifying the static mesh for the visual aspect. The two examples really aren't showing the same thing.

You're right that you have more code to implement that, but then C++ is more verbose and UE4 more powerful. It would only be something you'd need to implement once really before reusing the class.

roomforthetuna posted:

UE4's "flappy chicken" demo appears to be 28MB on Android. As some kind of person from medieval times this makes me sad - you could totally have played a game like that on a machine with 16K. Even allowing for higher resolution graphics and a reasonable amount of bullshit 3D interface wrangling surely we shouldn't be excusing this "everyone has infinite everything" approach to modern software development. We'll never get nice things if we keep making the same old poo poo take up the full hundreds-of-times expanded capacity of our computer-machines. Get off my lawn.

UE4's engine module is a beast. It's not surprising that they can't just strip all of that out. Flappy Chicken is also actually rendered in 3D with 2D sprites being shown and hidden based on blueprint code I'm not sure how much overhead that would include compared to something like Paper2D.

Edit:

dupersaurus posted:

In a competition of capability vs barrier to entry, Unity's still and likely will be top dog for awhile. We the regulars are often of a level in which Unity's deficiencies compared to UE4 might start to matter (and even then a lot of us are still using Unity); but to someone coming in new as a "making games sounds fun" person, or even an experienced hobbyist, how likely are you actually going to recommend UE4 over Unity? I can't imagine that's something that's going to change soon or very easily, no matter how much Unity might (a big might) screw things up.

That's true. Though I have to say, UE4's editor is a tremendous improvement over UE3's. It reminded me of Unity's when I first opened it. The blueprints feature is going a long way in making programming easier too by allowing people to avoid C++ entirely in many cases.

I haven't used Unity myself so I can't really make a real comparison.

Inverness fucked around with this message at 23:10 on Aug 4, 2014

# ? Aug 4, 2014 23:06

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

I've been getting the "maintenance mode" error page at https://www.unrealengine.com/register for the past day or so, don't see anything in their Twitters about it. Is there another way to sign up?

# ? Aug 4, 2014 23:58

Shalinor: Jun 10, 2002; _{Can I buy you a rootbeer?}

Inverness posted:

That's true. Though I have to say, UE4's editor is a tremendous improvement over UE3's. It reminded me of Unity's when I first opened it. The blueprints feature is going a long way in making programming easier too by allowing people to avoid C++ entirely in many cases.

I kind of take it for granted, since it's Epic, but I assume the Blueprints are extensible with totally custom (C++) nodes?

Also, did it fix the issue Kismet had, where it was difficult to make a single Kismet script, and associate it with an object that's instanced over your entire world without that thing's Kismet hierarchy appearing a billion times in a billion places? Think level design widgets: a single "bulb + switch" or "torch lamp" or "door that opens when clicked" that gets re-used in a billion places, instead of everything being bespoke.

# ? Aug 5, 2014 00:28

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

It would be weird if Kismet didn't have that. I've never actually worked with Kismet, but all the other important visual code systems I've seen had that. In the systems I've used, it was known as "PCB mode", where you could define your own internal components built out of yet more components, and then stamp those PCBs out across the board. In fact, it was invisible to the rest of the system: once your PCB got so complex, you could just sit down and replace the PCB with a hand-written C++ node and the rest of the system didn't care at all, as long as it had the same inputs and outputs.

So you have your lamp model, attach the "secret switch on a timer" PCB to the side of it, and then wire it together so that when all four secret switches are active and haven't timed out, a door opens, and that's done with level-global behavior for wiring.

# ? Aug 5, 2014 00:51

Shalinor: Jun 10, 2002; _{Can I buy you a rootbeer?}

Suspicious Dish posted:

It would be weird if Kismet didn't have that. I've never actually worked with Kismet, but all the other important visual code systems I've seen had that. In the systems I've used, it was known as "PCB mode", where you could define your own internal components built out of yet more components, and then stamp those PCBs out across the board. In fact, it was invisible to the rest of the system: once your PCB got so complex, you could just sit down and replace the PCB with a hand-written C++ node and the rest of the system didn't care at all, as long as it had the same inputs and outputs.

So you have your lamp model, attach the "secret switch on a timer" PCB to the side of it, and then wire it together so that when all four secret switches are active and haven't timed out, a door opens, and that's done with level-global behavior for wiring.

Oh, sorry, yeah - Kismet had that. It absolutely had custom nodes. The "does Blueprint have this" was more to the way you associated script with objects. To be fair, it MAY have be something that Kismet was actually capable of, and I just wasn't doing it right... but I wasn't happy with what I saw / how it worked. I vaguely remember it polluted a sort of global script space with tons of copies, or something. And given how old Kismet was by that point, it may have just been that janky.

Regardless, I'd assume that Blueprint, being a total overhaul, doesn't have those problems at all.

EDIT: I ask because, you know what node-based visual system DOESN'T have custom nodes? Unity MecAnim.

Shalinor fucked around with this message at 01:09 on Aug 5, 2014

# ? Aug 5, 2014 01:06

BabelFish: Jul 20, 2013; Fallen Rib

Shalinor posted:

I kind of take it for granted, since it's Epic, but I assume the Blueprints are extensible with totally custom (C++) nodes?

You can create a blueprint out of pretty much any C++ UCLASS, it's almost like a derived class with it's own interface. It's pretty awesome, not sure if that's what you mean by custom nodes though.

# ? Aug 5, 2014 01:11

Above Our Own: Jun 24, 2009; by Shine

Is UE4 primarily component or inheritance based?

# ? Aug 5, 2014 01:25

Bizarro Buddha: Feb 11, 2007

Shalinor posted:

I kind of take it for granted, since it's Epic, but I assume the Blueprints are extensible with totally custom (C++) nodes?

Also, did it fix the issue Kismet had, where it was difficult to make a single Kismet script, and associate it with an object that's instanced over your entire world without that thing's Kismet hierarchy appearing a billion times in a billion places? Think level design widgets: a single "bulb + switch" or "torch lamp" or "door that opens when clicked" that gets re-used in a billion places, instead of everything being bespoke.

Kismet used to be levels only, blueprint is everything. So you can put blueprint code in a content-only actor class and put instances all over your levels dead easily. Way better than UE3 prefabs. I've even heard of studios completely ignoring level scripting and doing it all with actor blueprints to tie triggers to logic and so on.

As far as custom blueprint nodes - there's two ways you can do things. You can tag any C++ function as callable or implementable in blueprint, and you can put multicast delegate properties on objects that can be registered by blueprints. You can also write extensions to the blueprint compiler that let you place a node in the editor that expands into whatever code you need. This is also how you do things like the old "latent execution" nodes from Kismet. For example a single blueprint node that has an immediate output and another output that fires when a long process has finished. The second way is a quite a bit more involved and I haven't gone through the process myself, but I know we're using it at work.

Above Our Own posted:

Is UE4 primarily component or inheritance based?

I would say primary inheritance even though they have an attempt at a component model. It's not a very coherent attempt and trying to work in a component-focused mentality will give you a lot of pain in my opinion.

This matters less, but performance-wise they are also not set up for a great many components to be used.

Bizarro Buddha fucked around with this message at 01:29 on Aug 5, 2014

# ? Aug 5, 2014 01:27

SuicideSnowman: Jul 26, 2003

https://www.youtube.com/watch?v=rxM6QVwrzBg

This guy designed his entire "prototype" with blueprints. It's pretty crazy what he accomplished. Day/night system, inventory, weather.

# ? Aug 5, 2014 01:31

BabelFish: Jul 20, 2013; Fallen Rib

Above Our Own posted:

Is UE4 primarily component or inheritance based?

It's mostly inheritance, with some component. Most of the logic is inheritance based, PlayerController and AIController inherit from Controller for example. Actors however have a component bucket.

BabelFish fucked around with this message at 01:38 on Aug 5, 2014

# ? Aug 5, 2014 01:35

Jo: Jan 24, 2005; Soiled Meat

Inverness posted:

You shouldn't need to do a raycast to check if its picked up, just check for an overlap collision with the sphere or whatever you're using. I don't remember how UE4 handles physics events so I can't recommend anything there. You wouldn't hold a reference to the player either, just give the item to whatever pawn collided with APickup.

I don't think I'm storing a reference to the player in the Unreal code, am I? I _am_ in the Unity code because it makes it faster to check the transform. In the UE code, if I gave the item to whatever pawn collided with APickup, is there a chance a non-player character could pickup the item, or are the pawns solely players?

As for the raycast, you're right. I shouldn't have said that. I do still have work to do on that code, though. It's not "complete" in the sense that I haven't overridden any collision overlap function or implemented the check to see if someone's inside.

Inverness posted:

Your unity example has you holding a permanent and then checking the distance between the player and the pickup for each pickup while ignoring any possible collision volume or mesh. Yet your UE4 example is doing it more properly by creating a sphere for collision and specifying the static mesh for the visual aspect.

The Unity example is checking to see if the distance from the player is less than the pickup threshold, yes. I get that it means the player could theoretically pick up an item through a wall, but that fix is a raycast away. Wouldn't a sphere collider in the Unreal example also have the same problem of picking up things through walls? Why is a sphere collision 'more correct' than checking the distance?

Inverness posted:

The two examples really aren't showing the same thing.

You're right that you have more code to implement that, but then C++ is more verbose and UE4 more powerful. It would only be something you'd need to implement once really before reusing the class.

I think it's not an unfair comparison. I'm showing what it takes to have an object which is visible, has physics, and can be picked up (or have a pickup function be called) in Unity and in Unreal. The means by which they need to have this done are different, yes, but I think it qualifies well my argument that Unreal has more 'boilerplate' code to get things going. I can't just make a component and attach it to an object. I need to either make a new object, subclass an object (maybe rework my hierarchy), or fiddle with Unreal's component system (which I haven't tried yet). It's not so much that C++ is more verbose than C# (it is, but that's not really why the example is longer), it's because when I make an object in Unreal I need to define my Mesh object, my collision primitive, set the possibly overridable OnPickup function, and do all sorts of other things rather than add another behavior onto an object which has all these. The difference in length stems from (I'd estimate) 50% component versus inheritance and 50% C++ vs C#.

But that was my point, right? It takes longer to do stuff in Unreal because you have to write more.

# ? Aug 5, 2014 02:15

Above Our Own: Jun 24, 2009; by Shine

Using C++ instead of C# is a big turn off for me. I haven't touched C++ in years, so maybe I'm wrong, but I really don't like to imagine going back. Verbose code is demoralizing for me to work in. I also really enjoy component systems, so I think I'll wait out Unity 5.

# ? Aug 5, 2014 02:44

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

I can handle C++'s verbosity, but programming errors crashing the application really sucks.

# ? Aug 5, 2014 03:07

Adbot: ADBOT LOVES YOU

# ? May 12, 2024 21:16

Jo: Jan 24, 2005; Soiled Meat

OneEightHundred posted:

I can handle C++'s verbosity, but programming errors crashing the application really sucks.

Or just slowly bleeding memory and performance.

# ? Aug 5, 2014 03:24

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Game Development Megathread

«‹›622 »