|
Stick100 posted:Yup, the C# (Xamarin for Unreal) is currently planning on ONLY implementing blueprint APIs. From what I can tell it's working alright on 4.4 and should soon have 4.5 access. There seem to only be a couple very minor issues so far. (having to drop into C++ 10% of the time or whatever is fine, just so long as the lion's share of gameplay work is being done at the C# level)
|
#
?
Nov 6, 2014 21:23
|
|
|
|
| # ? May 24, 2024 06:40 |
|
|
Shalinor posted:What does this mean, in practical terms? Will it prevent us from touching important subsystems, or anything of note? Anything you can do in Blueprint you can do in Xamarin for C# those limitations have been discussed by individuals better qualified then me. Anything else you'll have to use C++ or expose it to Blueprint or use C++/CLI. This stream shows a game done almost entirely in Blueprint. They discuss a case where they used C++ and exposed a new method to Blueprint (wanted the time off the system clock so they could set the gametime equal to the system time). http://www.twitch.tv/unrealengine/b/567537661 C# should be good enough for nearly everything. Probably a good analogy would be if you can do something in Unity's C# you can do it in Xamarin for Unreal. But the advantage of with Xamarin for Unreal if you run into a problem or find a thing you want to do you can go to the C++ and fix it while in Unity you're stuck and have to submit a bug and wait a year. Also Xamarin for Unreal is using C# 4 including Async and Await instead of Unity's old/busted version of Mono. Stick100 fucked around with this message at 21:52 on Nov 6, 2014 |
|
#
?
Nov 6, 2014 21:35
|
|
|
For a little bit of background on the plugin, it automatically exposes Blueprint functions of a UClass to it's C# counterpart (it uses the ScriptGenerator and builds a bunch of binded C# classes at build time). You can expose anything to the C# side by making a C++ function a UFunction with the blueprint property. Same thing with UProperties. If you don't want to expose things via UProperty/UFunction, the plugin has several partial classes setup that correlate with some UClasses (Actor, for example). They setup custom C# properties that aren't generated by a UProperty via internal function calls to C++; Unity pretty much does the same exact thing. They can use this to make the corresponding C# classes to be more like C# classes someone wrote for UE4 than just autogenerated stuff. This will probably apply to most of the UE4 base classes as they develop the plugin. It's not ready for prime time but it's making me like UE4 a lot more. Right now I'm converting some templates and see what missing features I can try to mess with. I'd like to try to do debugging support but I'd suspect that's on top of Xamarin's list.
|
|
#
?
Nov 6, 2014 22:39
|
|
|
Shalinor posted:What does this mean, in practical terms? Will it prevent us from touching important subsystems, or anything of note? If you're not doing anything crazy (lets make it an MMO!) you can do 95% of gameplay in blueprints. Epic's working really hard on exposing everything you need, but there's still things you'll want to build in c++. For example TMap, epic's dictionary data structure, cannot currently be a UPROPERTY, and therefore cannot be directly referenced from blueprints (or any of the other handy things UPROPERTY does, like serialization and replication.) They suggest implementing them in c++ and exposing an interface to blueprint. I've been lucky to get to work with UE4 at the studio for the past year or so, and at this point I don't mind all the macro boilerplate. It really rubbed me the wrong way at the start, but now it just gives me a bunch of stuff I want anyway. ShinAli posted:If you don't want to expose things via UProperty/UFunction, the plugin has several partial classes setup that correlate with some UClasses (Actor, for example). They setup custom C# properties that aren't generated by a UProperty via internal function calls to C++; Unity pretty much does the same exact thing. They can use this to make the corresponding C# classes to be more like C# classes someone wrote for UE4 than just autogenerated stuff. This will probably apply to most of the UE4 base classes as they develop the plugin. This is the part I'm interested to see what they do with, but it seems too early in development to tell how much use it will be.
|
|
#
?
Nov 6, 2014 23:37
|
|
|
echinopsis posted:Why is it so hard to get a rotation from a normal? I find all sorts of conversions but they require multiple vectors. dupersaurus posted:You need two vectors to make a rotation. To rotate an object to face along a vector, you first need to have a vector that represents the object's zero rotation state. From those two vectors (zero and normal in this case), you can calculate the rotation between them, which is the rotation you need to set on the object. Usually the zero vector is something like (1,0,0). I'm pretty sure you can do (this is Unity but same principles apply): transform.rotation = Quaternion.AngleAxis(SpinAngle (float), NormalToAlignTo (Vector3)) SpinAngle is, as it says, the rotation around the axis. So if your normal is directly up, SpinAngle is the degrees in which you've spun around that axis (so your facing direction in this case).
|
|
#
?
Nov 6, 2014 23:43
|
|
|
It's kinda cool how C# is still going (relatively) strong. I thought that it would die out along with Microsoft XNA... thankfully there are people interested in actively supporting an alternative dynamic recompiler/virtual machine for it. Honestly I didn't knew Mono was used for serious stuff (Unity) until now.
|
|
#
?
Nov 7, 2014 00:37
|
|
|
Japanese Phone Box posted:It's kinda cool how C# is still going (relatively) strong. I thought that it would die out along with Microsoft XNA... thankfully there are people interested in actively supporting an alternative dynamic recompiler/virtual machine for it. Honestly I didn't knew Mono was used for serious stuff (Unity) until now. I think a large part of why C# has remained popular, is that the language goes a long way towards solving a lot of issues with the C family languages, while minimizing the normally incurred costs associated with a managed language. The newest .NET/Mono versions are scary good, which is what makes working with Unity's old custom Mono version so frustrating.
|
|
#
?
Nov 7, 2014 00:58
|
|
|
The King of Swag posted:I think a large part of why C# has remained popular, is that the language goes a long way towards solving a lot of issues with the C family languages, while minimizing the normally incurred costs associated with a managed language. The newest .NET/Mono versions are scary good, which is what makes working with Unity's old custom Mono version so frustrating.
|
|
#
?
Nov 7, 2014 01:01
|
|
|
Inverness posted:Part of it is that it just fixes a lot of issues with Java while still continuing to be actively developed by Microsoft. The language has gotten so many new, great features over the years to make a developer's life easier. Async/await is a good example of this.  Stick100 posted:C# should be good enough for nearly everything. Probably a good analogy would be if you can do something in Unity's C# you can do it in Xamarin for Unreal. But the advantage of with Xamarin for Unreal if you run into a problem or find a thing you want to do you can go to the C++ and fix it while in Unity you're stuck and have to submit a bug and wait a year. UE4's going to walk all over them unless they figure something out fast. How much difficulty will there be keeping UE4 C# in sync with UE4 trunk? Is it the kind of thing where, since the bindings are to Blueprint, not much actually changes? So it generally only changes if you need access to a new Blueprint addition, or if UE4 really shifts something big? Or is it a struggle, and you're pretty much locked to UE4 X.Y until Xamarin updates? Shalinor fucked around with this message at 01:08 on Nov 7, 2014 |
|
#
?
Nov 7, 2014 01:05
|
|
|
Pretty sure you would have to wait for them to make a X.Y specific version, since there were still dingly little modifications they needed to do on UE4 itself to get things working. They're not really super crazy changes, as I was able to apply them to 4.5 over the weekend, though they are understandably just targeting at 4.4 since it's still in a pretty early state.
ShinAli fucked around with this message at 02:51 on Nov 7, 2014 |
|
#
?
Nov 7, 2014 02:40
|
|
|
Inverness posted:Part of it is that it just fixes a lot of issues with Java while still continuing to be actively developed by Microsoft. The language has gotten so many new, great features over the years to make a developer's life easier. Async/await is a good example of this. But enough about bad languages. C# is basically fulfilling the promise of being a high-level language that can still perform very well, and has been on a spree of implementing useful features quickly and in ways that work well. eeenmachine posted:Not to mention code portability. I can see moving a good amount of C# code to another engine that supports it but when most of your game is in blueprints it seems very unportable. 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. OneEightHundred fucked around with this message at 04:20 on Nov 7, 2014 |
|
#
?
Nov 7, 2014 04:12
|
|
|
OneEightHundred posted:It depends what it is, but I've never seen any two engines with paradigms even remotely close enough to even fathom gamecode from another one being portable. I think what he's trying to say is that all the code that's not engine centric, is usually portable between engines that use the same language. When you're working in Blueprints, all that work is inherently non-portable. Of course, the portion of your code that's engine-centric depends on the type of game you're making. A simple FPS is going to have a much larger portion of engine-centric code than say a Roguelike, which would largely be behind the scenes logic, which is all platform independent.
|
|
#
?
Nov 7, 2014 04:22
|
|
|
I don't have much experience with game engine's like unity and unreal..how feasible would it be to create a game client in unity/unreal that interacts/is controlled by a server written in python? I like the idea of just having the ease of making a graphical client with the game engine that makes calls to a server to get updates, but how do I get started on making calls from unreal/unity?
Feral Integral fucked around with this message at 07:13 on Nov 7, 2014 |
|
#
?
Nov 7, 2014 06:41
|
|
|
Feral Integral posted:I don't have much experience with game engine's like unity and unreal..how feasible would it be to create a game client in unity/unreal that interacts/is controlled by a server written in python? I like the idea of just having the ease of making a graphical client with the game engine that makes calls to a server to get updates, but how do I get started on making calls from unreal/unity? With Unity, you have access to the .NET framework so you can setup UDP/TCP sockets. UE4 also has UDP/TCP socket classes (something like FTcpListener or something). Actually, turns out theres a wiki tutorial for UE4 for setting up connection with some python script: https://wiki.unrealengine.com/TCP_Socket_Listener,_Receive_Binary_Data_From_an_IP/Port_Into_UE4,_(Full_Code_Sample)#.cpp There is also a C# library called UdpKit that kind of eases thing when doing UDP socket programming. The author wrote a Unity networking library with it called Bolt Engine, which is pretty decent as far as Unity networking libraries go.
|
|
#
?
Nov 7, 2014 07:34
|
|
|
OneEightHundred posted:It depends on what you want out of it. To learn? To make a completed game? To make things that other people will use? To make proof-of-concepts? There are a lot of directions that you could take, but many of them require drastically different priorities than the others.
|
|
#
?
Nov 7, 2014 07:51
|
|
|
So, uh, nobody really mentioned UE4 being so tightly-coupled with VS2013. Is there an open/free editor I can use while I'm picking at it? I have a VS2010 license, but I guess that's no good.
|
|
#
?
Nov 7, 2014 08:46
|
|
|
Rocko Bonaparte posted:So, uh, nobody really mentioned UE4 being so tightly-coupled with VS2013. Is there an open/free editor I can use while I'm picking at it? I have a VS2010 license, but I guess that's no good. How about VS2013 Express?
|
|
#
?
Nov 7, 2014 08:51
|
|
|
The King of Swag posted:I think what he's trying to say is that all the code that's not engine centric, is usually portable between engines that use the same language. When you're working in Blueprints, all that work is inherently non-portable. Even in something like a roguelike, I'm pretty sure that if you took two roguelikes that aren't from the same code lineage (i.e. Angband and NetHack), the amount that's portable between them is probably close to zero. Rocko Bonaparte posted:I just plunked down for the $20 and we'll see what it's like to do the basic little fighting cubes stuff I was doing in Unity with it. I'm going to assume Unity will do that a little bit better, but I figure I'd go nuts as soon as I tried to do one little thing more complicated with it. OneEightHundred fucked around with this message at 15:48 on Nov 7, 2014 |
|
#
?
Nov 7, 2014 15:46
|
|
|
dupersaurus posted:You need two vectors to make a rotation. To rotate an object to face along a vector, you first need to have a vector that represents the object's zero rotation state. From those two vectors (zero and normal in this case), you can calculate the rotation between them, which is the rotation you need to set on the object. Usually the zero vector is something like (1,0,0). OK that does make sense. So there are a lot of functions like [I'm not at my PC so I might remember these wrong] rotator from X, rotator from X,Y, and every combination of X,Y,Z . all of these take vectors [I'm sure] but none make sense to me. the only one that does is look-at rotation and it's handy but often not what I need
|
|
#
?
Nov 7, 2014 15:48
|
|
|
Nev posted:How about VS2013 Express? I misread that I needed the Pro version to do anything at all. Whoops! OneEightHundred posted:If you want to try both, go nuts, but I think that if you really want to get the most out of it, deciding what you want out of it matters. Finishing a game and having fun in particular are two very different goals, and I think it's important to pick a goal and base your decisions on that. A few years back I was pecking at stuff to learn component-based design and the current state of the art in game engines. I think now I have some ideas to prototype board games for my wife and doodle on an app. It might not make me any real money, but I feel at this point in my life, I should have released a program to a cruel public at least once.
|
|
#
?
Nov 7, 2014 16:38
|
|
|
OneEightHundred posted:Maybe I'm not understanding the specific case, but I just can't imagine this being true. As soon as you go from one engine to another, many basic assumptions about where functionality lives or whether it's present at all, and how it's executed, fall apart. I don't think that Unreal C# gamecode is ever going to be portable to Unity C# without a massive abstraction layer in both of them specifically designed to provide the same VERY high-level functionality. All the games we've shipped built with Unity using Futile (2d framework) are pretty portable to any other engine that uses C# as it really only uses Unity to render quads.
|
|
#
?
Nov 7, 2014 16:49
|
|
|
eeenmachine posted:All the games we've shipped built with Unity using Futile (2d framework) are pretty portable to any other engine that uses C# as it really only uses Unity to render quads. You can also write the tools "within" Unity, if you want a tightly coupled environment. Downside is the tools aren't very long-term portable and are prone to breaking if you update Unity, upside is it's easier to get them running on PC/Mac/Linux/maybe even mobile. (EDIT: But if you think about it, having a toolset that requires Unity 3.5 even though you've since ported the game to UE5 or whatever - I mean it's weird, but nothing about that setup cares that you're still running Unity 3.5, so "it works fine" so long as you've backed up a copy of Unity 3.5 in your source repo) Shalinor fucked around with this message at 17:19 on Nov 7, 2014 |
|
#
?
Nov 7, 2014 17:15
|
|
|
I am looking at traveling for a week with a laptop. Can I do that with UE4? It will be on my laptop, but I had installed on my desktop. I also have to deal with disk space and performance. If I can free up the many GB of disk, should I be clear for doodling?
|
|
#
?
Nov 8, 2014 03:08
|
|
|
Rocko Bonaparte posted:I am looking at traveling for a week with a laptop. Can I do that with UE4? It will be on my laptop, but I had installed on my desktop. I also have to deal with disk space and performance. If I can free up the many GB of disk, should I be clear for doodling? As long as your laptop has a nice modern dedicated nvidia or ATI GPU then your golden. Intel integrated will not cut it.
|
|
#
?
Nov 8, 2014 07:09
|
|
|
Ugh I think this thing is integrated graphics. It might not matter anyways. I'm sitting here with the top-down example in UE4, thinking, "Maybe I'll start by adding a little response to a right click." I can't even figure out how to even start to do that! The player control source files just declare some functions that seem to come out of thin air. I went poking through blueprints and could not find a player control in anything that could show a dataflow I can jump on. I'm absolutely clueless with it. I can't believe how helpless I am trying to do something as simple as that. Edit: Well I think I got a grip of it. I edited a bunch of files and thought I got the right-clicks to go through. But the stuff I put in to actually make it respond to the event did not trigger. It does not help that trying to look up anything about this just brings up tons of tons of Blueprint stuff. I'm thinking this might not be for more. The C++ stuff is too buried and I wasn't intending to have to wade through the visual language to figure anything out. I can't determine how I could, say, translate a blueprint to C++ since I can't figure out the API equivalents. Rocko Bonaparte fucked around with this message at 09:16 on Nov 8, 2014 |
|
#
?
Nov 8, 2014 08:47
|
|
|
Rocko Bonaparte posted:So, uh, nobody really mentioned UE4 being so tightly-coupled with VS2013. Is there an open/free editor I can use while I'm picking at it? I have a VS2010 license, but I guess that's no good. I don't like this about UE4 either. Besides the laptop mentioned below I also run UE4 on a 2011 iMac and I'd rather it startup Vim or Emacs for editing a file. Especially now code reloading is a thing since 4.5. Rocko Bonaparte posted:I am looking at traveling for a week with a laptop. Can I do that with UE4? It will be on my laptop, but I had installed on my desktop. I also have to deal with disk space and performance. If I can free up the many GB of disk, should I be clear for doodling? I use it on a two (or three?) year old Dell with an nVidia mobile GPU and it works fine. About C++ vs blueprints and leaving portability out of the question, would one even want to program most of a game using blueprints? Doesn't it become complex real quick? I can imagine one can replace huge swaths of flowcharts with a C++ class. This is a genuine question, I haven't used UE4 enough to determine this.
|
|
#
?
Nov 8, 2014 14:42
|
|
|
eeenmachine posted:All the games we've shipped built with Unity using Futile (2d framework) are pretty portable to any other engine that uses C# as it really only uses Unity to render quads. Same here, Sproggiwood runs on a fairly massive C# code base I developed for Caves of Qud, an dmoved largely intact to use unity as a rendering/input system. It means I have a kind of weird setup with my component-based game logic engine running alongside/undernrath Unity's component based engine. But I could probably port the whole thing to UE4+c# by just swapping out the input/output components (which would be a lot of work but would leave probably 80% of the code intact.)
|
|
#
?
Nov 8, 2014 16:00
|
|
|
edit: nevermind 
ModeSix fucked around with this message at 18:19 on Nov 8, 2014 |
|
#
?
Nov 8, 2014 17:56
|
|
|
You are an absolute monster.
|
|
#
?
Nov 8, 2014 18:02
|
|
|
senrath posted:You are an absolute monster. I take that as a compliment This is the first thing I've ever actually completed and I am quite proud of the final result. edit: I'm looking at monetizing through ad impressions, can anyone recommend/share their experiences with mobile ad providers that serve Android? ModeSix fucked around with this message at 18:24 on Nov 8, 2014 |
|
#
?
Nov 8, 2014 18:05
|
|
|
aerique posted:I don't like this about UE4 either. Besides the laptop mentioned below I also run UE4 on a 2011 iMac and I'd rather it startup Vim or Emacs for editing a file. Especially now code reloading is a thing since 4.5. I'm doing that, but out of necessity more than anything. also I have no idea how complex real games get but I think there is a general idea that blueprints serve single functions so you try not to have one thing doing everything, and then rely lots on functions, macros and comment comment comment
|
|
#
?
Nov 8, 2014 19:11
|
|
|
Rocko Bonaparte posted:The player control source files just declare some functions that seem to come out of thin air. I went poking through blueprints and could not find a player control in anything that could show a dataflow I can jump on. I'm absolutely clueless with it. I can't believe how helpless I am trying to do something as simple as that. I highly recommend following the C++ FPS from scratch written tutorial. It gives you a solid run down of some core systems and how to use the input binding system. You can find it pretty easily on the UE4 wiki.
|
|
#
?
Nov 8, 2014 19:49
|
|
|
ModeSix posted:edit: nevermind Where's the download link 
|
|
#
?
Nov 8, 2014 21:41
|
|
|
Japanese Phone Box posted:Where's the download link Here here -> https://dl.dropboxusercontent.com/u/92304749/Flap2048/Flap2048.html It still needs a couple small things that most people won't even notice aren't there, but overall it's in it's 1.0 state.
|
|
#
?
Nov 8, 2014 22:06
|
|
|
Has anyone here messed with a pathfinding solution for a 2D platformer in Unity? I'm seeing lots of 3D and top-down A* implementations but nothing really for sidescrollers.
|
|
#
?
Nov 9, 2014 21:10
|
|
|
Yodzilla posted:Has anyone here messed with a pathfinding solution for a 2D platformer in Unity? I'm seeing lots of 3D and top-down A* implementations but nothing really for sidescrollers. I don't know about anything that'll work out of the box, but the process is basically the same: You need to create nodes for places that characters can be, link the walkable paths between them, and do your pathfinding through that. For a platformer, that basically just means creating nodes for surfaces that NPCs can stand on, things that they can navigate through (i.e. ladders), and possibly jumps. Jumps are something that you can plot through either manually-placed connections, or automatically generate them by casting an arc path between nodes. OneEightHundred fucked around with this message at 21:36 on Nov 9, 2014 |
|
#
?
Nov 9, 2014 21:31
|
|
|
Wouldn't you just want steering behavior for a platformer and not proper pathfinding at all? I wouldn't think you gain that much from having a graph setup ahead of time. Using off the shelf pathfinding for me ended up way more work than just writing one myself. They always have complexity where you don't need it which just ends up with this huge mess of a thing that you try to wrangle every time you want to customize it. A* pathfinding project is the best but I really hated the dude's coding style which made fixing things myself and expanding it obnoxious and it's kinda unstable. FuzzySlippers fucked around with this message at 23:34 on Nov 9, 2014 |
|
#
?
Nov 9, 2014 21:53
|
|
|
$75 download for Unity is apparently free this week to support a procedural game jam: https://www.reddit.com/r/ProD/comments/2lmdhv/prod_total_is_free_for_the_duration_of_procjam/ What seems like a handy toolkit for procedurally generating maps and getting pathfinding working on them.
|
|
#
?
Nov 9, 2014 23:25
|
|
|
Let me pre-frame this with the fact that there are probably several things I'm not doing correctly, but it's getting to the point where its *almost* perfect So yeah I'm using an A* pathfinding system as well. I'll try to remember all the things I add to make it happen -I don't account for jumping when finding a path, just straight lines. -Going down is, on average, cheaper than going up -When generating a path each node has an additional cost, which is distance from ground. If it travels along the ground, the additional cost is 0 (easy to find in a 2d array, its just at the position under the current one). That cost is passed down to its child node (so each child node off the ground gets more and more expensive). That cost is reduced back to zero anytime its back on the ground. This is done to prevent the actors from trying to jump to places it can't reach. I have this set (right now) to make anything over 3 gaps big unreachable due to cost. -I've got some hacky things going on with the heuristics that seem to make it work better. For example if the destination is higher than the start, going down now costs slightly more (and vice versa). -AFTER a path is found, you usually travel backwards through the path to make the final path. This is where I create jumps. The path can't be generated over unreachable areas, so I don't have to insert much logic here. If the path point has no tile underneath, than obviously it's a jump, so as I'm creating the path I adjust pathpoint.y+16. There are a few other things I'm probably doing that I'm forgetting about, but that's the jist of it. My mindset with anything I've added is that I'm adjust for gravity, and I'm adjusting for gaps. Gaps aren't really a big deal with top down, and obviously there's no gravity either.
|
|
#
?
Nov 10, 2014 02:08
|
|
|
|
| # ? May 24, 2024 06:40 |
|
|
FuzzySlippers posted:Wouldn't you just want steering behavior for a platformer and not proper pathfinding at all? I wouldn't think you gain that much from having a graph setup ahead of time. Coldrice posted:-I've got some hacky things going on with the heuristics that seem to make it work better. For example if the destination is higher than the start, going down now costs slightly more (and vice versa). The only thing that you should need to do to make A* not return paths with pointless jumps is add a (possibly trivial) cost to jumps. I don't think you should need mid-air nodes either (whether a node link is a jump should just be specified by the link).
|
|
#
?
Nov 10, 2014 02:29
|
|