Game Development

Summarized using AI

VR Backend Rails vs. Serverless: Froth or Future?

Ram Ramakrishnan and Janet Brown • February 09, 2017 • Earth

The video titled "VR Backend Rails vs. Serverless: Froth or Future?" featuring Janet Brown and Ron Ramakrishnan explores the backend development choices for a Virtual Reality (VR) application. The presenters, from Atot Studios, share their journey of developing a collaborative multi-user VR app for a technically proficient client, who initially favored serverless technology (using AWS Lambda). However, after careful consideration, they opted for Ruby on Rails, particularly its API mode.

The key points discussed in the video include:

  • Understanding the Technologies: The talk begins with an exploration of the hype surrounding both VR and serverless technologies, emphasizing the need to ground discussions in practical realities rather than buzzwords.
  • Client Requirements: The client sought a VR system enabling six degrees of freedom and real-time interactions among users in various locations, informed their choice of technology.
  • Technical Considerations: The presenters detail the three critical layers needed for VR: a core game engine for physics and animation, a connection layer for user synchronization, and a persistence layer for saving user interactions.
  • Evaluation of Serverless: They clarify that serverless does not imply the absence of servers but a model that abstracts server management to third parties, which can help with scaling but also poses challenges like increased complexity and data management concerns.
  • Rails Advantages: Ultimately, they concluded that Rails offered features conducive to their needs, such as a strong testing infrastructure, integration capabilities, and alignment with client infrastructure.
  • Challenges of Serverless: They discuss the limitations of a serverless approach, including execution time limits, potential latency, and challenges in managing substantial data securely.
  • Future Considerations: The presenters ponder the evolving nature of serverless technology alongside the growth of the VR industry, advocating for a hybrid approach that leverages both serverless and traditional frameworks.

In conclusion, the key takeaways include a nuanced understanding of serverless technology as not a one-size-fits-all solution, the robust nature of Rails in handling complex applications, and an invitation for the audience to explore VR development and applications in depth. The discussion highlights the importance of aligning technology choices with project requirements and user experience goals.

VR Backend Rails vs. Serverless: Froth or Future?
Ram Ramakrishnan and Janet Brown • February 09, 2017 • Earth

http://www.rubyconf.org.au

Serverless (via AWS Lambda), the new hotness, was definitely something we wanted to explore when developing the backend for our new Virtual Reality app. TLDR - despite expectations to the contrary we came back to Rails, specifically Rails 5 API mode. We'll walk you through our journey, what the different considerations were, what the different strengths of each platform are and how we reached our decision. We think it's essential that as Rails developers we have an understanding of Serverless, both as a replacement and as an augmentation to our skill-set and development environment.

RubyConf AU 2017

00:00:10.719 Hey guys, today we want to talk about VR backend, Rails vs. Serverless: Froth or Future.
00:00:13.000 So as you said, I'm Janet and I'm here with Ron. We're from Atot Studios.
00:00:16.199 We have a full stack development studio in San Francisco, where we develop VR and AR products for clients.
00:00:21.359 We also train and teach VR and AR, and we have a game on the Steam store in Early Access called 'Live in Color'. We are big fans of VR.
00:00:34.800 What we want to discuss today is the journey we went through relatively recently with a client. This client was very technically astute, which is always both a blessing and a curse.
00:00:44.399 They were determined that we would use Serverless as the backend for the VR app we were building for them. Spoiler alert: we ended up choosing Ruby on Rails instead of serverless.
00:01:05.840 We found that journey to be quite interesting, and we believe it would be interesting for everyone here today. We'll discuss the hype surrounding both VR and serverless, share the problem and use case we faced, explain how we solved it, and compare Rails with Serverless.
00:01:18.119 Finally, we will outline our thoughts on the future of these technologies.
00:01:14.000 First, we're trying really hard not to turn this talk into a buzzword bingo experience. If we dropped in some terms like Elixir and Millennials into the title, we’d probably hit every buzzword at this conference.
00:01:30.799 So, hold us accountable if we start overusing buzzwords. We want to ground our discussion in reality.
00:01:40.800 This is Conan O'Brien experiencing the HTC Vive for the first time in a job simulator, one of the launch titles for the HTC Vive. We probably have people in this room on both sides of the hype. Some might think it's the next Blu-ray, while others believe it's going nowhere and just beta VHS.
00:02:05.960 However, we can all agree there's a significant amount of hype surrounding VR right now. To cut through the hysteria, we need to explore what's underneath.
00:02:26.760 For our client, we were considering a VR system offering six degrees of Freedom, powered by PC-based immersive audio feedback.
00:02:39.120 We considered the HTC Vive and the Oculus Rift for our project. Typically, these setups involve a head-mounted display (HMD) that creates an immersive environment and hand controllers to allow physical interaction.
00:02:50.680 With Oculus now offering touch controllers that enable movement, there became a new opportunity in VR. Notably, we did not consider console-based VR, such as PlayStation VR, which only allows front-facing movement.
00:03:06.080 Moving on to the next hype aspect: serverless technology. We want to clarify that serverless does not mean there are absolutely no servers involved.
00:03:26.840 In reality, serverless abstracts the traditional application model into different layers, where browsers now take the lead in facilitating rich client experiences.
00:03:55.440 Core services can be abstracted to third-party solutions for authentication and product databases. The most commonly used tools in serverless applications include Auth0 for authentication and Firebase for databases.
00:04:17.680 It's essential to connect these components through an API Gateway to hook everything together, resulting in lightweight and focused single-responsibility functions executing precise core logic.
00:04:56.080 However, serverless does not mean that all the backend logic is eliminated. It simply outsources server management to third parties, which takes care of provisioning and state management.
00:05:03.800 Back to our client’s project: they wanted a multi-user, real-time collaborative virtual reality application that could function across different locations.
00:05:21.440 This required a careful consideration of three layers: the core game engine providing physics and animation, a connection layer for synchronization, and finally, a persistence layer for maintaining user interaction.
00:05:38.160 When we looked at the problem, we knew that to create a shared VR experience, we needed to think through how other users would interact within the same virtual space.
00:06:02.639 Typically, we'd utilize Unity or Unreal to create the game engine that delivers powerful physics and analytics needed for VR.
00:06:13.760 Both engines can support the complexities of virtual reality while facilitating the interactivity of multiple users.
00:06:38.720 Ultimately, we'd also need to implement a third layer to maintain user settings and preferences, predominantly using persistent storage.
00:06:55.720 Our client was enthusiastic about exploring serverless options in terms of scaling and performance as the application was anticipated to grow significantly.
00:07:14.080 But after assessing the needs of the system and user experience value that Rails provided, we concluded it delivered exactly what we needed.
00:07:32.640 To illustrate a familiar example, let's consider building a virtual reality cricket game. The game engine could host a static environment while ensuring a seamless interactive experience with players.
00:07:57.680 As we move forward with our plans, we identified Unity as the best-fit engine since it currently holds a 45% market share in the gaming industry.
00:08:19.760 However, we decided to go with Photon for networking, which has proven to be robust and suitable for our enterprise client's needs.
00:08:38.560 During development, we also found that Rails offered valuable features for the testing infrastructure that supported our overall strategy.
00:09:07.040 Although we faced some integration challenges, the Rails ecosystem provided tools that made it feasible.
00:09:37.720 As a Ruby community, we are used to a robust environment that allows us to integrate different libraries and extensions into our workflow.
00:10:05.440 These attributes made Rails the superior choice for our client, considering their comfort with the technology and their existing infrastructure.
00:10:27.040 However, as we consider the broader implications and potential uses of serverless, we gained insights into why clients often feel serverless is the answer.
00:10:57.200 With serverless, clients see the promise of autoscaling, lower costs, and reduced execution management overhead. The ability to scale with unanticipated growth seemed appealing.
00:11:25.840 Nevertheless, there are several caveats. Serverless functions are limited in execution time and capacity. If not managed well, this approach could lead to unforeseen expenses.
00:11:58.560 In addition, serverless can introduce latency due to container cold starts, impacting the end-user experience and complicating testing across distributed systems.
00:12:31.280 When dealing with a substantial amount of data and third-party services, maintaining control became a challenge.
00:13:04.560 For our client, many of their use cases revolved around consumer and proprietary data that required high levels of management and security.
00:13:26.240 As we continued evaluating serverless technology, we found several challenges, such as increased complexity in the solution and the need for specific skill sets to manage distributed systems effectively.
00:13:47.680 Before signing off, we want to emphasize that serverless isn't an all-or-nothing approach. Organizations can adopt hybrid systems, leveraging both serverless and traditional frameworks efficiently.
00:14:15.760 There's a notable interest in how serverless technology will evolve, especially as the VR industry continues to grow.
00:14:36.760 As we close, we invite further discussions about how we can integrate Ruby and serverless together to address various use case challenges.
00:15:06.200 Finally, we'd like to extend an invitation to everyone here to explore VR more actively, whether through development or immersive experiences.
00:15:27.040 With that, we'd like to thank you all for your time today, and we look forward to engaging with many of you on the topic.
Explore all talks recorded at RubyConf AU 2017
+20