Unity Plus Target Audience?

Nothing official. I've seen some of the current developers make mention of their own games from time to time, but those are titles they work on themselves during their spare time. About the only official title is GooBall but that was back when the development team was very small.

 

Aren't we all restating each other since thursday?

 

I was asking thatn because I heard blittzBasic creator had many games under his belt, and one feature had amazed me in blitz3D is the input features, notably that, when I did a crappy 3D platformer, control where super responsive, and this is was due to the engine buffering inputs, so even though I push the key three frames ago and it had three frame to test the input, it still remember I pushed the key and jump as soon as it touch ground ... Of course you can pevent that with flushkey()

Anybody who has made a decent platformer know the problem of hitting keys just before the frame where collision happen, the character seems unresponsive because the input was forgotten. So the fact he made that a default in the engine is mindblowing to me, he made gameplay the default instead of generic implementation! Before I even knew it was the right implementation!

Meanwhile Unity engine has delay as default in their horrible input mapping, has control gathered in Update() while the physics run on the faster FixedUpdate() and people had to discover a hack where they pool inputs on Ongui(). Every step introduce a complexity that run counter to game design . They did win with component design though.

Too bad blitz3D is stuck in old school: directx7, no multithread, etc ...

 

Source is available for it now under a permissive license. I wouldn't be surprised if someone eventually updated it.

https://github.com/blitz-research/blitz3d

 

There's some lovely bits of code in there too if anyone wants to nick bits and bobs.

 

Well I'm a non coder and c++ is scary, though the bit shared to me early was beautiful for me

edit

"->" this I don't know exactly what it mean, I think it's pointer related?

 

Remember Mark Sibly is still actively developing. He went on to make Blitz Max (which people have and are developing Indie games in that are on Steam) then Monkey X and now working on Monkey X 2. Monkey X is a nice language. Kind of reminds me of Blitz in some ways (some of the method names for the graphics and so forth are the same) but this is fully object-oriented and multi-platform.

 

Since I'm bored, lets start the semantics argument

Was GooBall really made in Unity? My understanding is that Unity was developed in an attempt to recover some of the work that went into GooBall. So Unity as a distinct engine probably didn't exist at the time Goo Ball was created.

I could of course be wrong. I'm not really up to speed with much that happened in 2005, I was busy off knocking on doors as a minister of religion. I didn't even notice FaceBook happening. Let alone the beginnings of Unity.

 

Yep, it's member access via a pointer.

From what I remember of the story they'd still deliberately made a distinction between their tools development and their game development. Paraphrased and probably warped by time, I remember it being something like "Our game wasn't that good, but our tools were great."

 

Yes, it's the operator used to access a member of a pointer. Imagine you have a struct like the following.

Code (csharp):

1. struct foo
2. {
3.     int x;
4. };

If you declared it like you normally would in C# you would access the members with the dot operator.

Code (csharp):

1. struct foo var;
2.  
3. var.x = 5;

If you declared it as a pointer you would use the arrow operator.

Code (csharp):

1. struct foo* var;
2.  
3. var->x = 5;

 

Thanks, it clarify it!

 

But I'm not that bored yet!

 

Yeah, I used to love Blitz3D. Hacked together some cool stuff back then.

In any case, I too am confused about the new pricing model. I thought maybe the $35 tier would be a little more useful, for example removing splash screen but having a lower revenue cap or something. Right now it's totally useless unless you really can't stand the light skin. I would have even been OK with subscription only (no free tier) if it meant the removal of the splash screen altogether. I mean, I pay $30 per month for Maya LT and I don't even use it all the time. But it's a fair price and I feel it's worthwhile. I have no problem paying $35/mo for something worthwhile. The Pro tier is not that.

And really, is Unity generating any substantial business from the inclusion of the splash screen? I mean, every single game developer worth anything has heard of Unity before and knows what it can do. No one either in the industry or any aspiring game developer has never heard of Unity before. Plus, most of the best quality and bigger budget Unity titles buy Pro, so they are really only advertising Unity for low-budget or lesser quality games. The whole model makes no sense, unless their only point is to piss off existing customers.

 

You know this discussion made me think of Torque. A quick check on Wikipedia through the pages related to their company, their game (Tribes 2), and the engine show that the engine came out a year before the game. Seems Unity may be alone in developing nothing but tech demos with their engine.

 

Based on the feedback I get from my few assets on the store there are a lot on non coders using Unity and are scared to death of C++ on Unreal as the reason for sticking with Unity.

I don't get it though as Unreal's Blueprint system is a graphical way to program and I would have though suit the beginner better.

Oh Unreal have just released a Blueprint to C++ add-on to the engine. It's beta at the moment but this clinches it for me now as Blueprints can be arranged to look like Unity components and now are super speedy.

 

From what I've heard it has been available for a while in some preview state. It's apparently very effective depending on how heavily you use Blueprint. One example is the Infinite Voxel demo someone made to see how difficult it would be to build a Minecraft-style game in Unreal. Using the BP->C++ converter resulted in a "more than 1200%" boost.

https://forums.unrealengine.com/sho...-an-Infinite-Voxel-World-similar-to-Minecraft

 

@arkon
Nah the myth that spaghetti interface is easier to read or manage is just a myth and placebo.

I'm scare of C++ because I have no solid reference, I tried many time, there is just something that don't gel, it's close to c# but for some reason harder to read or guess, I don't know why. Also stuff like c# tend to arrive in higher level IDE like in unity, so a lot of the actual work is already done. It's really just about the hi level environment!

For example RPG maker hide complexity through interfaces, but the gist of it is still typed variables arrange in sequence. It's the same basic logic, instead of typing the name of the function with auto complete, you look for it in a list of button, click the button, which open a windows that allow to fill the parameter field (after selecting the proper overloaded of the function!), then translate it into a line of text with proper syntax.

I think this logic can apply to any language, what if the annoying list of class member in any decent ide, I could click that member, fill the parameter and it put down the code like in rpg maker? What if declaring a function wasn't put one after another (their order don't matter) in a text file but was a floating windows you access by double clicking the useless member list (instead of being a poor man's shortcut or eavedrop).

Basically the useless member list would be less useless, if it was like the windows task bar where functions and class definition "dock", that you would open when needed. The title bar would have editable identifier and a readable field that spell thing humanely instead of the strange hungarian mismatch we have, you would select the type in the proper field and the the body of the windows dedicated to the actual code.

The windows can be minimize to a single floating summary for class (to eavedrop members) and to a flying bar for function, you would drag and drop them in the main body windows to enter an expression with a prompt to fill the parameters. Variable would have their own dock in the windows, and you could drag and drop them into function's parameter field. You wouldn't have to code linearly and have syntax errors, but have flying snapable box where you can have a look at, changing a function or variable name auto update everywhere.

It would detect loop immediately and change the windows color or something to signal recursive function. Since the function are on a list you would have shortcut based on their index to recall them instantly, which would be faster than auto complete. It would be easier to debug because you can just put a windows to eavedrop a function body to verify a bit of code where it is used at the same time, no need to frantically scroll up and down, split file and ide screen to look a function behavior to see if there is bug.

Code have strong syntax, it's possible to parse them and generate this interface and reverse generate the usual way, no change needed! It's time to bring code from MSDOS (C/PM for the geek) to WINDOWS.

 

A few things immediately jump to my mind:
- Many more subtleties in the syntax, that you need to understand to use the language effectively.
- The syntax is often more verbose. You need to read more stuff to understand the same amount of functionality.
- The language expects you to understand how memory works and, to some degree, even how compilers work.

For some tasks those things are benefits. For others they just get in the way.

That said, I strongly believe in learning C++ (or another language where the above points apply) if you want to be a really good programmer. Not because of the additional challenge (I don't believe in making things harder than they have to be) but because it makes you really understand two things:
- What happens to the text you write so that it can become instructions your CPU executes.
- Specifically what those instructions make your CPU, RAM, etc. do.

 

How stack and heap work should be mandatory learning for any developer but it boggles my mind how many skip it. It's not even hard compared to a million other things you have to learn in programming(I found closures much harder to wrap my head around than stack/heap/memory allocations)...just takes a little bit of analytical thinking and a decent teacher/reference.

 

I dunno. A lot of the hard comp sci stuff is interesting. But its not overly essential. That's why we have frame work developers and engine builders and the like. Very good specialists can worry about these things, so I can focus on aspects that actually matter to my game.

One of the great things I like about Unity and C# is it lets me keep most of my stuff high level. Most of the time it really doesn't matter to my game if variables are allocated on the heap or the stack, or if they are sent via a smoke signal to Mars where little elves with pointy hats engrave them on stone tablets. All I need to know is how to put a number in, and get a number out.

 

The thing is that many people think this...

... and then end up doing this...

... and then wondering why things are slow.

You're right, most specific details don't matter to most specific games. But a generally solid understanding of the fundamentals of computing is applicable to development in general. You will need some of those details at some times, and if you don't know them in advance you'll never know when they could be of use.

 

Granted, information is useful. The real question is exactly where does the line lie between the game dev and the specialist? Especially when you consider the opportunity cost of acquiring information.

I think about driving a car to work. I definitely need to know how to operate the steering wheel, and what the pedals do. Knowing that I need to put fuel in it when the light comes on is a good thing. I should probably know that the car needs an oil change every six months and how to change a flat tyre. But do I really need to know how a fuel injection system works? Or what type of spark plugs my car has? If I need any of those things I contact a mechanic whose job it is to be a specialist in cars.

With Unity and memory management its much the same. I need to know how to store a variable and get a number back. I need to know the difference between pass by value and pass by reference. I need to understand scope. I should probably know about the garbage collector, and how to avoid unneeded allocations. Knowing if a variable is allocated on the heap or the stack is starting to get less useful. And knowing how to optimise the layout of data in memory to avoid CPU cache flushes is probably unneeded.

Of course all of this is really context sensitive. It depends a lot on what you want to do with the engine. I bet you somewhere out there someone is horrified I drive a car without the slightest clue what 'electronically fuel injected' means.

 

This is where knowing how to look up the answer is pretty close to being good enough. Whether or not you'll actually understand it when you get it is another matter (read the Wikipedia entry for 'electronic fuel injection' for an example).

 

Typically its not the history section of a Wikipedia page .

 

Sure, but it's intrinsically related to a bunch of the stuff you just said is useful.

Like I said, most specific bits of knowledge are indeed not relevant to most specific cases. But I've done plenty of work where understanding the fundamentals has made a huge difference, including doing some things that others claimed couldn't be done.

Well, to me a game dev is a specialist, though I guess you're right in that that's getting less true as time goes on, and as it gets easier to make games without caring about the low level stuff.

 

A game dev is a specialist. But I think we are moving into a period where the game dev specialist is not a programming specialist. At least not at the low level.

 

For example, did you know that, if you dismember long lines of math:

a = b + (c * d / (Mathf.Sin(e));

into two operand lines:

a = c * d;
temp = Mathf.Sin(e);
a = a / temp;
a = a + b;

you get a good amount of performance in medium to heavy computation? I learned that on an AMD whitepaper, which is very technical and specific.

I agree with you, the great thing about Unity and C# is that you just put a number there and the number goes (I love that), but there's a moment where the software will choke, slow down, crash and all sorts of things. That's when it's a good idea to understand low-level.