[HN Gopher] My first game with Carimbo, my homemade engine
___________________________________________________________________
My first game with Carimbo, my homemade engine
Author : delduca
Score : 150 points
Date : 2024-10-08 17:13 UTC (5 hours ago)
(HTM) web link (nullonerror.org)
(TXT) w3m dump (nullonerror.org)
| chainwax wrote:
| _because code is like pasta_
|
| In more ways than one
| delduca wrote:
| You got it!
| ashleyn wrote:
| Conventional wisdom dictates; make a game or make an engine. If
| you're making a serious effort at actually delivering a game,
| then you may want to use an existing engine. However it's also a
| nice challenge to write an engine of your own. And perhaps some
| true legends can actually do both - just look at Animal Well.
| delduca wrote:
| I totally agree, or if I were in a game jam, but in my case
| it's just for fun. I used to be a gamedev and don't intend to
| go back.
| Profan wrote:
| Heck, I'm a gamedev right now and I completely understand the
| not going back bit
| chongli wrote:
| The author made this game for his son. I think this qualifies
| more as a hobby/side project than a serious effort at
| delivering a marketable game. In the hobby case I think the
| conventional wisdom no longer applies. That puts this sort of
| project in line with folks building hot rods or restoring
| classic cars right down to the last bolt. Rebuilding a car's
| engine is a similar exercise which rarely makes commercial
| sense but can be an absolute joy for the hobbyist mechanic!
| sunrunner wrote:
| It's always worth remembering that when people suggest not
| writing an engine the sentiment is usually "Don't try to write
| a Unity/Unreal/Godot equivalent".
|
| This is very reasonable advice. Those tools are software
| behemoths, by design, because they have to account for all
| possible use cases and give people a way of opting in to any
| possible combination of provided features, along with providing
| various abstractions (scene hierarchy, gameplay scripting,
| graphics API abstraction, materials, VFX, animation state
| trees, etc., the list is seemingly endless) as they need to
| support making essentially any kind of game.
|
| And not only are they software behemoths, they also represent a
| huge amount of mindshare in the form of documentation, support,
| community, customer-provided content, (marketplace assets) and
| so on.
|
| If you're making a game and you know what your requirements are
| up front, it's possible you just don't need most of what the
| engine provides.
|
| If you don't need to support multiple graphics APIs, you can
| get away with just using the specific API yourself (and then
| you don't need a different shading language). If you don't need
| complex VFX you might not need a VFX graph. If your rendering
| code is closer to your gameplay code you don't need a separate
| gameplay scripting system, you could actually write your
| gameplay code in the same language and build them together.
| Don't need rigid body simulation? Great! Throw that away. Don't
| need RVTs? Goodbye. And so on.
|
| That doesn't mean throwing away some engine-like structure,
| you'll almost certainly still end up with some representation
| of a scene, but if your requirements are minimal you can get
| away without most of what's in the above tools.
|
| And there's always the middle ground (that seems to get
| forgotten). Open source rendering libraries such as Ogre
| integrated into your own program, such that your game stops
| being a completely isolated component that sits on top of the
| engine and is regular code integrated with rendering (and so
| on), while being a more cohesive whole.
|
| Of course, if you need the features in Unity or Unreal and you
| don't have five years to burn then maybe you should just use
| them after all.
| braden-lk wrote:
| Congrats! Game engines seem like such a gratifying pursuit that
| flexes every aspect of one's skills. I just started reading Game
| Engine Archicture; if I can ever make the time I really want to
| take a crack at an engine.
| delduca wrote:
| This book is really good; I've already gotten a lot of ideas
| from it.
| dakom wrote:
| Love that book, great resource for lookup up all kinds of
| programming topics, whether game related or not
| shepherdjerred wrote:
| Game programming patterns is also an excellent book. I
| referenced both of these when writing my engine.
| hoten wrote:
| It's really a bottomless pit of interesting technical projects.
| Careful, if your game engine has users other than yourself, it
| is also a bottomless pit of feature requests and bug reports.
|
| Source: me
| litenboll wrote:
| Very cool to see someone actually making a game in their hobby
| engine!
|
| Regarding the asset prefetching, you mention that they are loaded
| lazily. Maybe I'm misunderstanding but to me prefetching and lazy
| loading are the opposite (i.e. you would prefetch during a
| loading screen in order to avoid loading things on demand since
| it could affect the game loop). Could you elaborate?
| delduca wrote:
| The prefetching works like this: a list of assets is provided,
| and in each main loop iteration, the engine opens and loads a
| single one into memory (an unordered map of shared pointers).
| It would be more effective in a longer game, where as the
| player moves, the assets are already being prepared for use.
|
| There's also a mechanism to collect and remove unused assets
| from memory.
| delduca wrote:
| What I really wanted was to load the textures in a separate
| thread, but 10 years ago, when I tried it, I didn't get good
| results. Maybe now things are different.
| emanuele-em wrote:
| Very cool! Great blog too (add RSS!). You officially have new
| reader.
| delduca wrote:
| Ah, a fellow RSS reader! Thank you!
| samiv wrote:
| To anyone thinking about writing a game engine.
|
| I've been cranking on a 2D engine for over 4 years and have put
| thousands of hours of work into it.
|
| My summary:
|
| If you want to write a game, just write a game. Don't start with
| your own engine since this will suck all your time and you'll end
| up spending 90% on engine and very little getting the game game
| done. Especially so in the beginning when you have no features
| and doing anything in the game requires engine work.
|
| If you choose to create your own engine it's a compelling and
| fantastic domain where problems come in all shapes and sizes and
| you can and get to work with physics, maths, linear algebra,
| audio, rendering, graphics APIs, system level programming, most
| likely native programming AND scripting, game content, technical
| art etc.
|
| But finally the real work is not the engine but the tooling and
| the editor around the engine.
|
| If (when) you rely on free assets from (for example opengameart)
| you can expect no consistency. Not just the art style but just
| the technical part too, like your models are all inconsistent in
| shapes and sizes and axis, 2D content such as textures are by
| default without any meta data etc. So you really need to create a
| ton of tooling so that you can have sensible workflows and you
| can extract and consume the usable and interesting parts of any
| content package easily.
|
| This inevitably leads to the concept of "editor" which easily
| comes with a ton of work by itself that has nothing to do with
| game or game engine per se. For example the concept of "Project",
| windows, resource management, basic editing functionality for
| creating content, undo/redo/ etc. A lot of this is not really
| related to the game or the engine in anyway but you really sort
| of "must have it" if you want to create something that is
| actually usable.
|
| The feature creep is real! But once you get the over a lot of the
| boiler plate and you can actually use your own editor to stuff
| content into your own engine and have it running it's really a
| nice feeling even if nobody else cares!
|
| On the technical side my advice is really to be able to do first
| principles type of thinking. It's of utmost importance to be able
| to break things apart into self contained features and pieces
| that the _game_ can then combine to create bigger constructs.
|
| If you can have your materials scroll textures vertically, when
| you combine that with shapes that are layered and place textures
| onto those shapes that scroll at various multiples of your
| "characters" speed then you've just created "parallax scrolling"
| essentially.
|
| -----
|
| https://github.com/ensisoft/detonator
| fidotron wrote:
| I think the trap people fall into is to have things be overly
| specific in the name of optimization they never get to
| achieving anyway.
|
| For instance, I find you can get massive mileage by declaring
| "(almost) everything is instanced", then you batch it, forget
| it, move on. There are similar shortcuts to be made with
| physics and so on.
|
| The close to ideal engine, in terms of approaches to problems,
| was LittleBigPlanet. That was a small team that were really
| good, but crucially they had the right way to frame the
| problems so as to constrain the emergent complexity of the
| result.
| samiv wrote:
| "I think the trap people fall into is to have things be
| overly specific in the name of optimization they never get to
| achieving anyway."
|
| Yes I agree, writing a specific functionality in the engine
| does allow for more optimal performance but the tradeoff is
| that it's more brittle and more complicated to write and
| maintain.
|
| My personal approach has been to do the first principles and
| avoid writing use-case specific features in the engine as
| much as possible but provide more fundamental functionality
| that the game then combines to create the desired effect.
|
| That being said I've still had to do some concessions and
| move stuff like simple constant velocity game object
| integration to the engine side simply because the perf
| difference between native code doing that vs Lua code are
| just too massive.
| hedvig23 wrote:
| A question then, I have run some game servers in my time
| that had quite advanced console options and scripts to run,
| in Lua, which I then saw as maybe the most common language
| in this area. But I wondered where and why Lua which is its
| own full language was kept to a certain part of the game
| and running instance, and where the other runtime and the
| games main language differed. How is that division of
| responsibility separated or chosen I guess?
| samiv wrote:
| There's no single answer to this, it all depends on the
| game, the engine and the team(s) executing the engine and
| game.
|
| Some typical ways to divide this though is
|
| Some org has "engine" team and "game" team. Engine team
| implements features in the engine itself and game team
| implements _game specific_ features using the embedded
| scripting language.
|
| Engine features are game agnostic and game features are
| specific to games and are scripted / built-on top of the
| engine features.
|
| But sometimes things get muddled as general purpose
| engines are used in games that require specific features
| in the engine itself. Typically the decision is then made
| by a) what kind of feature and how does it fit in the
| architecture of the engine b) what are the performance
| requirements c) who is willing to do the work and
| maintain it
| codazoda wrote:
| I want to write a slot machine "game" for a custom slot machine
| I've built using a piece of MDF, a 32" LCD, and a Linux single
| board computer.
|
| I haven't found much information on how to write a game in this
| style with existing engines. Any advice or resources you would
| point a noob too? I am a software engineer but not a game
| programmer.
|
| It doesn't have to be so good as a real slot machine
| (regulations and such) but I do want to follow the rules as
| best I can. I may not use a real hardware RNG.
| Zircom wrote:
| Maybe re-assess if a game engine is needed for your use case?
| A slot machine doesn't really need a whole ass game engine,
| you could do it with pretty much any graphics library.
| fidotron wrote:
| Isn't this what Godot was originally for?
| Vedor wrote:
| For me, a great middle ground is building an engine similar to
| fantasy consoles (PICO-8, TIC-80, etc.)
|
| This type of project is small enough to plan all the elements
| before you start (which helps to stick to the design and
| therefore to avoid feature creep). Yet, it is still complex
| enough to provide entertainment and challenge.
|
| This approach also has the advantage - at least it is an
| advantage in the case of side projects - that you can see the
| results of your work quite quickly.
|
| I'm working on such a project myself, and it is a great
| experience. Although to tell the truth, it is more of a "game
| creation kit" than an engine.
| matthewkayin wrote:
| I often hear the advice to "make games, not game engines", and
| it's refreshing to hear it from someone who is actually working
| on an engine themselves, because usually when I hear this
| advice it's from devs who use Unity/Godot/Unreal, and the
| implication I get is that if you're not using one of those
| engines, you're wasting your time and won't ever make a game.
|
| But I'd say there's a middle ground between using an existing
| engine and making your own general-purpose engine from scratch.
| I've been making a 2D RTS using C++/SDL, and it's taken me
| longer to write it this way than if I had used an existing
| engine, but in only a few months I've reached the point where I
| have a prototype and have had multiple playtests and am
| iterating the prototype based on feedback from those playtests.
|
| So, while the advice "make games, not game engines" is still
| definitely true, it doesn't mean that if you code "from
| scratch" that your game will necessarily be a long 4-year
| engine project (unless you want it to be!). The trick is to
| keep the code specific to the game you're working on and to
| avoid the urge to abstract everything / make everything
| general-purpose.
| samiv wrote:
| Yep this is of course one possible way too. Make a game from
| scratch but don't make an engine.
|
| I personally I'm not capable of executing this strategy
| because my mind is always thinking in terms of abstractions
| and how to make things so re-usable in another
| context/project when the time comes. For better or worse this
| means that for me any "game from scratch" project will
| immediately turn into "engine + game from scratch" project :)
| Cthulhu_ wrote:
| I suspect it also helps if your engine can ingest content
| made in existing editors, or uses off-the-shelf libraries for
| e.g. the nitty gritty.
| SleepyMyroslav wrote:
| I want to make sure you understand that games as art genre
| and old resource limited and low level programs are far away
| from each other now. And moving in different directions at
| light speed. Unless one builds something that should be
| donated to a museum on release one does not need more of
| C++/SDL.
|
| I say that as someone who keeps working as mostly C++
| contributor into internal game engines for various projects.
|
| I would want people to look forward and make works of art
| that expand what we thought was possible more instead of
| 'learning low level programming'.
| GabeIsko wrote:
| This is exactly why I ended up going for Godot with my own
| hobby game. I have made a lot of progress on a custom game
| engine in the past without actually having a game to make in
| mind. It always gets to the point where you have to start
| making decisions about the tooling, and that becomes your main
| focus.
|
| No disrespect or put downs of anyone trying to do their own
| thing, but Godot is a really great engine and is open source.
| It's kind of miracle that we live in a world where there is a
| viable open source engine for commercial grade 2d games and the
| whole thing is MIT licensed.
| PretzelPirate wrote:
| If I run all the way to the right side of the screen past the
| enemy and shoot in any direction, the bullets immediately hit the
| enemy.
| delduca wrote:
| Yes, the collision mechanism is incomplete, which is why I'm
| using the bullet position > 1200. Since you passed that
| threshold, any bullet will hit.
|
| My next step is to work on collision and physics; maybe I'll
| use something like Box2D.
| dakom wrote:
| FYI, I recently posted about a 2d game I made, here:
| https://news.ycombinator.com/item?id=41761517
|
| Putting aside the politics and all, focusing on the tech- one
| thing I came across when trying to do my own collision
| detection was the idea of using the GPU and occlusion queries
| for pixel-perfect results.
|
| I didn't come up with the technique, but it's super cool, and
| since you're not taxing the GPU with tons of 3d triangles,
| it's perhaps a bit more free to do stuff like that.
| delduca wrote:
| Using the GPU is always interesting, although in my case I
| want to maintain compatibility with browsers through
| WebAssembly.
|
| Nowadays, it's very rare for a user to download and run a
| binary.
| hedvig23 wrote:
| Ignorant question, but I assume that means there is no
| "browser-facing" or accessibility to the GPU for a web
| based application in this way (WebAssembled or even
| otherwise)?
| dakom wrote:
| Yeah, the game I linked to is in Rust/wasm, running
| solely in browsers :)
|
| The interesting part of the collision detection code is
| here: https://github.com/dakom/not-a-
| game/blob/main/src/collision/...
| onikolas7 wrote:
| For anyone looking to write their own engine, I wrote a tutorial!
| You just need the tutorial and a couple of years :)
|
| https://nik-os.com/agl/00_intro.html
| wilberton wrote:
| Very cool - nice tutorial! I've released a few games with my
| home made engine (most recently https://poki.com/en/g/blaze-
| drifter) My best advice is only write enough engine to support
| the game you want to make. Also don't try and write an editor,
| but add debug/editor tools directly in the game. With each game
| you make, you can add one or two new features to the engine,
| and slowly build up the feature set to be able to make larger
| games.
| onikolas7 wrote:
| Totally agree! I am now writing a very simple hack'n slash
| game to identify missing features. I won't be writing an
| editor any time soon.
|
| Do you have any examples of good debugging features?
| wilberton wrote:
| I started with a simple on screen 'watch variable', so I
| can visually inspect values over time. I added simple click
| drag edit support so I can then edit a value too. Over time
| I've added a (very simple) console, a simple immediate mode
| debug UI, graphing for the watch variables, and a little
| track editor (with the debug UI). Again the key is to build
| only what you need and only when you need it. It sounds
| quite a lot when I write it down, but it's all super simple
| and only supports the barest features that I actually need.
| metalliqaz wrote:
| "anyone can draw"
|
| I wish
| slmjkdbtl wrote:
| I think most "I want to make an engine so I can make games
| faster" people are cursed to make engines forever, this is rare.
| shepherdjerred wrote:
| The only thing more impressive than writing a game engine is
| actually using it
| 01HNNWZ0MV43FF wrote:
| That is truly a curse. I just want to make an engine so I can
| say I did everything from scratch
| sunrunner wrote:
| I hope by 'everything' that includes the text editor and
| compiler you'll used in the development process ;)
| Cthulhu_ wrote:
| At least that's a goal, a lot of people say "I want to make a
| game" but get stuck in the making an engine part. Which is also
| valid, don't get me wrong - if you enjoy it, by all means!
| However it's not building a game, it's building a game engine.
|
| Anyone that wants to build an engine (or a CMS, or whatever)
| with the goal of making a game should try making one or more
| games with one or more existing engines first, if only to get a
| better idea of features and shortcomings. And if they really
| want to make games, or just the engine.
| jedberg wrote:
| I think a lot of them want to be like Carmack. :)
| 0xdeadbeefbabe wrote:
| Or Commander Keen
| wilberton wrote:
| It's definitely possible to do it - for me the key is to write
| the game and the engine together, and only implement the bare
| features you need. For the first game at least, the engine and
| the game are essentially the same thing. Also, forget about
| wiring an editor, just add debug functionality to the game.
| flykespice wrote:
| Literally that what I'm pursuing rn, I want to make my first
| (real) 3d game, I'm very aware of the loophole that most self-
| made engine game developers falls into but I genuinely found no
| 3d engine that suits my criteria:
|
| * Be resources efficient (memory and cpu usage)
|
| * Has primary 3D support
|
| * stable
|
| * Supports old devices (ideally embedded systems too)
|
| * And of course be FOSS
|
| I'm focusing on mobile, as you know mobile devices are very
| sensible to heating so the 1st option is a must, Godot isn't
| resource efficient, it heats very easily when I play one of the
| sample games. Regarding the second option, whilst Godot still
| supports gles2(which is the most widely supported api yet
| across old devices) it's further being pushed as second-
| citizent over Vulkan and looking through github no other engine
| checks my boxes...
|
| If someone could direct me to an engine that checks all the
| boxes above I would happily try it out.
| airstrike wrote:
| Bevy?
| darepublic wrote:
| I also have kids and have toyed with the notion of making games
| with/for them. Thank you for the inspiration!
| Buttons840 wrote:
| I think the best advice for making your own game is: do what
| you're most excited to do. Do you spend time thinking about
| making your own game engine? Then start making it. Be willing to
| change course later if it's too hard, your time will not be
| wasted.
|
| I got into gamedev by messing around with making my own engine,
| mostly focusing on low level graphics APIs, and that knowledge
| transferred well when I switched to a professional game engine. I
| knew about shaders and such and knew I was somewhat prepared to
| alter the engine I was using if needed.
|
| Or, the other way, if you start making a game in an engine and
| you hate it, your efforts are not wasted. The truth is like 10 or
| 20 thousand lines of game logic can make a lot of games, and
| that's really not much code to port to your own game engine
| compared to the rest of the engine. All the art and other assets
| can be ported too. Plus, if you know a professional game engine
| you can use it for tooling or get some good architecture ideas to
| use in your own engine.
|
| So, just get moving with whatever excites you most and be willing
| to change course.
| stroupwaffle wrote:
| Another way to think of this is not making a "game engine" but
| just "making a game". Get rid of all the generic stuff and use
| some common patterns that fit the game exactly. No need to
| over-abstract!
| MattRix wrote:
| That's not what the person you replied to is saying though...
| They're saying just use an existing engine, and if you really
| need to, you can always write your own engine later if you
| really need it.
| stroupwaffle wrote:
| Yeah I'm just saying in general. I probably shouldn't have
| replied to anyone in particular--just jumping in the
| conversation. =)
| fpgaminer wrote:
| > The truth is like 10 or 20 thousand lines of game logic can
| make a lot of games, and that's really not much code to port to
| your own game engine compared to the rest of the engine.
|
| I intuitively want to agree, but on the other hand I've also
| seen many, many hobby/indie/etc projects deadlock when they
| switched engines. Or even engine versions (Unreal 4 -> 5).
| Buttons840 wrote:
| Granted, but I don't think there are many people / teams who
| are capable of writing their own engine and then fail to port
| a few thousand lines of game logic. So I stand by my advice
| that if you decide later to write your own engine, porting
| the logic will not be the difficult part.
| sph wrote:
| [delayed]
| geepytee wrote:
| I find that this is the best advice for life, not just making
| your own games. Do what you're most excited to do :)
| kkukshtel wrote:
| I think maybe opposed to some of the other opinions here, making
| your own engine is much easier than you think and has a lot of
| potential upside.
|
| On a walk today I was thinking about something specific that I
| think is under-discussed. Yes people bikeshed etc. but when you
| create your own engine you are _fiercely_ aware of _everything_
| it can and can't do. As part of this, it's very easy to feel
| fully in command of your own toolset, and as such able to exhibit
| mastery over that toolset.
|
| Granted, the scope of possibility when you start out building
| your own tool is narrow, but in some ways that acts as an easier
| onboarding to expertise instead of getting dumped into something
| as powerful as Unity/Unreal/Godot with little orientation and
| lots of edges you don't know about. In using some super-general
| you have to carve out your own path through its features, which
| is cognitive load (and time!) you don't need to worry about when
| you create your own.
|
| For similar reasons I'm _also_ making my own engine. It's 2D-only
| engine that uses lots of modern C# features to make for rapid
| programming of 2D games. For the game I'm making with it to
| start, I'm using literally every feature of the engine, which is
| something I don't think I'd ever be able to say for something
| more general purpose.
|
| For anyone interested: https://github.com/zinc-framework
| samiv wrote:
| "On a walk today I was thinking about something specific that I
| think is under-discussed. Yes people bikeshed etc. but when you
| create your own engine you are _fiercely_ aware of _everything_
| it can and can't do. As part of this, it's very easy to feel
| fully in command of your own toolset, and as such able to
| exhibit mastery over that toolset."
|
| Yeah the really compelling thing to me is the knowledge
| building. For example what I do with my own project is that I
| take a look at some demo or example, let's say in Gamemaker or
| GDevelop and I ask myself a few questions: a)
| how is the sausage made? b) can I make the sausage and
| what are my ingredients? c) if I can't make the sausage
| yet, what do I need in order to make the sausage?
|
| For me this has been really the best way to build rather "deep"
| knowledge in this domain, as in knowing how something works
| under the hood (or how I think it works or at least how my
| version of it works) vs. knowing how to use it in Gamemaker /
| GDevelop.
|
| Ps. your github could use some screenshots I think
| adamrezich wrote:
| After trying to evangelize this exact mindset to people in the
| wake of the recent Godot drama, I've given up (or not, judging
| by my posts here...). Most people aren't willing to even
| investigate how easy it is to make "a game engine", because the
| term "game engine" has been mythologized (due to Unity, Godot,
| etc.) into being this thing that's for all practical purposes
| impossible for the average programmer to build.
|
| "As a solo developer, either you work on building an engine,
| _or_ you work on building a game, but if you 're going to do
| the former, then you'll never complete the latter," they say
| (in this very comments section, even). Well, sure... if by
| "game engine" you mean "general-purpose super-generic game
| engine," and not "the smallest set of things absolutely
| necessary to transmute the idea I have in my head into playable
| form on this supercomputer I'm sitting in front of."
|
| I don't really get it--I started programming games by learning
| Game Maker in the early 00s. By the time I was ready to move
| onto something more like " _real_ game development" (C# /XNA),
| I was more than eager to structure things more according to how
| I wanted for whatever given project I was working on, rather
| than trying to cram my ideas into a somebody-else's-engine-
| shaped hole.
|
| But the freely-downloadable general-purpose game engines
| available these days, with their innumerable layers of wholly-
| unnecessary overly-generalized one-size-fits-all abstractions
| have gotten most people who use them to never even _consider_
| even _imagining_ doing things in any way other than the way
| they 're now used to doing them, using their tool of choice.
| They're more than happy to settle with thinking about game
| design purely in terms of whatever high-level primitives are
| exposed by their preferred engine, rather than even _consider_
| even _imagining_ what it would be like to have complete control
| over how their game logic is organized and executed.
|
| Why simply define structs and make arrays of struct instances
| and iterate over them, when you could make a byzantine web of
| Nodes/GameObjects in the engine-provided scene graph? I guess
| that's how indie "game developers" these days have been trained
| to think.
|
| And it's crazy because compared to only a couple short decades
| ago, there's more information and resources available out there
| on the Web for free, that anyone can read and use to make
| building something "from scratch" (where "from scratch" means
| "using open-source libraries to do the parts you don't want to
| learn more about for the time being, such as rendering") easier
| than it ever has been before! You can use something like SDL or
| Raylib to "sketch out" a gameplay prototype in _shockingly_ few
| lines of code, then refactor everything so that all library
| calls are wrapped in function calls more suited to your use
| case, and then, later, if you want, you can _replace_ those
| library calls with your own code!
|
| It's not difficult to do _at all_ , but I think there's just
| some level of comfort people take in having a GUI editor for
| their "game engine" that they can open a blank project in and
| start clicking around to make things happen on the screen,
| compared to staring at a blank source code file and figuring
| out where to go from there.
|
| The ever-decreasing baseline level of curiosity and hacker-
| thinking in younger programmers continues to both baffle and
| depress me.
| alstonite wrote:
| I pretty wholeheartedly disagree with this entire sentiment.
| For some people making a game engine isn't a monumental task,
| but implying that it's _easy_ seems like an out-of-touch
| sentiment. There are many people who love making games but
| who aren 't software devs that are enabled to make whatever
| they dream up via by the plug and play nature of game
| engines.
| adamrezich wrote:
| Have you ever _tried_ to "make your own game engine" such
| that you can opine on this from a place of experience?
|
| General-purpose game engines like Unity and Godot are
| "plug-and-play" for only a small percentage of your game's
| development cycle--at some point, unless you're making an
| extremely trivial game, you're going to end up "fighting
| the engine" to make it do the thing you want it to do at
| some point or another--typically much more than once. If
| you weren't relying on someone else's underlying game
| engine substrate to build your game upon, then you would
| never encounter something like this. It would be entirely
| upon you to restructure your _own_ underlying game engine
| substrate that _you 've built_ in order to build your game
| upon. You would _know_ what each part of the machinery is
| doing, because you built it--you wouldn 't have to guess
| and check and dive deep into documentation and forum
| threads and Discord channels just to try to figure out the
| optimal way to beat the engine into submission to do the
| thing you're trying to make it do.
|
| Have you seen the Raylib examples[0], such as the "2D
| platformer camera" example [1] (playable from the examples
| webpage)? It's really not a lot of code at all to get a
| basic playable game going--then from there, you just make
| more structs, store struct instances in arrays, and loop
| through the arrays to do 99% of the things you want a "game
| engine" to do that aren't covered by Raylib library
| functions.
|
| If you made a 2D platformer by starting from that example
| instead of using something like Unity or Godot, and do as I
| said above and wrap all Raylib library function calls in
| your own functions, then, in the absolute worst case,
| tomorrow you wake up and find out that Raylib has, for some
| reason, gone all "Our Machinery"[2] and deleted its public
| source repositories and informed you that you're legally
| obligated to delete all Raylib code on your machine. Not a
| problem--just switch to SDL or SFML or bgfx (for just the
| graphics) or something similar, spend a couple hours
| replacing the library function calls in your code, and
| you're good to go! You maintain _complete ownership_ over
| the _vast bulk_ of your game 's code, _because you wrote it
| yourself_ , except for a few library calls which can be
| easily replaced with something else. This is a _much_
| better situation to be in, compared to e.g. the Unity
| fiasco of last year!
|
| > There are many people who love making games but who
| aren't software devs
|
| This idea still baffles me--why do people try to make
| _video_ games while abstaining from learning anything at
| all about software development? Like there 's nothing wrong
| with using higher-level tools as a means of learning the
| very basics of the craft--that's how I started out, too.
| But wanting to learn a high-level tool and then _stopping
| there and learning nothing more_ is like wanting to be an
| artist but never learning any art fundamentals and using an
| AI generator instead.[3] Video game development as a whole
| is extremely difficult, and a craft that should either be
| taken remotely seriously (especially if you wish to self-
| describe as a "game developer"!!), or taken extremely
| casually. If you want to take it extremely casually, then
| by all means continue to refrain from engaging with even
| baseline software development knowledge and principles. But
| if you want to take it seriously, because, for example, you
| wish to _sell the software you 've made to other people_ so
| they can _run it on their computers_ , then really, making
| a "game engine" is the _least_ of your concerns as a game
| developer. Actually figuring out the game 's design is much
| more difficult and time-consuming!
|
| [0] https://www.raylib.com/examples.html
|
| [1] https://github.com/raysan5/raylib/blob/master/examples/
| core/...
|
| [2] https://old.reddit.com/r/gamedev/comments/wd4qoh/our_ma
| chine...
|
| [3] Surely we all agree that someone whose idea of
| "creating art" is "learning how to best write a prompt for
| an AI art generator", self-describing as an "artist",
| weakens the term and is offensive to those who put untold
| amounts of time and effort into truly learning their craft
| --why should game development be any different?
| _gabe_ wrote:
| You seem to be very intent on insisting that anyone can
| make a game engine (which I mostly agree with). But, it's
| not easy, even when you use a pre-existing framework like
| Raylib. I've used frameworks like Monogame, I've used
| bare metal C++ and OpenGL, I've used the HTML canvas and
| JavaScript, I've built physics engines and used physics
| engines like Box2D or Havok. What I'm trying to say is
| I've done a lot of game engine-y stuff at various levels
| of the stack.
|
| I've _also_ used Godot, Unity and Unreal. There's a
| tremendous difference. I just started learning Godot a
| week ago and I already have the core game loop
| practically done in a new RPG. Sure I could've done the
| same thing using C++ and OpenGL (or Raylib or something),
| but I would be missing out on a lot of useful things that
| _just work_. Godot's BBCode text labels are amazing and
| give my dialogue boxes a whole bunch of character out of
| the box. The tilemap editor allows me to just build my
| levels without having to build an editor first. The
| lighting system can add a ton of visual polish with very
| little effort on my part.
|
| I've also dabbled in VR games with Unreal. And I've tried
| making some simple 3D games in Unity. Is this all
| possible without those engines? Yea. Would I have been
| able to experiment with the kinds of tech I got to play
| with if I made it all myself from scratch? I doubt it
| (not because I couldn't do it, I just don't have the
| time).
|
| Another thing to consider is porting your game to
| different platforms! There's a whole lot of variability
| in what kind of support you'll get for that with
| something you made yourself or a framework like Raylib.
|
| Anyways, from someone who has experienced both sides of
| the coin, you'll end up fighting with the engine either
| way ;) There's nothing wrong with using a general purpose
| engine.
| adamrezich wrote:
| Would you not say that learning how one could possibly
| make a game without using someone else's engine that does
| everything for you made you a better game developer, even
| if you end up choosing to use one?
| kitd wrote:
| I'm not a game dev, but I had a lot of fun making an ECS
| system by following ideas in an article I found (and which
| I have now annoyingly lost).
|
| It's a very educational exercise that any dev would benefit
| from, game dev or not.
| wilberton wrote:
| Absolutely agree! It's totally doable, but it does require
| some desire/ability to dig under the hood little. I think a
| lot of people conflate the game engine with a game editor,
| and don't realise how simple an engine can be if it only
| contains the features needed for one game. I've shipped
| several games with my home made engine, and it was the best
| technical decision I ever made! No more relying on someone
| else to fix bugs!
| adamrezich wrote:
| The editor is part of it but I think the complete lack of
| where to even begin structuring one's game code in absence
| of some kind of formalized scene graph is a huge part of it
| as well. Scene graph editors make seeing "what exists in
| the game world right now" very visually apparent and easy
| to understand: "well, there's this root Node, and within
| that there's these different Nodes, and some of them have
| child Nodes which represent..." and so on and so forth. I
| recently replied to someone on X [0] who was starting from
| the Raylib 2D platformer example and asked, earnestly, "so
| I have this constant array of five rectangles representing
| platforms... how do I go from this to 'defining my game's
| world'"?
|
| It's just data. In its most basic form, a game world can be
| represented as just arrays of instances of structs, and
| then you loop over those arrays and call a function on each
| element to simulate the "entity" that struct instance
| represents, and then again to render it onto the screen.
| Sure, you eventually might want to do something more
| complex than that if the need arises, but most people would
| be surprised at just how far you can go doing only the
| simplest possible thing.
|
| [0] https://x.com/rezich/status/1841889141505851680
| MattRix wrote:
| People like designing and making games, so they design and
| make games... Making the engine (or underlying framework,
| whatever) is just not necessary for that goal.
|
| There are relatively few game designs (especially with indie
| scope!) where a custom engine is truly necessary.
|
| For the tinker/hacker types, there are plenty of things to do
| at a "lower level" within the engine itself (note: I don't
| necessarily mean modifying the source code). There are all
| kinds of different ways to structure things within the
| confines of the engine, and lots of other ways of building
| frameworks and GUI tools within the engine too.
| FragmentShader wrote:
| > but when you create your own engine you are _fiercely_ aware
| of _everything_ it can and can't do
|
| The problem is that if you start gamedev by making engines,
| then you aren't aware of what you _need_ to do.
|
| To give an example, if you make font rendering and looks
| blurry/pixelated, what now? Oh, and a simple 2D game takes 8
| seconds to load, wonder why?
|
| Meanwhile, if you have ever made a Unity game, chances are you
| already know the keywords "SDF" and "Texture compression",
| because you tore down an already big engine for optimizing your
| game and accidentally learned about what features a game needs.
| sunrunner wrote:
| > What now? > wonder why?
|
| What now is you have a fantastic opportunity to learn some
| topics in depth. Using Unity is also no guarantee that you'll
| come across those terms. And even if you do, if the Unity
| solution is to check the correct boxes you're exactly better
| off from a knowledge point of view.
|
| I'm not advocating for _not_ using Unity, but I am advocating
| for learning, increasing the depth of your understanding, and
| just a general approach of curiosity and problem solving.
| saintfire wrote:
| This was my experience.
|
| I dove into writing a niche game engine and stumbled over
| every hurdle that modern game engines solve.
|
| Been learning Godot lately and going back to writing an
| engine I'm confident I could trivally solve a lot of those
| hurdles.
|
| Additionally, if im trying to make a basic editor I can now
| see what is tenfold easier graphically (animations) and what
| I don't mind programming in.
| zoogeny wrote:
| I've been really interested in things like raylib [1] and other
| minimal C libraries for lower-level game-engine-like
| capabilities. There is a widening middle ground available for
| developers between writing your own engine completely from
| scratch and using a full-featured engine like Godot, Unity, or
| Unreal. There was always stuff like SDL but these new minimal
| libraries hit a sweet spot for a lot of cases.
|
| 1. https://www.raylib.com/
| scruple wrote:
| I'm currently using raylib and Odin to build a 2D platformer
| for my twins. I built out a PoC with a couple of levels. Now
| I'm working my way through a level editor. It has completely
| reinvigorated my passion for programming.
| wilberton wrote:
| Yup, raylib is great. Sokol is another solid choice for the low
| level bits - that's what my engine is built with and it's
| excellent (at least for indie level games).
| bcrosby95 wrote:
| Am I the only one who thinks the word "engine" is overused?
|
| I've always assumed that "make a game, or make an engine" meant:
| if you decide to _not_ use an engine when making your game, don
| 't abstract it and _also_ make an engine.
|
| In other words, don't overengineer your game and build a generic
| engine when you don't need to.
|
| Have I interpreted this wrong all these years? Or did the phrase
| morph because everyone thinks everything is too hard to program
| yourself these days?
| adamrezich wrote:
| "Game engine" is _supposed to_ simply mean, the parts of the
| game code that aren 't the main game logic--the stuff that
| handles asset loading, entity management, input detection,
| rendering, sound playback--that sort of thing. It _could_ be
| used to refer to Unreal Engine... _or_ it could just mean the
| simple, minimal homemade tech stack that you built your game
| upon. Or anything in-between.
|
| But you hit the nail on the head--it's definitely one of those
| terms that has been warped and downright _mythologized_ in
| recent years, with the rise of free-to-download general-purpose
| GUI-editor "game engines", and their ensuing popularity.
| sunrunner wrote:
| > if you decide to not use an engine when making your game,
| don't abstract it and also make an engine.
|
| Exactly this. Do the minimal thing correct for your situation
| (your own rendering if desired/required or integrating a third
| party solution, free or otherwise) and don't spend a year on
| stable rigid body simulations in a completely general-purpose
| and reusable tool (that is only reusable for you because it's
| almost a guarantee it won't be general purpose enough or
| documented well enough for anyone else) if you don't need the
| objects to behave with some level of physical realism.
|
| Smaller personal and hobbyist projects have the freedom to make
| a lot more choices around 'how' they get to their end goal, and
| I think they should use that opportunity. If you're genuinely
| intending to make the next indie hit, the actual tech is not
| likely to be the most difficult thing for success, whether you
| use Unity or your own tools.
|
| > because everyone thinks everything is too hard to program
| yourself these days?
|
| Without getting too cynical, it seems like there's a culture of
| ignorance in some places where large long-lived software
| projects created by other people over time are treated as black
| boxes, impossible to understand, and not for the likes of mere
| mortals to even attempt to comprehend.
___________________________________________________________________
(page generated 2024-10-08 23:00 UTC)