Jump to content
Search In
  • More options...
Find results that contain...
Find results in...


ArtCraft Alumni
  • Content Count

  • Joined

  • Last visited

About hsmith

  • Rank
    Lead Client Programmer

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

1,200 profile views
  1. We currently have a kickstarter stretch goal to bring in a dedicated effects guy and if we reach it we'll probably be working together closely to figure out whats best for the game. Right now we are evaluating a piece of tech called PopcornFX that can produce some amazing volumetric effects (I think we've linked a demo video somewhere) but leveraging voxels is definitely on the table, especially for fluid simulation.
  2. Hi maric! This is definitely a design decision, there isn't anything in Unity that forces you to structure your world this way. For a lot of games like Shroud of the Avatar, breaking the world into discrete chunks makes a lot of sense, but for what we want to do with Crowfall, a large open streaming environment is a better fit.
  3. All of our initial testing with Unity 5 while it was in beta and now with the public release has been extremely positive. The folks at UT have taken a lot of feedback and improved the core performance of Unity in several ways from previous versions: While Unity's graphics system has recently gotten a huge facelift with Enlighten realtime GI, native PBR support, etc - what most people don't realize is that they also have an extremely efficient renderer. They have excellent tools and third party libraries integrated - like Umbra for occlusion culling, a slick dynamic batching system (once you know how to use it), and a very efficient lighting model. Unity 5 has made a lot of low level improvements to component lookup and GameObject instantiation speeds, capable of an order of magnitude improvement over previous versions, built ontop of their already well constructed scene graph. Unity's physics is also highly optimized, and several of us were incredibly impressed (dare I say shocked!) with the results of physics stress testing, and how well this performed especially with the new PhysX version upgrade. There are still a lot of knobs that we, on the engineering team, can turn to alleviate stress in some areas or transfer work to different subsystems (for example, I've been toying with Unity 5's new command buffer system to help customize the render pipeline of our game since the needs of the Voxel Terrain are so unique). There is no single limiter on concurrent players on screen, but a confluence of systems, architecture decisions, and collaboration with content creators to ensure the best possible play experience. Unity is just one tool in our belt for achieving this - it just so happens to be a really effective one!
  4. iTween is awesome, I've used it on previous projects and it's been a huuuge time saver.
  5. It sure does, iirc it's FMOD under the hood. There's a Wwise plugin as well, I believe. Unity 5 has added a huge drop of editor tools for audio that I have not yet had the chance to personally play with, but from what I hear it's pretty great (previous to 5 I used Fabric and that was a very well put together plugin).
  6. The short answer is no, I've been using UE4 as a hobbyist for about a year now, and prior to that have had some experiences in UE3 and I still don't think it's the right fit for our team or project. The longer answer is that while UE4 has made some significant improvements over the previous generation, not just in terms of user facing features but developer workflow as a whole, it's still a huge investment of time in order to make it do things the original developers didn't intend. I love UE4 for specific types of games, and even though various flavors of Unreal have been used as clients for MMOs (we have CF devs who have done it!) it requires a lot of effort and modification in order to use it that way. If you want gory details, we'll have to do it over a beer =p. I think the easiest way to describe the differences between Unreal and Unity is to kind of examine their history. Unreal comes from a generation of engines where developers created a game,then packaged their tools and code and sold that and the promise of support to another developer to make a different game. The new developer would then strip out all the gameplay and mechanics and whatever else didn't suit them, while trying to keep the rest of it from falling apart, then graft in new code to make a new game. Building a game in Unreal is like restoring a car, it's about figuring out which pieces work and which don't and salvaging what you can etc. The closer to the original car your goal is, the easier it will be. Unity is one of the first game engines I've used that was built as ... welll ... just an engine. It makes very few assumptions about what you are trying to build, but instead presents you with a lot of tools and common practices and solutions to common problems and then you are asked to figure it out. It's like ordering a kit car, and things come in a box with just a few of the more obscure bits put together for you. You can take this kit and build a motorcycle, or a boat, or a snowmobile if you wanted, just take the pieces that work for you and build around it. For a game like Crowfall where what we want has so many unique aspects, this modular engine design is much better suited to our needs. That all being said, UE4 does have a TON of cool stuff, and it this version is the most pleasant to use in the history of Unreal. I don't think it's right for Crowfall, but I think it's a fantastic choice for many games. -Howard
  7. Unity uses a modified(?) Mono 2.6.5 which still uses Boehm GC. The devs at UE are working on their new IL2CPP compilation path (currently only available for webGL products and iOS I think) which the developers say will give them the flexibility to upgrade - though to be honest I'm more interested in getting better .NET compatibility than I am in upgrading the GC (controversial controversial!) This change I believe they said at this years Unite would happen in the 5.x cycle, but not for 5.0. That being said, I should add that the Unity GC isn't half as bad as it's made out to be, and as most things in game development it's just about having an understanding about what is going on and working with the system and not against it. The biggest mistake is assuming that the CLR is going to handle it all for you. For most mundane day to day tasks, it's perfectly safe to rely on a garbage collector to not have to worry about the intricacies, but for high performance and memory intensive applications you need to be an active participant in how you deal with your memory no matter what language or platform you are developing in/for. I think those of us who come from a C/C++ background are more familiar with being very to the metal with memory, moving to .NET and having a seemingly light-featured or unintuitive API abstraction around it initially feels cumbersome and inefficient. It's easy to get frustrated, and that frustration I think turns many programmers - even experienced awesome coders - to think poorly on these tools. Once you embrace it (warts and all) and begin working within the paradigms of the language and runtime, it becomes a lot more manageable (no pun intended) and intuitive. Certainly well worth the effort! I hope that answers your question!
  8. Hello everyone! I know a lot of you have been asking to hear more about the technical side of Crowfall and I thought with the public release of Unity 5 it would be a good time to talk about how that particular piece of technology has played a significant role in how we've been building the game. We've been using Unity 5 early on in its beta and this choice was influenced by a number of important factors. A big part of it was how it brings together an impressive collection of proven, AAA quality modules out of the box. From their new PhysX 3.3 integration for physics simulation (extremely important to Crowfall's unique flavor of physically based combat) to their usage of Mono and the .NET platform - the developers at Unity have been kind enough to assemble a veritable dream team of game development middleware. As a team that has built more than their fair share of game engines as both hobbyists and professionals it's hard to overstate how much time was saved by not having to wrangle all these third party libraries and make them play nice with one another (not to mention those pesky licensing fees!) For most games this would be enough, but from its inception Crowfall has been a different kind of game that has very unique requirements. Fortunately, Unity has a well architected extension system - both as editor and runtime managed code as well as a native plugin architecture. This has enabled us to make significant modifications to subsystems that would otherwise be considered "under the hood" of most engines, and bring in our own or additional technology (like the beloved VoxelFarm!) not to mention the massive collection of libraries opened up to us in the .NET ecosystem. For development, we’ve also been extremely impressed with the additional workflow and features that Unity 5 has given us. As a programmer, their robust debugging and profiling tools have been invaluable in helping us identify issues and performance bottlenecks early on. Our combat team has been very happy with the improvements to the Mechanim system - especially the new animation state behaviors, and the new uGUI system has helped us build working prototypes of many of the screens you’ve already seen. Post launch, Crowfall’s unique Dying Worlds concept means we are going to need to be able to deliver new content quickly and effectively, and break up resources specific to each world and ruleset. We’ve been looking into the new powerful Asset Bundle system in Unity 5 to help us with this. There’s a lot more I’d love to talk and share with you! As always feel free to post on the forums and ask questions, and I’ll answer them as best I can. Let us know if you guys find these kinds of posts enjoyable (I’m not sure if they’re as much fun as design and art posts) Thanks for reading, looking forward to talking with you some more!
  9. Call in sick to work! What a great id- Do'h!
  10. Developer Tears will be a rare and valuable crafting resource.
  11. He also drank my Red Bull Just sayin.
  12. Thank you so much! *nom nom nom*
  13. Not stupid at all! Much of this is my fault for speaking very broadly about very complex issues. In an ideal world all an MMO client would do is render the scene and pass input to the server where the simulation was happening. With improvements in hardware outstripping improvements in network infrastructure, we've been working out ways to spread this work out more and more, but today (depending on your setup) what is slowing down your frames per second is more likely to be render related than simulation. Perhaps it would be more accurate for me to not categorize it in terms of CPU and GPU, but in terms of threads of responsibility, where rendering was chiefly the one dominating your individual frame timeslice (except in special circumstances). The nature of our voxel processing allows that to run concurrently with minimal disruption of the core client systems in a more traditional MMO, and potentially net us wins in terms of rendering as a whole. The point I wanted to get across was that while at first blush it might be reasonable to think that in order to get voxels we had to make sacrifices elsewhere (like large scale battles), but I wanted to assure all of you that voxels exist to serve the vision of the game, not the other way around. The things that brought you to this game (like siege warfare) will not be watered down for the sake of shiny new tech.
  14. You did, I saw that post and wanted to like it, but couldn't at the time. Retroactive like, engage!
  • Create New...