.jpeg)
If you ever find yourself on reddit.com/r/gamedev, you might notice something.
Browsing through the thread, you’ll often find posts from newly minted computer science grads or enthusiastic hobbyists lobbying questions about creating efficient collision detection systems, or effective ways to create spritesheets for their new indie video game that they are working on.
Almost always, the same reply pops up: “Why aren’t you using a game engine?”
Aspiring game developers often fall into the trap of creating a video game from scratch. That’s because, as a developer, it’s really easy to start building an entire game from the ground up when there’s no foreseeable reason why it can’t be done.
But what’s hard to see, and what these newer developers often miss, is the cost-benefit ratio of developing something from scratch.
The main cost? Time. Add to that challenge the programmer’s greatest weakness: underestimating the effort needed to complete a project.
At the end of the day, creating a game from scratch can be an enlightening endeavor. You learn what it takes to efficiently manage assets, how to make a level editor, how to serialize data, how to write shaders, how to write collision or physics engines, and a ton more.
But you’ll eventually realize you spent more time making the systems to support the game than making the game itself. Systems that someone has already made before, most likely with a more full-featured and efficient implementation.
How game engines reduce code to maximize efficiency.
Let’s take a look at a game engine.
Now, I chose this video because it shows the value of a game engine very well. You can see the asset management, visual level creation, visual animation modification, as well as visual scripting.
I liked Amazon Lumberyard’s video the best, but those sort of features are commonplace in Game Engines—it’s quite literally what they are made for.
If you take a look at these screenshots below, you can see that there is a common understanding among game developers about what an engine should do for its users.
Game engines reduce code as much as possible in order to give the developers maximum agency and efficiency in developing their game.
Furthermore, engines make development visual. “Information is only useful when it can be understood” is one of my favorite quotes by Muriel Cooper. While that quote is typically used in conversations about data visualization, it is just as pertinent when discussing the creation of experiences.
Avoid the blocks of code found in Angular and React.
In other words, can you tell me what needs to be fixed with this chunk of code?
Well, for starters the “<style>” tag is at the bottom of the page, which should never be done (you risk rendering content without style).</style>
But let’s look at what renders when you put this code in an HTML file and view it in a web browser:
Yup, it’s just white, because the text color is white, and the background is white by default. This is a silly example, and for those that know HTML/CSS, it’s pretty easy to spot.
But my point is this: why is the vast majority of web app development still being done in code? If you go to the homepage of React, you are greeted with a set of blocks of code like this, demonstrating how you can get started making applications:
How about Angular?
I mean, the code is different. But we’re still using code as our primary driver to create a visual experience.
Angular and React are the most popular front-end development platforms right now, but the development experiences don’t even begin to touch something like that of any of the game engines we’ve looked at.
I’m not trying to pick on React or Angular—honestly, they’re great. But what I’m trying to get at is that we are really doing ourselves a disservice if we restrict what we consider as web development to just coding.
Just like it’s inefficient to build a game from scratch, the same goes for web app development . Web app developers need to stop wasting their time coding things that have already been done and start using more visual tools. And these tools should look a lot closer to a game engine than they do to a code editor.
Game engine functionality applied to web app development.
So, how can we bring that kind of tool to web app development? Luckily, it already exists, and it’s called Skuid.
Functionally, Skuid is like very much like a game engine, but for building enterprise apps. I have been working as part of the product development team for Skuid, an app development platform for enterprises, for awhile now and am very proud of the product we have built.
Skuid is visual. It’s iterative. It provides visual flows for executing logical sequences. Skuid connects to a wide variety of systems of record, can deploy to mobile applications, has built in offline capability, and is supported by some of the hardest working, brightest engineering and design teams around (although I may be a little biased). On top of that, Skuid has the most flexible declarative componentry—with accompanying visual design tools—on the planet.
Here’s an example of an app being built with Skuid:
And here’s what that app actually looks like:
When some of our friends at Procore Technologies used Skuid to build a custom application for their customer success team, here’s what their developers said about the process:
“I would definitely recommend Skuid to another developer,” says Michael Schniepp, customer success operations specialist. “I do a lot of custom work and automation that you just can’t get without Skuid.”
Even people without a robust coding background can create apps with Skuid, too—as long as they understand their businesses processes and their database:
“With Skuid, I’m definitely saving time. I’m not having to spend extra hours on learning a whole new language, learning how to develop,” says Natalee Yamasaki, customer success operations specialist. “It’s very intuitive, and the product is just amazing. I’m spending less time, but I’m still able to create this beautiful end product.”
Ready to give Skuid a go? Build better, for free.
