|
I just got back from a brief holiday and don't know how this happened but my Facebook flash hidden object game (Pearl's Peril) got nominated for Develop Awards 2014's Use of Narrative, alongside Brothers: A Tale of Two Son and Beyond: Two Souls. How did this happen oh god that's awesome  David Cage is probably wondering WTF too.
|
#
?
Apr 29, 2014 13:54
|
|
|
|
| # ? Jun 5, 2024 05:59 |
|
|
Mango Polo posted:I just got back from a brief holiday and don't know how this happened but my Facebook flash hidden object game (Pearl's Peril) got nominated for Develop Awards 2014's Use of Narrative, alongside Brothers: A Tale of Two Son and Beyond: Two Souls. Wow, congratulations! That's really cool!
|
|
#
?
Apr 29, 2014 17:15
|
|
|
Brackhar posted:Apparently Unreal has updated their EULA as part of UE4.1 such that the first $3000 earned per quarter is exempt from royalties. Pretty cool! I haven't tried recent Unity, but can speak to some initial UE4 stuff (as a professional UE3 technical designer). Overall tools are a lot nicer than UE3 and Unity, but some areas of engine didn't see much improvement (FX tool Cascade, etc.). Clear Unity influence in UE4, and it's much easier to tweak and simulate / play rapidly than UE3. UE4's lighting and rendering is dramatically better, but Unity supposedly has global illumination coming from what I saw at GDC? The big question for UE4 is technical workflow. Blueprint is really well done and will enable a lot of people to prototype and "script" that couldn't easily do it before. That said I have some serious concerns about Blueprint maintainability over longer term / larger team projects, as I would with most any visual scripting language. But that may just be wariness from seeing too much bad Kismet in UE3 talking. I do think Unity is a bit more friendly to the "advanced" hobbyist or indie dev who wants to code but doesn't want to get too deep into things. Unreal 4 has a bit of an awkward gap IMO between high level visual scripting (Blueprint) and C++. Coming from Unreal 3 I'm very comfortable in UnrealScript and what it does - a high level scripting language that can do more complex things when needed. Unity just throws you in C# which is a great language for flexibility. Epic's clearly pushing that functionality into Blueprint's visual scripting, but there are simply things Blueprint doesn't do yet, or doesn't do WELL. You end up hopping to the C++ side which, while workable, will be intimidating to people comfortable with Unity's C# approach or UnrealScript. You're also at the mercy of Epic version upgrades which may add or remove standardized Blueprint nodes/connectors/etc. at will. Merging a source file to a new version is fairly straightforward, but a large Blueprint "codebase" could be really difficult to upgrade if there are significant changes to basic interfaces. There's also an odd tension between when to use C++ and when to use a Blueprint, where to reference content, and what the basic pipeline should be (create C++ base class and sub blueprints? create C++ class hierarchy and blueprint each individually? which properties to expose? etc.) that adds a few headaches to getting rolling that I don't think you run into with Unity.
|
|
#
?
Apr 30, 2014 19:15
|
|
|
I dont necessarily think the choice of when to use blueprint vs c++ is all that different from the choice you would make of when to use C++ vs unrealscript or (name your scripting language here). A change also landed yesterday in UE4 master that will make it much easier for third parties to add a scripting system onto UE4. They even provide a sample plugin with lua. I understand the worry about how maintainable are the blueprints going to be over the long haul. It seems like they tried to address that with a few things: - they have in-editor blueprint diff'ing, so you can see the changes from one revision to another - they are making it easy to decouple blueprint functionality, eg. with BlueprintInterfaces and BlueprintClasses, and various ways for blueprints to 'talk' to each other, so you don't have this huge monolithic blueprint graph
|
|
#
?
Apr 30, 2014 20:12
|
|
|
And, most importantly, any change to core blueprints by Epic is usually accompanied with a redirect that will transparently rename the properties, functions, params, etc. on Blueprint assets that still use the old names. Truly breaking that can't be handled by redirect are often handled by deprecation instead, so any old assets will continue working but emit a warning until you switch to the newer equivalent. The redirects are handled in config files, so you can look up the existing ones in BaseEngine or define your own in your DefaultEngine.
|
|
#
?
Apr 30, 2014 21:01
|
|
|
Is the C++ in UE4 vs the C# in Unity really all that different, though? IIRC, they have a garbage collection system (?), and for 99% of your "just gameplay logic" code, I can't imagine C++ VS C# would make much difference at all. It's just logic and components and some messaging.
|
|
#
?
Apr 30, 2014 22:05
|
|
|
xgalaxy posted:I dont necessarily think the choice of when to use blueprint vs c++ is all that different from the choice you would make of when to use C++ vs unrealscript or (name your scripting language here). A change also landed yesterday in UE4 master that will make it much easier for third parties to add a scripting system onto UE4. They even provide a sample plugin with lua. I do because UnrealScript vs. C++ is largely a ease of use vs. perf choice that can be relatively easily translated in either direction when necessary. Given I haven't actually MADE a full game in UE4 yet I can't usefully comment one way or another, but I can imagine scenarios being relatively painful. For example a team new to Unreal doing a lot of Pawn/Game logic in Blueprints and then later needing to port to C++ for perf or maintainability. In UE3 that's basically adding "native" keyword to a few functions and fixing up some syntax, but Blueprint<->C++ conversions will be a much bigger timesuck. Shalinor posted:Is the C++ in UE4 vs the C# in Unity really all that different, though? IIRC, they have a garbage collection system (?), and for 99% of your "just gameplay logic" code, I can't imagine C++ VS C# would make much difference at all. It's just logic and components and some messaging. They've taken pains to make it very C#/UnrealScript-esque, so it's not hugely different. Declaring headers/etc. is pretty ugly, though - lots of custom, verbose syntax and not very readable compared to C#/UnrealScript. E.g., UE3 posted:var SpringArmComponent CameraBoom; UE4 posted:UPROPERTY(VisibleAnywhere, BlueprintReadOnly, Category=Camera) But to be fair, once you're in the groove just editing function behavior it's kinda similar, and "hot reload" on C++ recompiles is miles better than UnrealScript rebuilding. As a designer who likes to program still (former programmer), Blueprint diff is a nice effort but it's still a far cry from merging which I think will come up more than people think when working on more complex projects. I don't mean to only focus on the negatives - I really like what I've seen of UE4, and I think Blueprint is a cool step towards making scripting more accessible. But I think the jury's still out on what use cases it will be sustainable for and what team sizes. Kismet was a pretty ugly failure IMO, but Blueprint does try hard to learn from those mistakes. I will have to look into that third party script engine option for our future titles, I would love to have something less cumbersome than C++ to prototype in that doesn't have the downsides of visual script packages. Thanks for the tip.
|
|
#
?
May 1, 2014 07:12
|
|
|
It would be awesome if Epic built in some code refactoring into their custom visual studio add on that automated or eased the creation of those boilerplate macros. But as was pointed out, coming from C# they aren't that different from C# attributes actually. It's just the typing and remembering what things to put there that is hard. So extending their Vs addon to make that easier could be really beneficial.
xgalaxy fucked around with this message at 08:03 on May 1, 2014 |
|
#
?
May 1, 2014 07:59
|
|
|
Me and a friend have both been working with Unreal 4 for a while now. I have programmed before, never C++ though and quite frankly, the little I know of programming isn't all that impressive. My Friend studies Engineering Physics or whatever it is called in English so he had never programmed until he started playing around with Unity in January. Despite this we have both gotten up to speed rather quickly with Unreal 4 and the Blueprint system, especially my friend since he applies his knowledge of physics to make, for example, a beam spell. So far we are both happy with choosing Unreal 4 and every day I sit with Unreal I keep reminding myself of how everything was so tedious with he Source engine. Not a fair comparison I guess but it was the best engine around that had plenty of content to get you started.
|
|
#
?
May 1, 2014 12:15
|
|
|
icking fudiot posted:Declaring headers/etc. is pretty ugly, though - lots of custom, verbose syntax and not very readable compared to C#/UnrealScript. "Lots" of syntax? Really? A single UPROPERTY/UFUNCTION/UCLASS/etc. tag containing a few attributes? Are you forgetting that UnrealScript is a custom, cumbersome syntax of its own requiring you to declare your classes in a special file format... xgalaxy posted:It would be awesome if Epic built in some code refactoring into their custom visual studio add on that automated or eased the creation of those boilerplate macros. But as was pointed out, coming from C# they aren't that different from C# attributes actually. It's just the typing and remembering what things to put there that is hard. Autocomplete will fill in your VisibleAnywhere/EditAnywhere/Transient/Category/etc. easily, and if there really is something you can't remember, just have to look through the attribute list in ObjectBas.
|
|
#
?
May 1, 2014 16:39
|
|
|
Shalinor posted:Is the C++ in UE4 vs the C# in Unity really all that different, though? IIRC, they have a garbage collection system (?), and for 99% of your "just gameplay logic" code, I can't imagine C++ VS C# would make much difference at all. It's just logic and components and some messaging. The main difference is that it's really easy for things to go surprisingly wrong in Unreal C++. If you forget a UPROPERTY declaration on an object pointer, that field won't be serialized by garbage collection and you will enjoy random crashes. I really feel for anyone not intimately familiar with C++ and debugging who is trying to get into UE4. Last night I was debugging a convoluted crash that happened when you hit the friendly "Compile" button in the blueprint editor that seems to have been introduced in 4.1 which brings me to my other fear about UE4's public release - the release schedules. If they release every month and every month has new bugs, people are going to get sick of upgrading and it's either going to fracture the community or just drive people away from UE4.
|
|
#
?
May 1, 2014 18:34
|
|
|
IMO, if you are in 'production' you shouldn't be upgrading the engine anyway, unless absolutely necessary. And even then just cherry pick the changes you absolutely need. EDIT: Speaking of UE4, EVE Valkyrie switches from Unity to UE4. xgalaxy fucked around with this message at 19:02 on May 1, 2014 |
|
#
?
May 1, 2014 18:55
|
|
|
Jan posted:"Lots" of syntax? Really? A single UPROPERTY/UFUNCTION/UCLASS/etc. tag containing a few attributes? Are you forgetting that UnrealScript is a custom, cumbersome syntax of its own requiring you to declare your classes in a special file format... I guess we'll just have to disagree, I think claiming UnrealScript is cumbersome syntax is laughable next to the UE4 C++ examples I gave, and the "special file format" is a text file with .uc on the end? For me personally it boils down to something like.. - Boilerplate code required to define and implement classes is objectively more verbose, more complex, and less readable than an UnrealScript (or LUA, or other actual scripting language) equivalent - Forcing non-C++ prototyping and implementation into Blueprint visual scripts doesn't solve the performance or maintainability problems of having a "script" layer on top of native code, but sacrifices a lot of the advantages of a traditional scripting language (established tools, easy diff/merge/search, readability of large/complex scripts compared to complex blueprints/kismet trees) Obviously there's options, like Epic exposing better access for grafting your script language of choice onto the engine in a future update. And I don't want to "win" an argument here, I fully expect I could be proven completely wrong over the course of the next few years about this approach. Just my 2 cents as someone who is admittedly comfortable in a UE3 ecosystem and likes the idea of game code being easily prototypable in flexible, more forgiving languages (but is generally wary of unsolved problems in visual scripting for team projects). Anecdotally, and with tongue in cheek, I am also a little bit horrified of the Blueprint monstrosities our level designers and tech artists are going to create - I've seen their material graphs and kismet before, and I felt terror deep within my being at the sight. For instance (not ours, from Google):  KILL ME icking fudiot fucked around with this message at 19:35 on May 1, 2014 |
|
#
?
May 1, 2014 19:26
|
|
|
Reminds me of making maps for Source engine games!
|
|
#
?
May 1, 2014 19:40
|
|
|
That is trivial compared to some of the things that our guys create. I'm embarrassed to post them, though, because the tool we use is what I maintain. Usually they are prototypes, though, so people are doing things that we wouldn't necessarily ship/should be done in code.
|
|
#
?
May 1, 2014 19:49
|
|
|
icking fudiot posted:I guess we'll just have to disagree, I think claiming UnrealScript is cumbersome syntax is laughable next to the UE4 C++ examples I gave, and the "special file format" is a text file with .uc on the end? Needing to use scripting syntax to declare C++ classes is cumbersome, yes. I am coding in C++ instead of a scripting language for a reason. icking fudiot posted:- Boilerplate code required to define and implement classes is objectively more verbose, more complex, and less readable than an UnrealScript (or LUA, or other actual scripting language) equivalent This is really the only thing I don't get -- I still don't see how the header syntax is cumbersome or ugly. UE4 tags are more verbose and complex because they give far more control than UnrealScript declarations ever did. If all you need is a managed property, you simply need to add UPROPERTY() which I honestly don't find less readable than var. With Visual Assist's default settings, the Unreal header syntax takes a discreet, pleasant shade of purple that you can easily gloss over to look at the actual variable or function that you care about.
|
|
#
?
May 1, 2014 20:17
|
|
|
So I've been invited by the Brazilian government to come speak at their game show in two weeks: http://www.bigfestival.com.br/programacao All expenses paid week in Sao Paulo and Porto Alegre because they are awesome and have the game show in two cities.
|
|
#
?
May 1, 2014 22:17
|
|
|
 Yay! We got featured in the app store for Dwarven Den. I am pretty jazzed about it, though my personal contribution to this particular project is pretty minimal (I drew that spider concept within the first month I started working at the studio and then got assigned to another game).
|
|
#
?
May 1, 2014 23:02
|
|
|
There is a new post @UnrealEngine detailing how to manage complex blueprints.
|
|
#
?
May 6, 2014 00:29
|
|
|
xgalaxy posted:There is a new post @UnrealEngine detailing how to manage complex blueprints. That's not bad. I'd love to see a discussion of merging/diffing blueprints.
|
|
#
?
May 6, 2014 00:41
|
|
|
Can anyone recommend any reading material on game design?
|
|
#
?
May 6, 2014 01:09
|
|
|
Chernabog posted:Can anyone recommend any reading material on game design? A Game Design Vocabulary: Exploring the Foundational Principles Behind Good Game Design - http://www.amazon.com/gp/product/B00IJYFDPG/ref=oh_d__o00_details_o00__i00?ie=UTF8&psc=1 I just finished this one. It's really good and explains some of the basics of game design in very easy to digest ways. There's cliffnotes at the end of each chapter as well as some exercises. There's also a list of recent games in the back the author suggests you play in order to look for the concepts. The Art of Game Design: A book of lenses - http://www.amazon.com/gp/product/B004EHZPEG/ref=oh_d__o02_details_o02__i00?ie=UTF8&psc=1 Probably the best Game Design book. This is always the first book recommended when someone asks for game design material. I'm probably a good 10% into this one and I already like it more than the Game Design Vocabulary book. The book is broken into conceptual 'lenses' that you view your game with. Be careful to not pick up the lenses cards that are much cheaper unless you want to snag both. Level Up!: The Guide to Great Video Game Design - http://www.amazon.com/gp/product/B0046REX10/ref=oh_d__o01_details_o01__i00?ie=UTF8&psc=1 Recommended to me by 2 friends. Will let you know one day when I get to reading it.
|
|
#
?
May 6, 2014 01:59
|
|
|
Understanding Comics: The Invisible Art.
|
|
#
?
May 6, 2014 02:14
|
|
|
Thanks. I'll look into those. And I have seen the comics one, but not for game design.
|
|
#
?
May 6, 2014 02:57
|
|
|
The best part of the games industry is that even when you and your friends go separate ways, you'll wind up in town sooner or later. I've got two friends from back in my Volition days moving out to SoCal soon. After 7 years as a AAA dev, it's rather absurd how many friends and colleagues I have spread across the US. It's also kind of chilling to think about how this would affect my job prospects if I had a poor reputation.
|
|
#
?
May 7, 2014 18:51
|
|
|
Sigma-X posted:The best part of the games industry is that even when you and your friends go separate ways, you'll wind up in town sooner or later. Yeah, that was one of the most revelatory bits of GDC for me. I knew that I'd had friends come and go over the years (we have, IIRC, relatively low turnover by game industry standards) and I was still constantly running into people that I knew who were working other places.
|
|
#
?
May 7, 2014 18:57
|
|
|
Learning of the week: Chinese pirates are great for stress testing servers!
|
|
#
?
May 7, 2014 19:04
|
|
Sigma-X posted:The best part of the games industry is that even when you and your friends go separate ways, you'll wind up in town sooner or later. So when am I getting that tour of RaD bruv?  Oh wait you're in Irvine pshhhhh
|
|
|
#
?
May 7, 2014 19:25
|
|
|
You can have a tour of IA. It will last 2 minutes and it'll take you several days to get out here in 91 traffic.
|
|
#
?
May 8, 2014 01:15
|
|
|
91? That's not traffic. Gimme some 55 at 7 in the morning or anywhere in Los Angeles between 12:01 A.M. and 12:00 A.M.
|
|
#
?
May 8, 2014 01:21
|
|
|
Studio posted:91? That's not traffic. Gimme some 55 at 7 in the morning or anywhere in Los Angeles between 12:01 A.M. and 12:00 A.M. When I was at nexon my route was the 405 to Sepulveda in El Segundo, just a few streets shy of LAX. That's right. LAX Commuter traffic. Every single day.  Oh, but speaking of LA, I've got a few E3 affiliate passes up for grabs, if anyone's at a company where they run out really fast... (And I need a GWG volunteer in North Hollywood this saturday morning, just sayin')
|
|
#
?
May 8, 2014 01:45
|
|
|
Driving back from Ontario/San Bernardino to Irvine on the 91, my favorite bit is the one curve where there is always, always, always an accident. The road dips and turns and so it's very difficult to gauge traffic and it's about where the natural flow of traffic drops about 20mph and as a result there is always some motherfucker wrapped around some other motherfucker filling the carpool lane and killing the whole flow of traffic.
|
|
#
?
May 8, 2014 02:19
|
|
|
You mean the toll lane that costs 5 loving dollars to go 4 miles that they installed instead of actually solving the traffic problems?
|
|
#
?
May 8, 2014 03:58
|
|
|
There is no loving way the 55 is worse than the 91. None.
|
|
#
?
May 8, 2014 15:38
|
|
|
I used to do 5 to 55 to 405 and the gridlock between getting on the 5 and 405 was godawful. This was a few years ago and I think some of the transitions were under construction
|
|
#
?
May 8, 2014 16:19
|
|
|
Construction doesn't matter. Nothing will ever make the El Toro Y not a vehicular hellscape.
|
|
#
?
May 8, 2014 19:59
|
|
|
How about this: There is nothing more awful then seeing cars on a freeway overpass moving quickly, but when you get on the freeway you find out bumper to bumper traffic starts about 2 seconds after the entrance.
|
|
#
?
May 8, 2014 20:04
|
|
|
mutata posted:You mean the toll lane that costs 5 loving dollars to go 4 miles that they installed instead of actually solving the traffic problems? No, before that - when you're going down/south the 91, about 3 miles before the 241 I think, it's before you hit the mountain proper and start going down, there's a dip and the whole road jogs to the left and just around that location is where traffic is usually backed up and running slowly. But yeah, gently caress that whole road and the traffic situation. It's not as bad as the 5, but it sucks because it's the one I actually drive. Also seriously gently caress the tolls. The 241 Toll road shaves 4 miles off the journey and is $5.75
|
|
#
?
May 8, 2014 22:06
|
|
|
The entire last page is reading like why_I_will_never_move_to_california.txt.
|
|
#
?
May 9, 2014 00:40
|
|
|
|
| # ? Jun 5, 2024 05:59 |
|
|
If it's worth anything you could easily get by in California with owning nothing but shorts (business aside).
|
|
#
?
May 9, 2014 00:48
|
|