Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An Unreal Decision

martiancraft.com

Post reply on HN
Print view View original

91–100 of 105 posts

Re: An Unreal Decision

#91

Post by LeftSideDrive »

mrfusion wrote: post #73
LeftSideDrive wrote: post #37

Earlier quoted context omitted.

I make 3d models for games. In fact, I make 3d models for the game in the OP at MartianCraft. There's a vibrant community of game and 3d artists supporting eachother, giving out free assets, free help, free advice, tutorials ETC. I take issue with your broad assertion that artists don't support free culture. When it comes to assets, it's tough to put together a library of free, or even purchased ones, because the sty…

Thanks for the detailed writeup of your experiences. What would you say would be different for a hobbyiest just learning 3D game development? Would free assets be more viable if you don't need a professional, polished look? Could you still get a playable game?

Ehhh, it's tough. What happens when you need a vertex moved or a poly count reduced? Visual assets really impact game performance in a way that requires bespoke work on almost everything. It doesnt help that the number of free game-ready assets out there is basically 0

Re: An Unreal Decision

#93

Post by dragonwriter »

sillysaurus3 wrote: post #32
the_af wrote: post #30

Earlier quoted context omitted.

> The lack of static typing, for example, allows a REPL Uh? Languages with static typing can have REPLs. See: Scala, Haskell and more. I don't think that is what makes JS an option for game development, but rather its ubiquity in browsers. If you remove that, I don't see why you would choose it for serious development.

Why does Haskell have a REPL but not Go?

> Why does Haskell have a REPL but not Go?

Because no one's bothered to create a REPL for Go.

Re: An Unreal Decision

#94

Post by jonasechterhoff »

malkia wrote: post #86
sorbits wrote: post #82

Earlier quoted context omitted.

On OS X switching from 32 to 64 bit also means no longer being able to use many Carbon APIs. I would imagine that cross platform software is more likely to use the Carbon APIs because they are procedural and often a bit more low-level than the “modern” Cocoa equivalents.

From what I've seen, I think Unity draws the UI non-natively, using it's own UI system, but I could be wrong. I'm basing this simply on the fact that it looks exactly the same on OSX/Windows. I actually like their UI quite a lot (as a programmer), and love the fact that the Editor can be extended while it's working.

Correct - we draw all the UI ourselves. Yet, we did indeed have a lot of dependencies on Carbon APIs for all sorts of different things like handling rendering into windows or fullscreen contexts, getting images from WebCams, input, etc. We had to rewrite quite a bit of that code to move to 64-bit. A problem with that is that often the replacement APIs have only been introduced in more recent OS X versions (which have always been trying to keep long backward compatibility with old systems), which means that in several places we had a choice of maintaining two separate code paths or dropping functionality in 32-bit. Or releasing 64-bit versions later when we could safely drop backwards compatibility with old OS X versions. This was not the biggest reason for us to take long to support 64-bit, but it was one.

Re: An Unreal Decision

#95

Post by _random_ »

christoph wrote: post #33
keerthiko wrote: post #29

My teammate and I started moonlighting on the first game for our studio about 8 months ago, right before Epic announced the current $19.95/seat pricing model. We decided to go with Unity purely because I already owned a Pro license, that we could use to make final beta builds and be responsible for the advanced visual effects that needed Pro. Additionally I already had lots of experience with Unity, and nearly none w…

You highlight one of Unity's real strengths here that is often forgotten - the asset store. Want to drop in a nice city scene? Thats 10 bucks. Want realistic car physics? That's 10 bucks. A few nice NPC's with rigged faces? Thats 20 bucks. A pack of nice shaders? 10 bucks. I don't think Unity is targeting AAA developers at all. Its targeting small studios that want to get ideas built quickly. It's got great, simple O…

Then people publish whiny posts on how tough the mobile game market is and how nobody notices their game (which is a bunch of scripts tying together pre-made components and assets).

Re: An Unreal Decision

#96

Post by TMichael »

exDM69 wrote: post #69
ivanca wrote: post #44

Earlier quoted context omitted.

Absolutely false, using imported materials and creating your own is extremely easy to do in Unreal, and there are tons online of stores where you can buy 3D models, Unreal integrates pretty well with all kinds of 3D models (including riggs) specially those from Autodesk Maya. And over top of that there is an Asset Store for Unreal, is called the Marketplace and the EPIC team is filling it itself with tons of free hig…

Yes but the point in OP and GP is that the amount of content available in the Unity store is greater than other stores. Sure Unreal has the same goodness but there just isn't as much stuff readily available in the Store you can just pick up and use. So it's a content issue, not a technical issue with the engine itself.

@christoph:

As the article's author pointed out, you don't need many of those addons in UE4 because the functionality is ALREADY built into the engine.

Want realistic car physics? Already built in! Want great shaders? Already built in! Want rigged faces or a cityscape background? As regular assets, buy them anywhere on the internet (including the Unity asset store), and then put them into UE4!

And this is why one of Unity's strengths is also one of its weaknesses. The reliance on so many third party libraries for basic functionality means that A) integration with the engine isn't always perfect, B) updates and fixes are dependent on the third party author, and C) the UT community is nickeled and dimed for many things which should be included already.

Re: An Unreal Decision

#97

Post by TMichael »

bitpew wrote: post #54
Tepix wrote: post #3

I recently started getting to know Unity3d and it was extremely easy and quick to learn. One annoying discovery was that their variant of JavaScript is not real JavaScript, it's "UnityScript". It took me quite some time to convert a simple script that I had written for node.js to UnityScript. I need the pro version of Unity3d to generate iOS, Android or VR games for the Oculus Rift. For someone who is just doing a bi…

> I need the pro version of Unity3d to generate iOS, Android or VR games for the Oculus Rift Not true anymore. You can generate iOS and Android versions of your game with the free version of Unity3d (although with a reduced featureset in comparison to the pro version).

I think he was referring to the Oculus Rift part. Pro has one feature (is it deferred rendering?) which is requisite for OR development.

Re: An Unreal Decision

#98

Post by maxmem »

vyrotek wrote: post #88
increment_i wrote: post #84

Earlier quoted context omitted.

Indie devs -- particularly one man shops -- should also take note that the hardware requirements to run UE4 are magnitudes higher than what is required to run Unity. I was basically ready to jump ship to UE before I realized this.

I just discovered this for myself this past week. I've been playing with Unity for a while now and just recently decided to give UE4 a try. I couldn't even do a serious evaluation of it on my PC with my current graphics card. I didn't have any problems with Unity at all but with UE4 I could barely open or run the sample projects. Even the blueprint editors were terribly laggy. I purchased a new graphics card and it r…

What are the specs of your system?

Re: An Unreal Decision

#99

Post by pkroll »

sillysaurus3 wrote: post #32
the_af wrote: post #30

Earlier quoted context omitted.

> The lack of static typing, for example, allows a REPL Uh? Languages with static typing can have REPLs. See: Scala, Haskell and more. I don't think that is what makes JS an option for game development, but rather its ubiquity in browsers. If you remove that, I don't see why you would choose it for serious development.

Why does Haskell have a REPL but not Go?

A quick Googling would have shown two REPLs for Go, though they're old and haven't been updated in a long time. I'm guessing the Go playground and "go run file.go" compiling and running so quickly, make it not a real concern.

Re: An Unreal Decision

#100

Post by scott_karana »

jokoon wrote: post #61

I remember being at a private game programming school, there was a school project to make a game with unity 2 or 3. An entire class was using it. Things were synced using subversion. I never really jumped in that. I did not continue at that school. I really think a video game is something that should be made with your custom tools. A good smith makes his own tools. Of course if you want to save time, you can use an e…

> A good smith makes his own tools

The problem is, this can be taken to infinitely far ends.

Editor annoys you? Modify it to your desires. Don't like the compiler? Write your own. Get sick of the programming language? Invent your own. Get annoyed with how the OS does something? Change it or invent your own. Bump up into x86's limitations? Start on custom FPGAs.

Ten years later, you might still have 0% completion on your videogame, and indetermine completion on your ever-fractaling toolchain. (And this isn't just a thought exercise; I remember a HN submission earlier this year that was nigh-identical to what I describe)

I would rephrase what you said as "A good smith knows his tools and their limitations, and knows when it's appropriate to make his own tools". Even when talking in analogy... a smith's apprentice would not presume to make his own tools before experiencing his master's, and even further I suspect most smiths did NOT make their own anvils, or mine their own steel... ;)

There's also a healthy serving of "Worse is better" in this line of argument.

Post reply on HN