[HN Gopher] Stride Game Engine
___________________________________________________________________
Stride Game Engine
Author : fctorial
Score : 110 points
Date : 2021-06-18 11:55 UTC (11 hours ago)
(HTM) web link (stride3d.net)
(TXT) w3m dump (stride3d.net)
| billfruit wrote:
| Does it support F#?
| crispyalmond wrote:
| I don't see why it wouldn't work with F#. It runs on .NET and
| can interop with C#. Note that I have not tested this and I am
| just speculating.
| csdtx wrote:
| Do we not have enough of these fully featured game engines? Game
| development has become so bloated these days. You need teams of
| hundreds or even thousands of people to create a full game. In
| the PS1 era some of the best games were built by a team of a
| dozen or so people working for 1-2 years. Instead of focusing on
| graphical fidelity I think we should be focusing on lower
| development time, gameplay features/diversity,
| stability/portability and implementation. I have yet to see a
| proper open world game (Think GTA but you can enter every room in
| every building) with good draw distances that don't suffer from
| horrible pop in.
|
| Also how about a game engine where it's easy to build games? The
| WC3/SC2 world editors are great examples, you can get started and
| start building stuff from the start. Even though it's an engine
| made for making RTS maps it's modifiable enough you can create
| FPS games in WC3 if your willing to put in the effort.
| https://www.youtube.com/watch?v=gwtteOIksbo
| JabavuAdams wrote:
| Actually fully featured game engines like Unity have made it
| possible for smaller and smaller teams to build bigger and
| bigger games. Not sure where you're getting your numbers from.
| sinuhe69 wrote:
| One of the hottest game on Steam 2021 Dyson Sphere Program was
| developed by a team of just 5!
| username90 wrote:
| Games requiring a lot of custom code are really under rated
| among indie devs. Most tries to do stuff that are really easy
| to do, like 2d platformers or shooters or puzzle games, but
| hard to code games that gives experiences you can't get in
| other games seems like the easiest way to make a successful
| game with few people nowadays.
| art0rz wrote:
| > Instead of focusing on graphical fidelity I think we should
| be focusing on lower development time, gameplay
| features/diversity, stability/portability and implementation.
|
| > I have yet to see a proper open world game (Think GTA but you
| can enter every room in every building) with good draw
| distances that don't suffer from horrible pop in.
|
| I don't think these are compatible. The majority of man-hours
| are spent creating graphics, not programming features.
| maccard wrote:
| > The majority of man-hours are spent creating graphics, not
| programming features.
|
| Technically, yes but it's not as heavily swayed as you might
| think. On the four AAA projects I've worked on, it's been
| roughly 60-40 art to programming/technical design (think
| level scripters). There is definitely a sizeable amount of
| the man hours spent by engineers writing C++
| username90 wrote:
| Programmers writing C++ to support graphics also goes in
| the art bucket though. If there is a performance bottleneck
| on art, or if you need to load/unload art resources since
| they take tons of memory, or if they are tweaking shaders,
| then that is still work done to make the art.
| maccard wrote:
| > Programmers writing C++ to support graphics also goes
| in the art bucket though.
|
| Hard disagree here.
| username90 wrote:
| You have to do it to support modern game graphics. It is
| something they could skip if they didn't do modern game
| graphics. It is a cost of modern game graphics. Doesn't
| matter if you disagree, this is a fact.
|
| So if you divide it up, how much work is done to support
| the art and graphics of the game, and how much is done to
| support the gameplay, you get a much greater ratio art to
| game than 60/40.
| Tossrock wrote:
| Sounds like you might be interested in Roblox - fully solved
| out of the box multiplayer, Lua based development, no shader
| access or particular graphical fidelity concerns. Some of the
| most successful games of the current era were developed by
| single teenagers.
| MeinBlutIstBlau wrote:
| Crash Bandicoot was made by 2 people, a dev and an artist.
| midnightclubbed wrote:
| Do you have a source for that? Wikipedia (and the game's
| credits) have a core development team of 8 (plus audio,
| production, testing etc).
| Trasmatta wrote:
| There are still tons of games made by tiny teams, even moreso
| than at any point in the past probably. The indie dev scene is
| huge, and some of the best games of the last 5 years have been
| built by teams is 10 or less.
| spywaregorilla wrote:
| > Game development has become so bloated these days. You need
| teams of hundreds or even thousands of people to create a full
| game
|
| Hard disagree. The accessibility and availability of free
| resources is higher than ever before for solo devs. AAA games
| take large teams because they have more content, and a larger
| diversity of content than older games.
|
| > Instead of focusing on graphical fidelity I think we should
| be focusing on lower development time, gameplay
| features/diversity, stability/portability and implementation. I
| have yet to see a proper open world game (Think GTA but you can
| enter every room in every building) with good draw distances
| that don't suffer from horrible pop in.
|
| That's because it's a difficult problem and machines don't have
| unlimited resources. Draw distances are a graphical fidelity
| problem, so I also find it ironic that this is your first idea.
| jayd16 wrote:
| Agreed. Its never been easier to make such detailed games but
| he bar for a game anyone cares about is much much higher.
| gentleman11 wrote:
| C# is nice to program in, but I remember the unity garbage
| collector used to give me anxiety, it was a nightmare. Every tiny
| thing you do you have to second guess because it might allocate
| behind the scenes and you get these awful performance hiccups if
| you miss too many of these
| jayd16 wrote:
| Its really not a big deal. Just preallocate as much as you can
| behind a load screen, and use pooling on your tight loops.
| You'd be doing this in any language, anyhow. If you really want
| to go overboard, C# has Span<T> now, if you want to do your own
| arena allocation.
|
| At least in Unity, the profiling is fairly well established so
| its easy to hunt down allocations.
| gameswithgo wrote:
| How long ago? Compared to 5 years ago C# performance has
| improved dramatically, and you have more tools available to
| control memory usage.
|
| That said, if you are trying to make a competitive first person
| shooter than never dips below 144fps, C# may not be a good
| choice. But there are popular competitive shooters out there
| using Unity, like Tarkov. But who knows how much pain they went
| through to get the performance they needed?
| mostelato wrote:
| Curious - how come so many engines don't support Mac? I am
| constantly baffled by how few games exist for my MacBook Pro.
| gameswithgo wrote:
| You can use opengl or vulkan and target every platform, except
| mac. A very old version of opengl still works on mac but its
| not supported any more.
| Mikushi wrote:
| Apple is extremely developer hostile so it's not that
| surprising.
| pjmlp wrote:
| Apple is extremely friendly to developers targeting the Apple
| ecosytem.
|
| Unreal and Unity do support Apple devices.
|
| Plus, unlike Android, they actually provide tons of tooling
| for game development and graphics programming on iOS.
|
| Google tells you to clone github repository from Vulkans
| shaderc.
| mhuffman wrote:
| > Apple is extremely friendly to developers targeting the
| Apple ecosystem.
|
| Yeah, I don't know where the hell you get that!
|
| Do they offer emulators for non-Mac developers to target
| their ecosystem?
|
| Do they make even simple development onerous if you are on
| a Mac and do target their system, but have the audacity to
| want to share the app with someone else not in the same
| room with you?
|
| You want to make a free app for your business targeting our
| ecosystem? Pay us bitch! Also, while we're at it, pay us
| every year from now on! Whoa! You also want to put it on
| our store, pay some more you fucking pay-pig!
|
| > Plus, unlike Android, they actually provide tons of
| tooling for game development and graphics programming on
| iOS.
|
| ... read, we are so locked into and starved for hardware
| options that it is easy to release a few libraries that
| will work for your app ... for now! Has your business not
| changed at all and your app doesn't need any special
| privileges ... but it has been more than a few years ..
| haha! Go fuck yourself, sincerely Apple!
|
| > Google tells you to clone github repository from Vulkans
| shaderc.
|
| Apple makes you get into a personal relationship with them.
| I am not sure that is much better!
| suby wrote:
| Forcing me to pay a dev fee for the privilege of releasing
| software on their ecosystem is not friendly.
|
| Foring me to get apple hardware by discouraging MacOS
| virtual machines is not friendly to developers.
|
| Policing what apps people are even allowed to develop on
| some of their platforms (ie, no custom browser engines on
| ios) is not friendly to developers.
|
| Deprecating support for opengl to push metal, a solution
| which is only available on their platform is not developer
| friendly.
| JabavuAdams wrote:
| I spend more on eating out in a week than that yearly
| Apple developer fee (not ideal, I know). Cost/benefit. At
| some point you realize you're going to die and that you
| can essentially buy more productive time by paying money.
| username90 wrote:
| Most people starts out as students or similar with
| basically no budget at all. To them paying fees to just
| get others to run your program is a huge hindrance, which
| is why it is developer hostile. It isn't hostile to full
| time developers who work on established products, no, but
| it is hostile to the next generation of developers who
| are just starting out and experimenting with things.
| pjmlp wrote:
| Apple is not for hippie developers, is for developers
| that want to make money and understand others like to be
| paid for their work.
|
| Enjoy the developer friendliness of Steam on GNU/Linux.
| jayd16 wrote:
| Forcing you to drop everything and do it Apple's way is not
| friendly.
|
| Forcing you to buy specific hardware and banning
| virtualization to do builds is not friendly. Cloud builds
| is a huge pain. You essentially have to rent full macs from
| MacStadium.
| skohan wrote:
| Apple's developer hostile in general.
|
| They create a narrow space where it's possible to make
| money developing for their platform, but there's a huge
| risk that:
|
| a) they will make a decision which makes your product no
| longer viable, or
|
| b) they will decide to replicate your product as a 1st
| party offering and render you redundant (e.g. tile)
|
| Adopting open standards like Vulkan would be the single
| best thing they could do to support games on their
| platform. Games are extremely high-investment, and having
| to develop against a second back-end like Metal is a
| perfect reason not to support a platform.
|
| Apple's friendly to developers as long as they are willing
| to stay on the reservation, but there is no reward for
| doing so.
| pjmlp wrote:
| Producing development tooling unmatched by FOSS is
| anything but hostile.
|
| Want success with "developers friendly" tools? Try to
| make a business of using Khronos APIs in GNU/Linux games.
|
| Ask Loki how well did it go.
|
| As for Vulkan it is just the same design by committee
| extension spaghetti soup that killed OpenGL, just with
| even more boilerplate.
| skohan wrote:
| Doom 2016/Eternal shipped with Vulkan and they are two of
| the best optimized games ever made.
|
| I don't buy that Vulkan is not a first-class choice for
| graphics. To the extent that it has issues, it's only
| because of (developer hostile) lack of support from major
| software vendors.
| pjmlp wrote:
| Pity that outside Android 10+ and a couple to Swift
| ports, most AAA studios don't care.
|
| Now that Microsoft owns Doom, let's see how long it holds
| its Vulkan implementation.
| skohan wrote:
| I don't see what this has to do with your argument
| ykafia wrote:
| I might be wrong but from what i read on the internet,
| MacOS don't provide direct access to GPUs, you have to go
| through the OS GPU API to do your GPU computation. On
| Windows and Linux, there is no abstraction, OpenGL and
| Vulkan access the GPUs directly. I'd say it's safer to go
| the MacOS way but it's a bother for those who want a
| unified API
| pjmlp wrote:
| You are wrong, there is no way to access the GPU directly
| unless you are the driver author.
| flohofwoe wrote:
| It's a chicken/egg problem. There are no games on Mac because
| nobody plays games on Mac, and nobody plays games on Mac
| because there are no games on Mac.
|
| Only Apple has the power to break this cycle by throwing money
| at game developers to reduce the financial risk (same way Epic
| does to get games into the Epic Game Store for instance).
| madpata wrote:
| It's not a chicken and egg problem. It's Apples
| fault/intention.
|
| They had really bad support for OpenGL and wanted developers
| to use Apple's Metal API. But developers stayed on DirectX
| (Windows-only) or OpenGL/Vulkan for Linux/Windows/Android
| crossplatform. It just wasn't economically viable to develop
| for Mac.
| flohofwoe wrote:
| The importance of cross-platform 3D-APIs for game
| development is vastly overrated though. The problems of the
| Mac as gaming platform are much more "holistic" (but yes,
| in the end it's about the economical viability).
| skohan wrote:
| They're kind of trying to do that with Apple Arcade, but from
| what I've seen they don't really understand the market enough
| to make an interesting offering.
|
| It's insane to me that they're failing so badly at it:
| Apple's amazing at building brands, but gaming is _huge_ with
| people under 30, and it might get harder to sell people a
| computer you can 't run AAA games on.
|
| Google could have eaten iPhone's lunch with gen Z with Stadia
| if they invested in it properly, but they didn't manage to
| make it work
| Sandvich wrote:
| The way I see it, unless you're developing exclusively for
| Apple platforms, it's not worth the effort to build something
| with Metal. There are translation layers like MoltenVK that can
| help, but that still requires a lot of effort for what is
| likely a very small market segment.
| skohan wrote:
| It's not _that_ hard. With SDL2 /GLFW and MoltenVK you are
| 90% of the way to a cross-platform codebase.
|
| That said I can understand why there's not a lot of
| investment in mac, since Apple's shown to be very developer-
| hostile as far as games, and the market is pretty small
| outside of mobile games which are kind of a separate thing.
|
| There's some potential with m-series processors - now there's
| basically one SOC to target for everything from an iPad to a
| desktop, so it's sort of like consoles where there's a very
| consistent hardware target to develop against.
| pjmlp wrote:
| As I wrote in a sibling comment, Unreal and Unity do support
| Apple devices.
|
| Plus, unlike Android, they actually provide tons of tooling for
| game development and graphics programming on iOS.
|
| Google tells you to clone github repository from Vulkan's
| shaderc.
|
| Vulkan and OpenGL tooling on Android is a joke, to the point
| Unity are Unreal the official tools.
|
| https://developer.android.com/games#develop-content
|
| While Macs have all of this at their disposal,
|
| https://developer.apple.com/wwdc21/sessions/?q=Metal
|
| The only thing Android Games SDK has is a frame pacing API!?!
|
| https://developer.android.com/games/sdk
| jayd16 wrote:
| I don't understand how you can respond with how great Apple
| dev is when the question was why does no one do it. If its so
| great, what's the problem?
| d0100 wrote:
| I've tried a few times to start making a game I consider
| "simple", the basics are:
|
| * Animated character * Top down view * Grid based floor *
| "Default" RTS/MOBA physics
|
| I've tried both Unreal and Unity but I've always found myself
| blocked by having to find out how to make something look like
| water, how to make an animation sync with movement, how to
| customize movement to something already familiar, etc
|
| This means I can't actually make a game if I first don't make my
| own pretty much everything
|
| I think that more than game engines, we need game frameworks that
| provided game designers with presets that present "solved" game
| mechanics, like water styles, ground tiling, precise character
| animation for any view angle, character movement, etc
|
| It would be nice if we could have a "democratization" of video
| game development anytime in my lifetime
| gameswithgo wrote:
| There are lots of asset packs for things like that. So you can
| get stuff done if you don't mind things not looking and not
| performing exactly the way you want, and don't mind your game
| having assets that people might recognize from other games!
|
| Otherwise yeah, making a game is hard.
| dvfjsdhgfv wrote:
| You seriously need to go through a few standard unity tutorials
| they offer just after installing, it will save you a lot of
| time and the blocks you've mentioned.
| EamonnMR wrote:
| It helps to start with a less complex game and learn the basics
| of how the engine works. I know in Godot at least (and I assume
| Unity is miles ahead) there are prefab things to do what you
| describe but you will need to know how to fit them together.
|
| Another option would be to fork an existing foss RTS game, like
| Spring, Warzone 2100, BOSwars, etc.
| qayxc wrote:
| Maybe I'm missing something, but aren't pretty much all of
| these issues solved using Blueprint/Prefabs in UE/Unity?
|
| Water has a prefab:
| https://docs.unity3d.com/2019.1/Documentation/Manual/HOWTO-W...
|
| Tiling is standard for Terrain Layers:
| https://docs.unity3d.com/2019.1/Documentation/Manual/class-T...
|
| Syncing animation and movement could be solved using root
| motion: https://docs.unity3d.com/Manual/RootMotion.html
|
| Etc.
|
| And then there's whole starter packs for all kinds of genres
| that include solutions for all these as well.
|
| IMHO the two major players have you covered quite well
| -\\_(tsu)_/-
| d0100 wrote:
| I can find the resources on how to do those things, I have a
| compiled list of tutorials & code with what I wanted, but
| that still leaves me with a ratio of 80% programming vs 20%
| game design
|
| It'd be nice to be able to create a character and just attach
| preset behaviors: walk like Dota, add jump, etc
|
| Then I can focus 80% on game design and 20% on development,
| this way I can know upfront if my game is worth polishing and
| customizing those presets
| sombremesa wrote:
| > It'd be nice to be able to create a character and just
| attach preset behaviors: walk like Dota, add jump, etc
|
| You can already do this via the Unity asset store.
|
| But I'm guessing in addition to having your dream
| engine/working environment, you also don't want to pay a
| dime for it.
|
| They do say you get what you pay for.
| d0100 wrote:
| I have searched in the Unity asset store, and there is
| either not what I need, or what I need is in several
| different packages that aren't seamless to use together,
| or the cost of everything is more than my monthly salary
| (non US here)
|
| > But I'm guessing in addition to having your dream
| engine/working environment, you also don't want to pay a
| dime for it.
|
| Before Unity came out the same could be said about people
| wanting a more accessible engine, no?
|
| I'm fine with Unity's and Unreal's pricing models, I just
| want a more creator friendly game editor that isn't
| Roblox
| sombremesa wrote:
| Really?
|
| https://assetstore.unity.com/packages/3d/characters/moba-
| mov...
|
| Come on, man.
| d0100 wrote:
| I have already done myself what that package provides
| [deleted]
| Marazan wrote:
| You don't need fancy animations or water that looks like
| water to work on the game design.
|
| Use place holders for everything
| elefanten wrote:
| Agree with this. Sounds like you want to prototype game
| designs more than code/utilize final implementations. The
| standard advice you'd get in game dev is to use super low
| production value assets to prototype. People even often
| "paper prototype" or use other completely non-digital
| media.
|
| I agree with the sister comment to parent that suggested
| something like Game Maker. Those tools are simpler and
| more usable out the box than game engines.
|
| If you want the feeling of completing a simple game as
| you go, and seeing your (near-)final implementations of
| elements as you hammer them out -- that's fine as a
| learning exercise. It will probably be inefficient (as
| you may change you mind about things later on that you
| already spent a bunch of time implementing/polishing),
| but it can be a cool way to learn. However, for that, you
| may run into what some other comments are saying: you'll
| have to figure a lot of custom stuff out as you go.
|
| Edit: There's a good series[0] where a game critic /
| indie game dev makes 12 games in 12 months. He uses Game
| Maker Studio 2 and the episodes go back and forth between
| concept/design and execution.
|
| [0]
| https://www.escapistmagazine.com/v2/category/v2/yahtzees-
| dev...
| void_mint wrote:
| Whiteboxing/Greyboxing/whateverboxing is one of the most
| important processes that all too many hobbyists don't do,
| which causes them to burn out on gamedev. They want to
| _see_ everything working with how it looks in their head,
| but in reality the game mechanics vs. visuals are very
| different skillsets that can take a lot of time to
| master. I would recommend most new gamedevs spend all
| their time using just default objects in their respective
| engines. Literally just white/grey shapes that act on
| user input. If the mechanics feel fun with whiteboxes,
| they'll feel more fun with actual
| models/sprites/whatever. But on the flipside, you'll
| never know if your mechanics are fun if you never make
| them because you're too busy worrying about water
| animations.
| pjmlp wrote:
| It seems to me you would be better served with something
| like GameMaker.
| tomc1985 wrote:
| Sorry dude, learn the skills and get it done
| JabavuAdams wrote:
| Unity Asset Store has done this. Unreal / Blueprints fulfill
| the same role, but I'm less familiar with them.
| gentleman11 wrote:
| If you want a game template, there are lots available in the
| gaming marketplaces. Your game will be almost identical to its
| competitors though
| TrainedMonkey wrote:
| Sounds like you don't want game engine, you want a fully coded
| game with a map maker.
| bee_rider wrote:
| Wonder how much of the current gaming ecosystem is originally
| rooted in the Warcraft 3 map making scene.
| elefanten wrote:
| If you're asking, you may know this already, but the whole
| MOBA genre (eg League of Legends) came from custom war3
| maps.
| spywaregorilla wrote:
| It's a learning curve. You don't need to reinvent all these
| things, but you do need to learn the tooling.
|
| * Animation sync with movement in unreal is done either by
| embedding root motion into your animations or just trying to
| use a blendspace to make movement animation fluidly transition
| with your speed.
|
| * Movement is customized for basic characters via the character
| movement controller component.
|
| * Water is a hard problem but the basic ue4 water
| implementation is good: https://docs.unrealengine.com/4.26/en-
| US/BuildingWorlds/Wate...
|
| * Top down view is just a camera facing down
| lazypenguin wrote:
| Yes I agree with you. Even with unity/unreal/etc. it's still a
| monumental amount of work to have a game. Personally, I have
| more fun modding a fully functioning game than I do starting
| from scratch.
| mihaifm wrote:
| Modding is a totally underrated thing right now, but I feel
| it might become big in the future. Someone just needs to come
| up with a solution to both keep mods free and incentivize mod
| authors.
|
| The way I see it, the big boys create games that acts as
| platforms and users freely create content of their own using
| these platforms. Bethesda/Microsoft might be in a good
| position to achieve this, they have good modding communities
| around their other games, really interested what their next
| title brings to the table, hope they don't blow it up like
| the last time they tried to monetize mods.
|
| You also have something like Roblox, where the concepts of
| game development and modding kinda blend together, so it's
| definitely a trend to keep an eye on in the future.
| madpata wrote:
| You should keep an eye out for S&Box! It's the successor to
| the popular Garry's Mod. Garry's Mod is, imo, the sandbox
| and modding game and I think that S&Box will be even
| better. It's based on the Source 2 engine, and the main
| developer Garry has collected a lot of experience with
| GMod.
|
| While GMod mods are based on Lua, S&Box uses C#, which is
| an awesome choice, imo. C# is a bit more verbose than Lua,
| but it probably enables mods of higher quality.
|
| It's not out yet, but some keys get distributed to chosen
| people. Sadly, I'm not one of those.
| mihaifm wrote:
| Thanks, subscribed to their subreddit. Never had the time
| to jump into Garry's Mod but might give this one a try
| when it comes out.
| mekkkkkk wrote:
| All you could ever ask for is available in the Unity asset
| store. A lot of it free.
| codefreakxff wrote:
| I'm not advocating for Roblox because it's quite terrible. But.
| They did make it stupidly simple to make stupid 3D games. If
| you like getting eaten and slowly have poop stuck to you while
| falling through the digestive system until you are pooped
| out...
|
| I have not tried godot yet but it's something I'm going to get
| to soon
|
| https://godotengine.org/
| isiahl wrote:
| Why is Roblox terrible?
| madpata wrote:
| Maybe keep an eye out for S&Box, the successor to Garry'sMod.
|
| It's not out yet, but uses the Source 2 engine and C# for
| modding, and will probably have an active community from
| launch.
| Applejinx wrote:
| Godot is coming up mighty quick. I've been favorably
| impressed. Also, if your concept is 2D, it's way beyond the
| 3D-centric game engines for that task: might not be the
| question being asked, but it's worth a thought.
| hesdeadjim wrote:
| There is no easy path to mastery with any engine out there.
| Games are hard and the learning curve is intimidating. Start
| small and grow from there.
|
| For instance, take a tutorial like this and understand 100% of
| everything going on:
|
| https://learn.unity.com/project/bolt-platformer-tutorial
|
| Visual scripting in Unity or Unreal, combined with asset store
| packages, can get you _very_ far. A buddy of mine shipped a
| game on Steam built entirely in PlayMaker. But he had spent
| five years learning and mastering the tool and the engine.
| YMMV.
| bitwize wrote:
| The Unity marketplace has lots of things like that.
|
| Only drawback is, you run the risk of players being able to
| identify all the readymades you used. Use too many, and your
| game will feel like an unoriginal "asset flip".
| brundolf wrote:
| I think that's just the nature of game dev. CRUD apps seem like
| they're all basically the same, yet we still hand-code them
| because there are always weird quirks and edge-cases. This is
| 10x more true for games (at least, remotely interesting ones).
| A game engine that supports exactly the kind of game you're
| wanting to make, out of the box, is not really going to support
| any other kind of game (or even very novel ones within the same
| genre). So the "everything" engines have to stick to the very
| most basic, least-common-denominator features, and even those
| are sprawling and require compromise.
| toddmorey wrote:
| I read this as "Stripe Game Engine" and honestly got rage about
| just how much product they are releasing.
| KronisLV wrote:
| Here's a video on the engine by the Gamesfromscratch YouTube
| channel: https://www.youtube.com/watch?v=ugFRSKFMgzo
|
| I would actually suggest that anyone interested in game engines
| give that channel a look, lots of good stuff over there.
|
| Personally, i rather enjoy seeing new game engines pop up,
| however i would say that Paradox/Xenko/Stride is about as obscure
| as the NeoAxis engine (which also uses C# as their development
| language), even if some of the features seem nice. I'm not
| entirely sure why Paradox/Xenko/Stride was renamed that many
| times, though, it kind of hurts its recognizability.
|
| As for the people asking about what engines to use, i think the
| other comments in this thread have some good arguments. My
| summary for which engine to choose would be as follows:
| - In case you want to develop an FPS game or something in a
| similar genre AND feel comfortable with writing C++ for the
| performance intensive parts, consider Unreal (or if you just need
| something really pretty) - In case you want to develop a
| game with an engine that will have most of the functionality that
| you'd need out of the box, a good asset store for the things that
| aren't included and if you're comfortable with using C#, consider
| Unity (UNLESS you need multiplayer, since currently the engine is
| slowly migrating across technologies and AFAIK they still didn't
| have a good networking solution) - In case you want to
| develop a 2D game of simple to medium complexity, or want to mess
| around with some basic 3D stuff, consider Godot - In case
| you don't necessarily expect to sell your game in the future, but
| would prefer just to learn bunches, consider writing your own
| engine, or using SDL/SFML/LWJGL or another solution like that
|
| Of course, others might disagree, but personally i've found that
| only using the more popular engines makes sense, given the
| abundance of tutorials, blog posts, examples, assets and even the
| quality of the documentation, in most cases.
|
| Here's another video by said YouTube channel, called "Choosing A
| Game Engine in 2021": https://youtu.be/rK6ulQaOpso
|
| In case anyone has any information on what Stride does better
| than those other engines, or perhaps has a unique perspective on
| why using it would be a good idea, feel free to respond!
| qayxc wrote:
| > - In case you don't necessarily expect to sell your game in
| the future, but would prefer just to learn bunches, consider
| writing your own engine, or using SDL/SFML/LWJGL or another
| solution like that
|
| Make that "in case you never want to actually _finish_ your
| game :)
|
| The greatest pitfall with rolling your own is that you soon be
| stuck spending 90%+ of your time working on the engine instead
| of the actual game.
|
| There's just too many moving parts involved and even libraries
| like SDL only get you so far. I'd VERY strongly recommend
| against developing your own game engine IF your goal is to
| actually make and finish a game.
|
| In case it's more about the learning experience and finishing a
| game is just nice to have, rolling your own engine is fine.
| AnIdiotOnTheNet wrote:
| > Make that "in case you never want to actually finish your
| game :)
|
| I disagree. People overestimate how much of a time sink
| "writing your own engine" is. Using a generalized engine
| often suffers from the second system effect, in the end
| reducing your flexibility while not really saving you that
| much time.
| qayxc wrote:
| Let's not guess and simply checkout a fair comparison, like
| this gentleman did:
| https://www.youtube.com/watch?v=tInaI3pU19Y
|
| From his perspective as an experienced developer, it took
| 3.4x more effort to implement a very basic project versus
| using a fully featured engine. And that's ignoring the
| editor part, not to forget.
|
| I'd call a factor of 3.4 quite significant. In more general
| terms, it's the difference between actually finishing a
| game in a 31/2 months vs a full year. In other words, you
| could finish 3 projects in the time it takes you to fully
| handcraft one, with the added advantage of OOTB multi-
| platform support. So reality seems to disagree with your
| "not really saving you that much much time" assumption.
|
| It's the small conveniences that add up quickly:
| exporters/importers for assets, in-game editors, readily
| available prefabs/blueprints for all kinds of components,
| stuff like that. Of course it's not rocket surgery to use
| SDL and a handcrafted engine for a quick little project.
|
| Yet, I've witnessed far more game projects die (especially
| by beginners) that went the handcrafted all-the-way route
| versus people using game engines.
| username90 wrote:
| Rolling your own is mostly a fixed cost endeavour. Taking
| 3.4x more time on a week long project isn't that bad when
| considering that most projects takes years.
|
| And then you have to consider that the guy got 10x the
| performance on his hand rolled project, getting unity to
| similar levels of performance would likely take way
| longer than just using his own engine.
|
| > Yet, I've witnessed far more game projects die
| (especially by beginners) that went the handcrafted all-
| the-way route versus people using game engines.
|
| If you don't have the skills required to make your own
| game engine then you shouldn't do it. You shouldn't learn
| how to make a game and how to make a game engine at the
| same time.
| bitwize wrote:
| Writing a basic engine takes no time at all.
|
| Writing a complete engine that works across all major
| consoles plus Windows and mobile, with all the features
| designers might need including editing and scripting
| capability, is a HUGE time sink.
|
| If you intend to sell your game, stick with Unreal or Unity
| and save yourself a lot of time and hassle.
| midnightclubbed wrote:
| I think it depends very much on how much engine you need. A
| simple renderer (in 2d or 3d) is a fairly low time
| investment assuming you are a strong C / C++ programmer.
|
| However every thing you add on top of 'draws stuff to the
| screen' adds at least the same amount of time again.
| Physics, animation, editor, UI, audio, streaming,
| packaging, asset import, networking. Plus each one of those
| new systems may require new features from the existing ones
| in order to work (eg animations will need asset import
| support, shader support, and renderer support).
| KronisLV wrote:
| Yep, overall i agree with you. Of course, there are a few
| people who actually write their own engines AND finish their
| games, but they're probably in the minority.
|
| I guess what i tried to say is that if your goal is to make
| money, then there are lots of ways to save on time and
| effort, in the case of gamedev that being using existing
| technologies and solutions, possibly even assets (as long as
| you don't mix art styles that don't match).
|
| It's much the same as wanting to produce a corporate CRUD web
| app vs writing a personal blogging engine for a passion
| project or simply for own amusement. Both can result in
| finished products, yet the motivations for each would be
| drastically different.
| TillE wrote:
| There's a big difference between "writing your own engine" (a
| bottomless pit of features your game probably doesn't need)
| vs writing a 2D game with a framework like SFML.
|
| Engines like Unity can be nice, but they can also be clunky
| and opaque and get in your way, especially if you're doing
| something outside the norm. It can be simpler to just write
| the code you need, as you need it. That said, of course you
| should use an off-the-shelf engine for a 3D game if you ever
| hope to finish it.
| whateveracct wrote:
| > Of course, others might disagree, but personally i've found
| that only using the more popular engines makes sense, given the
| abundance of tutorials, blog posts, examples, assets and even
| the quality of the documentation, in most cases.
|
| But then I have to use their languages and abstractions instead
| my preference, Haskell. Can't throw the baby out with the
| bathwater!
|
| Well, I guess Haskell makes rolling your own engine just
| library composition and standard abstraction, so the decision
| making in that world is definitely not the same as mainstream
| gamedev.
| xNeil wrote:
| That is a wonderful channel, I can attest to that. Superb
| content, and he's focused on one thing - testing, reviewing and
| recommending game development tools.
| bitcoin01 wrote:
| How does it compare to Unity?
| ggambetta wrote:
| Or Unreal. I think in this day and age any new game engine
| should start with "why use this and not Unreal or Unity".
| adamdusty wrote:
| I can't stand this mentality, but here is a list of reasons:
|
| * ECS is built in, not tacked on (unity DOTS)
|
| * Also supports unity/ue actor model style
|
| * Gives you complete control over rendering, access to
| opengl/vulkan/d3d12 context
|
| * Built in scene streaming (stream objects in and out as
| needed, similar to UE5 terrain chunking
|
| * Fully built in C#, runs on .NET 5 (xplat), and uses the
| latest version of C#. I don't know which version unity is
| stuck on
|
| * The "engine" is just a tool, you can use stride as a
| framework and make a code-only project (my personal reason
| for using it when I do)
|
| * MIT license
|
| * Aysnc scripting capabilities
|
| * Technically supports dev on linux (code-only)
|
| * FOSS
|
| * On top of all that it was developed by Silicon Studios, a
| company that actually makes money off of real-time rendering
| jokoon wrote:
| Or godot
| nrjames wrote:
| Unity and Unreal are giant resource-hungry game engines.
| There are plenty of people making games who only need a
| fraction of what those two provide. Engines like Stride and
| Godot -- or any number of other smaller engines -- can be
| easier to work with if you're resource constrained or looking
| for something more simple.
| debacle wrote:
| Your #1 resource is time. Why would you devote thousands or
| tens of thousands of hours to a game and not use the most
| powerful tools?
| skohan wrote:
| It depends on the game. Unreal for example is optimized
| for large teams, and collaboration between different
| kinds of professionals (programmers, artists, level
| designers etc.). If you're doing a one-person project
| relying on procedural generation and pixel graphics, you
| might be more productive with a much simpler game engine
| with a much shorter code-build-run loop
| debacle wrote:
| Like Unity?
| pjmlp wrote:
| Unity is on the same league as Unreal, with the
| difference to target developers that rather use C#
| instead of C++, other than that the complexity is the
| same.
| andybak wrote:
| That's just not true. Unity works very well for solo devs
| and the build/run cycle is very fast.
| pjmlp wrote:
| Exactly because of that unless there is a whole team of
| designers, level builders and artists alongside the core
| devs, there is more ways to spend time than getting a PhD
| level knowledge on AAA engines capable of producing
| Hollywood class 3D movies.
| debacle wrote:
| I have tried out Godot and many, many other game engines
| in the past. They aren't there yet. Even as a hobbyist, I
| find Unity much more easy to use, and even still I'm
| tempted to learn Unreal simply because it seems more
| powerful and well architected under the hood.
| pjmlp wrote:
| They are where Unity 3.0 used to be around 10 years ago.
|
| However Unity now is capable of supporting such kind of
| productions, with the respective increase in learning
| complexity and development teams scalability,
|
| "Oddworld: Soulstorm at Unity GDC 2019"
|
| https://www.youtube.com/watch?v=a8uAUPGZb3I
|
| "The Heretic short film"
|
| https://www.youtube.com/watch?v=iQZobAhgayA
|
| Using such engine for a basic 2D tiles game or shooter is
| already over budgeting.
| cridenour wrote:
| Because 99% of people using these engines are hobbyists
| and want to use something that works for them.
|
| I personally prefer Godot, its node structure makes sense
| with my mental model of the games I tinker with. And it
| has enough there that if I did decide to ever finish a
| game, I could. That's all I need.
| nrjames wrote:
| Why wouldn't you buy a Bugatti to take you to the grocery
| store? The "most powerful tools" aren't always the
| easiest or fastest to use.
| debacle wrote:
| If the Bugatti is free, why not use it? Unity is very
| easy to use, and it gets easier over time. They keep
| making paid features free, and once ECS is mature (in the
| UI, I know it's production ready), I think it's going to
| have a huge positive impact.
| lobo_tuerto wrote:
| OK, what about a helicopter? I think that better conveys
| parent's point...
| pizza234 wrote:
| Money, obviously. This engine has a permissive license, MIT.
|
| The question is rather what one can conveniently do with it,
| in the context of the given game, when compared to a big-name
| engine.
|
| Possibly, for non-demanding games, smaller engines are a good
| tradeoff between performance/features and cost. Godot, for
| example, is free, but AFAIK it doesn't have a very efficient
| culling (yet)1, so for smaller games, it may still be worth
| the savings.
|
| 1=https://www.gdquest.com/tutorial/godot/3d/optimization-3d
| spywaregorilla wrote:
| Unreal is free for the first million in revenue
| linspace wrote:
| Why use Linux or not Solaris? Wait... Solaris is not really
| that relevant anymore.
|
| I actually get your point but I don't think you should frame
| the differences as a sales pitch. Most probably people
| interested are engineers looking for some innovation. So the
| question is not "why use this" but instead "why is this
| interesting"
| Yaina wrote:
| When Discord was relatively new they had a comparison table
| with Skype, TeamSpeak and other platforms. As a long-time
| TeamSpeak user, I found that very helpful at the time,
| because it helped me understand what Discord wants to be.
|
| With Stride it is kind of similar. I don't expect an open-
| source engine to have the same set of features as Unreal,
| but they should tell me what they think they are good at!
| Especially in comparison to Godot, which is a direct
| competitor in the open-source landscape.
|
| The page talks a big game, and makes big claims. So
| honestly I'm a bit sceptical :/
| TranquilMarmot wrote:
| Would also be curious in a comparison with Godot, which is
| another FOSS game engine.
| eliseumds wrote:
| Stripe has been releasing so many new products lately that I read
| this as "Stripe Game Engine". Damn Fridays.
| Topgamer7 wrote:
| You are not alone. Definitely did a double take on this one.
| arduinomancer wrote:
| With this release you can now charge people's credit cards for
| micro-transactions directly from the GPU!
| fastball wrote:
| Don't give them any ideas...
| brylie wrote:
| If you want to make 2D or 3D games with cross-platform support,
| the open-source Godot Engine is a really great choice:
|
| https://godotengine.org/
| Q6T46nT668w6i3m wrote:
| I love Godot but it's a stretch to describe it as multi-
| platform when it doesn't support any of the consoles.
| Especially when compared to Unity or Unreal.
| brylie wrote:
| To be clear, games made with Godot can be exported for
| Windows (and UWP), macOS, X11 (Linux, *BSD), Android, iOS,
| and Web
|
| https://docs.godotengine.org/en/stable/about/faq.html
| egypturnash wrote:
| Games made with Stride: presumably zero, or they would be showing
| them off on the front page of the site.
|
| What makes Stride unique besides "it's MIT licensed!"? The site
| sure doesn't tell me.
| Applejinx wrote:
| The Godot engine is MIT licensed. So...
| fotad wrote:
| It was called Xenko.
| krak12 wrote:
| And it was a complete failure
___________________________________________________________________
(page generated 2021-06-18 23:01 UTC)