[HN Gopher] Accidentally making a language, for an engine, for a...
___________________________________________________________________
Accidentally making a language, for an engine, for a game
Author : markdog12
Score : 322 points
Date : 2022-04-05 01:17 UTC (21 hours ago)
(HTM) web link (verdagon.dev)
(TXT) w3m dump (verdagon.dev)
| quickthrower2 wrote:
| Maybe I would make a good game dev after all: I have no interest
| in making a language, would be happy knocking one up in JS
| winrid wrote:
| These days there are even cross platform PHP game
| engines/frameworks... for most ideas that can be executed by
| one person - use what you know!
| Jyaif wrote:
| > We're adding a parallel keyword
|
| Why is there a need for a "parallel" keyword? Can't the compiler
| decide for you whether to parallelize a loop for you?
|
| If the decision to parallelize depends on the data, couldn't the
| compiler generate code for both implementations and select the
| right one at run time?
|
| Or maybe the programmer could describe in code what they expect
| the data will look like, and the compiler will take a decision
| based on those annotations (and other signals, such as the HW the
| program has access to, what the programmer wants to optimize for
| (memory? latency?)).
| sriku wrote:
| This reminded me of a statement David Zicarelli (creator of
| Max/MSP/Jitter) made many years ago - that he originally started
| working on Max in order to make a tool to help him compose novel
| and interesting music, and then he got so drawn into making the
| tool that he lost interest in the music composition itself. If
| we're to call Max/MSP/Jitter "yak shaving", it is a shining star
| of it since so many artists - both visual and sonic - build their
| work on it.
|
| The other obvious one is Knuth - inventing TeX and Metafont and
| Computer Modern typefaces so he can write his books the way he
| wants to. Another shining star.
| empgodot wrote:
| I hate when that happens.
| wiz21c wrote:
| FTA :
|
| > So, having learned that lesson thoroughly, I then made the same
| mistake again!
|
| So true ! I don't know if it is written with a bit of sarcasm,
| but this one made me laugh !
|
| 'cos in the end, it's about doing what one loves. So if you think
| you like to make games but have fun writing the perfect game
| engin instead, it's not less fun !
| didip wrote:
| Scala for a game engine seems like an odd choice. What was the
| initial decision to choose it?
|
| Also, how's the compile time? If it's too long won't it drive you
| crazy?
| wtetzner wrote:
| Was Scala used for the game engine? It sounded to me like it
| was just used to write the compiler for Vale.
| lmm wrote:
| Sounds like it was for the compiler, not the engine itself. IMO
| Scala is the best general-purpose language going, but it's
| particularly good for data transformation, so it's a good fit
| for compilers.
| cyber_kinetist wrote:
| Many years ago I was turned off at Scala for its weird
| ergonomics (relying heavily on implicits, also the syntax is
| too wild for my taste) and large build times, along with
| Project Valhalla still not being finished. Maybe things have
| gone better for Scala 3?
| pjmlp wrote:
| > These languages are mostly fine... but C# is slow,....
|
| First of all, it is a matter of which implementation we are
| talking about.
|
| Second, all major implementations wouldn't have had any issue
| dealing with the demos shown on the blog.
|
| I guess it was a good learning process about compilers for the
| author.
| gary_0 wrote:
| C# is very fast on average, but due to its runtime/GC it won't
| give you the consistent performance you need for game engine
| internals, which is what they meant by "slow".
| pjmlp wrote:
| Unless we are talking about Assembly, all languages have
| runtimes.
|
| As for the GC, it can be turned on in critical code paths, C#
| supports manual and stack memory allocation.
|
| Profilers exist, many console games have been shipped in C#,
| besides Unity, there are Xenko, FNA and MonoGame custom
| builds for game consoles.
|
| Compare the demo on the blog with,
|
| https://store.steampowered.com/app/236090/Dust_An_Elysian_Ta.
| ..
|
| https://store.steampowered.com/app/985890/Streets_of_Rage_4
|
| https://store.steampowered.com/app/107100/Bastion
|
| https://www.pcgames.de/Arena-Wars-Spiel-18141/Tests/Arena-
| Wa...
|
| All of them done in regular C#, not even taking into account
| Unity and its DOTS/Burst C# subset.
| gary_0 wrote:
| > Unless we are talking about Assembly, all languages have
| runtimes.
|
| My point was that some languages have heavier runtimes than
| others (out of the box, at least).
|
| And yes, C# is very popular for gameplay code, but I'm
| talking about the parts of an engine that typically use
| systems programming languages. Even then, you can shoehorn
| C# into that role with some tweaking and AoT compilation
| (which is a testament to the C# ecosystem's versatility).
| But I was just explaining why I think the word "slow" was
| used regarding the C# language in general, even though it's
| not perfectly technically correct.
| orthoxerox wrote:
| There's also Terraria, which is the 15th best-selling game
| of all time. Written in C# (XNA).
| bartwe wrote:
| My last 8 yrs of game development have been in a good part
| about how to make c# go fast, and it is definitely possible,
| but you will have to write in a style that is different from
| the norm.
| Rochus wrote:
| Can you please elaborate on that, or provide some links?
| bartwe wrote:
| A few other commenters hit the points better, but mostly
| it comes down to avoiding allocating objects every
| frame/tick. In part this is through avoiding LINQ,
| lambdas, yield return, async etc. (fine to use in code
| that is run once like startup, or on relatively rare
| triggers) Using struct, arrays of struct/value, Span<>,
| ref, fixed etc. to keep memory access sequential or on
| stack. Use mutable structs, avoiding properties, avoiding
| struct constructors, moving throws into utility methods,
| etc. to support (the rather weak) optimizer to do more
| inlining. And move data processing of arrays of struct
| with tight loops, like compression, lighting, meshing,
| pathfinding into a native c++ dll/so or if applicable
| gpu. (c++ autovec/simd optimizations or much better than
| what the clr optimizer currently provides)
| Rochus wrote:
| Ok, I see, thanks. Why then using C#/.NET at all if you
| have to do without many (most?) of the conveniences of
| this technology, and even have to consider to implement
| parts in C++ for performance reason? Why not directly
| e.g. C++?
| bartwe wrote:
| Because the hot paths in the code are not the majority of
| the code. C# is (for me) much more productive to write
| than c++. More powerful refactoring tooling due syntax
| that is much easier for tooling to process. Powerful
| autocomplete, autorefactoring tooling. Easy code
| navigation due to easy to process syntax. The tooling
| also responds much faster, c++ refactoring tools seem to
| take a long time to process code. Big reduction in
| footguns/UB etc. Very quick iteration cycles, edit-and-
| continue in sub second, stop-edit-restart cycles in the
| low single second range. Very good debugging, objects are
| inspectable and editable, stacktraces reliable. Edit-and-
| continue makes for very quick probing of internal state.
| The c++ code is around 1% of LOC and 20% of cpu cycles,
| seems like a good balance. Bounds checking, lack of
| dangling pointers/use after free, removes a whole class
| of hard to debug bugs.
| pjmlp wrote:
| For the same reason that many C and C++ games were
| actually using them as high level macro processors full
| of inline Assembly a couple of decades ago.
|
| There are some conveniences that come with the technology
| and not every code path on the game engine is screaming
| for perfomance.
|
| If you are on the path for the ultimate performance like
| some console titles, the C and C++ code on those engines
| will be very alien to most developers as well, yet you
| don't seem many discussing that.
|
| Just on the subject, here is a talk I saw recently on the
| theme,
|
| "Beyond the Remake of 'Shadow of the Colossus': A
| Technical Perspective"
|
| https://www.youtube.com/watch?v=fcBZEZWGYek
|
| However not every single game out there is trying to fit
| Shadow of the Colossus into a PS 2 or XBox 360.
| pjmlp wrote:
| Before C and C++ became widely acceptable for game
| development, we used to read these bibles like these,
|
| https://www.jagregory.com/abrash-black-book
|
| https://www.amazon.com/PC-Intern-Encyclopedia-Programming-
| De...
|
| https://www.amazon.com/Black-Art-Game-Programming-High-
| Speed...
|
| Very little regular C and C++ code, plenty of inline
| Assembly.
| andrewflnr wrote:
| AHA! I should have known that generation-reference business was
| intended for games all along.
|
| Reminds me of the time the FoundationDB team wrote a compiler to
| write a simulator to test their database:
| https://www.youtube.com/watch?v=4fFDFbi3toc
| RandyRanderson wrote:
| In the limit, every configuration file becomes turing complete.
| mamcx wrote:
| The other niche where this kind of thing happens: ERP/eCommerce
| applications.
|
| And at least from my POV, is where it ACTUALLY need it, not just
| is fun.
| klabb3 wrote:
| The way structured concurrency is implemented in Vale is exactly
| what I've been missing in every language I've been working,
| including Rust which gets pretty close. Amazing job!
| hoseja wrote:
| Yeah, this seems like a research project for Rust, but wonder
| if Rust is still capable of such evolution.
| verdagon wrote:
| Thank you! We're pretty excited about it too.
|
| Though, I do want to be clear for readers, Seamless Concurrency
| [0] isn't fully implemented yet, we've only just started to
| play with its first building block, the region borrow checker.
| It's promising, but I don't want to get anyone's hopes up too
| early.
|
| [0] https://verdagon.dev/blog/seamless-fearless-structured-
| concu...
| UltraViolence wrote:
| Glossing over the language it seems very similar to Rust, but
| with a somewhat friendlier syntax that's closer to C#/C++.
|
| So, I'm wondering if and when someone will write an operating
| system in it.
| bogwog wrote:
| Gotta start with rewriting all of those programs that were
| rewritten in Rust.
| cmrdporcupine wrote:
| Being distracted building tooling and frameworks is one of the
| harder things I find with personal projects.
|
| In paid $work, there is a) an imposed direction and usually a
| schedule from a customer b) often a team of people to distribute
| work to, and to help keep one disciplined.
|
| Example: I'm writing a VST synthesizer, virtual instrument, as a
| personal project in my time off between jobs. Maybe I'll make it
| commercial someday, not sure. I became increasingly frustrated
| with the half-assed portable GUI toolkit bundled with the VST3
| SDK ("VSTGUI"). There's a complete lack of decent cross platform
| UI options that will work in this context (QT won't do it here,
| for reasons.)
|
| I realized that there's already a cross platform UI option with
| millions of man hours put into it: the web. So I have spent the
| last three or four weeks writing a bridge to embed Edge-Chromium,
| WebKit, etc. Have that working on Win32, at least (still have to
| do the work for Linux & Mac, but ok).
|
| Then on to actually making the UI in this platform. Now I'm
| learning npm, webpack, TypeScript.
|
| Need a nice little HTML/CSS knob for my UI. Most are bundled in a
| giant framework I don't want. Oh, here's one in pure JS. But, hm.
| I think I'll refactor this into Typescript. Now it's forked, just
| for me.
|
| Ok, well, yes I have that mostly working. Some warts, but
| basically is very similar to the "native" (VSTGUI) UI I had
| before. But now I want to write a graphical envelope editor. Off
| to learn HTML Canvas drawing.
|
| Many parts of this whole process could themselves be spun off
| into separate projects, that I could spend years maintaining, on
| their own.
|
| And so it goes. The Yak is pretty shaved at this point.
| [deleted]
| mathgladiator wrote:
| There should be a competition of yak shaving.
|
| I've writing a Rust based canvas engine, with content via my own
| IDE, the runtime is fed data via WebSocket using my own API
| protocol, web proxy routing through a streaming and distributed
| load balancer using a new protocol, landing on my back-end
| platform running my own language, writing deltas to my own data
| store. https://www.adama-platform.com/
|
| Why? For board game glory!
| DonHopkins wrote:
| I'm working on breeding hairier yaks, so you don't need as many
| to shave.
| sdenton4 wrote:
| Last year I set out to work some machine learning train+eval
| loops for my team, but ended up writing a config language.
| Oops.
| bcbrown wrote:
| It's not quite yak shaving, but it certainly is... something:
|
| > I mean, we are running Access in Wine in X11 on Linux in an
| isolated user account on our server slice that revision
| controls your Access database in git, and we're displaying it
| using VNC in your web browser in flash. People can't possibly
| want that. But they need it.
|
| https://apenwarr.ca/log/20120326
|
| (Not mine, but seems relevant)
| abrookewood wrote:
| That's such a good article! The pain, suffering and mind-
| numbing boredom of SUCCESS ...
| p_l wrote:
| I always wonder why the Access database isn't moved then from
| JET to some database server, even MSSQL (Postgres would also
| work), and then you can continue Access but without needing
| to snapshot it in weird and possibly broken ways?
| noisy_boy wrote:
| I find it somewhat disturbing that this felt like a
| reasonable approach to me...
| cyber_kinetist wrote:
| That's the total opposite of yak shaving, but in the most
| hilarious way. Layers upon layers of systems and protocols to
| maintain legacy systems... lazily use a bunch of glue and
| duck tape to build the whole thing... and it miraculously
| works!
| justinjlynn wrote:
| Wow. That's amazing. Any other stories you know like that
| one?
| sitkack wrote:
| Holy Moly, this is Board Game Erlang!
| Centigonal wrote:
| I don't know what it is about game development that really brings
| out the yak shaving in people.
|
| One time, about 8 years ago, I backed a game called Nowhere[1] by
| a very talented programmer. The original premise was an alien
| life simulator.
|
| Well, it's been eight years, and development is still going
| strong!
|
| The developer is currently working on the String implementation
| for the programming language he invented[2], which he's using to
| write the other programming language he invented[3], which is
| eventually going to be used to write the game.
|
| [1] https://duangle.com/nowhere
|
| [2] https://hg.sr.ht/~duangle/scopes
|
| [3] https://hg.sr.ht/~duangle/tukan
| ModernMech wrote:
| It's not game development that brings out the yak shaving, it's
| programming language development. Game development is just a
| gateway drug because it provides so many opportunities for good
| abstractions to make things easier. The mistake everyone makes
| is thinking that they can create a programming language while
| also doing X, where X is whatever they had doing when they got
| the itch to do a PL. Really, if you want to do a PL right, you
| have to do it full time.
|
| Actually I'm not sure it's really a mistake, it's just that
| doing PL development is so much fun that there's no reason to
| go back to the original project, if original the impetus for it
| was to have fun.
| thom wrote:
| I think a lot of people get into game development to go back in
| time to their early experiences of computing. Before all the
| enterprise projects, before all the tools and frameworks,
| before all the tiring interactions with people and teams and
| managers and customers. Just an empty BASIC prompt, just a
| blank C file. It's a search for a blank slate, open to infinite
| creative possibilities, before the world put everything in
| boxes within boxes within boxes and drained much of the joy
| from these magical machines. Finishing a game is coming back up
| for air, who'd want that?
| onion2k wrote:
| _which is eventually going to be used to write the game_
|
| At what point do you stop believing that?
| headsoup wrote:
| I think sometimes the followers find out that being engaged
| in the process of creating something brings more value than
| the game they're waiting for anyway.
|
| I have been in a couple of communities involved with
| developers as they built games and it was almost
| disappointing when the game was released because the
| 'journey' was finished and so time to disband.
|
| It can certainly be a curse though if the developer isn't or
| stops enjoying it.
| jfoutz wrote:
| Shhh. The man of La Mancha has a windmill that must be faced.
|
| I mean, never. But sometimes people just need to make stuff,
| and that's super cool. They're doing no harm, let them enjoy
| their fantasy.
| [deleted]
| bendbro wrote:
| Sorry about the game, but it looks like you funded a pretty
| cool programming language!
|
| https://sr.ht/~duangle/scopes/
| bartwe wrote:
| Thank you for backing his work, his posts and twitter feed are
| a gold mine for some pretty unique ideas in signed distance
| field and other rendering research.
| KronisLV wrote:
| This is a lot like what a YouTuber by the name of Randy has
| been doing: he decided to create his own game engine instead of
| using something like Godot/Unity/Unreal and it's been quite the
| adventure.
|
| His main YouTube channel:
| https://www.youtube.com/c/RandallThomas/videos
|
| His secondary YouTube channel:
| https://www.youtube.com/c/RandytheSequel/videos
|
| Of course, he still has nothing close to an actual game and the
| progress he's made in a year is visually similar to what i
| threw together in a month in Unity for a freelance client once.
| Though admittedly, he's probably learnt a bit more about how
| game engines work by creating his own and it's been quite the
| educational experience, as well as something that actually has
| gained him a nice following of people who support him towards
| more videos.
|
| But that's still not very conductive to shipping finished
| games. It's very much the same as people whose games tend to
| balloon in scope, another thing that's as damaging to finishing
| a _product_ in a reasonable amount of time as writing your own
| engine is.
|
| I do suspect that not everyone has the utilitarian approach to
| game development that i or other people like me have: who just
| pick Godot/Unity/Unreal for every single project of theirs
| without ever caring much about the inner workings of
| everything. Then again, i'm the kind of person for whom, for
| example, adding graphical effects to their game consists of
| utilizing pre-made shaders instead of learning to use the
| shader language properly and all that.
|
| Not that there's anything wrong with that, but those are wildly
| different mindsets.
| mwill wrote:
| In case you missed it, some further context, his website now
| reads: I've decided to shelve Arcane (a
| video game I've been "working on" for 7 years) so I can
| practice shipping smaller games first I've been
| sending out a personal changelog every Sunday I've
| started using Unity so I can hone my design & prototyping
| abilities I scrapped my old custom website with this
| WordPress one I've transitioned to having writing
| (this site) be my main communication medium since I'm not the
| biggest fan of chasing the YouTube algorithm
| KronisLV wrote:
| Yep, that is actually the eventual outcome for many of
| these grandiose projects.
|
| Nonetheless, i hope that his further pursuits are more
| successful or at least fulfilling for himself!
|
| Who knows, maybe he'll be able to create interesting
| content about Unity some time in the future, like Sebastian
| Lague and others make:
| https://www.youtube.com/c/SebastianLague/videos (if he ever
| feels like doing more YouTube content)
| animal531 wrote:
| I did the same thing 10 years ago. I probably spent about 9
| months full time building a game on a custom OpenGL engine,
| but at that point I realized how many systems I was still
| missing (for example animation, more advanced effects and
| shaders, etc).
|
| But as of recently I'm now doing game development again, but
| this time using Unity. I've learned that game development is
| really hard, geometrically more so than a random business
| application or tool, and you have to use all/any tools that
| are available to you.
| j-krieger wrote:
| > as well as something that actually has gained him a nice
| following of people who support him towards more videos.
|
| A following which has recently turned against him after they
| funded 6k a month on his patreon, and he flatout told them
| that he would stop communicating, doing YouTube videos _and_
| he would also stop working on the game they were giving
| funding for.
| egypturnash wrote:
| If he was making that much money for a while, lives
| somewhere affordable, and saved a lot of that, he's got a
| decent runway to start making money by actually making
| games instead of getting lost in his own engine.
| AceJohnny2 wrote:
| Wait, that's the game by Leonard Ritter, aka paniq!
|
| I loved his (demoscene) demo Masagin[1] way back when, and have
| the SVGs of the geometric shapes somewhere, with a vague idea
| of bleaching them onto t-shirts (speaking of old projects that
| never come to fruition...)
|
| Frankly, I can't say I'm surprised that's where he's at with
| Nowhere. Well, I'm glad he's having fun.
|
| [1] https://www.pouet.net/prod.php?which=50131
| Centigonal wrote:
| I'm a huge fan of masagin - it was one of the first demos I
| saw that really spoke to me about the expressive power of
| graphical programming.
|
| I'm glad he's having fun, too :)
| j-krieger wrote:
| At least the game's name also records where its progress is
| going.
| thyrox wrote:
| I read an amazing quote online about any satelite company
| trying to create their own custom rocket to launch its
| satellite instead of using existing infrastructure.
|
| The day they decide to get into that is the day they stop being
| a satelite company and become a rocket company instead. The
| person put in much more eloquent words so wish i could find
| that comment but its sounds similar to that.
| Tomte wrote:
| Similar: https://spacecraft.ssl.umd.edu/akins_laws.html
|
| > 39. Any exploration program which "just happens" to include
| a new launch vehicle is, de facto, a launch vehicle program.
|
| > 39. (alternate formulation) The three keys to keeping a new
| human space program affordable and on schedule:
|
| > 1) No new launch vehicles.
|
| > 2) No new launch vehicles.
|
| > 3) Whatever you do, don't develop any new launch vehicles.
| thyrox wrote:
| Wow these are just excellent and even though it says
| spacecraft design most of them ring just as true for
| software design.. or maybe just true in general!
|
| This one really made me laugh :D
|
| > At the start of any design effort, the person who most
| wants to be team leader is least likely to be capable of
| it.
|
| What an excellent link, thanks for sharing. Definitely
| bookmarking this.
| moonchrome wrote:
| >I don't know what it is about game development that really
| brings out the yak shaving in people.
|
| People get into game development because they want to have fun
| programming. Getting projects done involves a lot of things
| that are not fun, so it usually goes nowhere because the
| incentives are misaligned.
|
| I've noticed this in many hobby professions - eg. hobby
| woodworkers spending more time on creating
| workbenches/tools/jigs/sleds than actually building some
| projects, hobby guitar players spending more time on gear than
| playing, etc. and I'm 100% guilty of it as well.
| jasfi wrote:
| That is absolutely fine, and you can learn a lot with that
| sort of approach. It really depends on your objective.
|
| The only thing to keep in mind is that writing software for
| business (e.g. SaaS) requires the exact opposite approach.
| You go lean, write what other people want, and go for an MVP
| first.
| gjvnq wrote:
| > But not like creating a typesetting system to use to write
| your book.
|
| I sort of did this once because I wanted both PDF (via LaTeX)
| and HTML output.
| orthoxerox wrote:
| > I've noticed this in many hobby professions - eg. hobby
| woodworkers spending more time on creating
| workbenches/tools/jigs/sleds than actually building some
| projects
|
| As a hobby woodworker, I was saved from this by
| circumstances: I couldn't build a workbench in the old shed,
| I couldn't build a new shed at the time, but I needed a new
| nighstand ASAP because my son needed a larger bed, so I had
| to make it on an old kitchen table in the old shed.
| huseyinkeles wrote:
| In my first year of 3D printing, I printed mostly parts about
| upgrading and modding my 3D printer.
|
| But the good thing is it also made me get used to the whole
| process of refining a 3D print and after a year I barely
| started to print functional&useful things.
|
| So yeah, I don't see a problem with this approach :)
| ummwhat wrote:
| What's the point in life if you don't get to work on what you
| find interesting. Those Yaks ain't going to shave themselves
| you know.
| bpicolo wrote:
| Nothing wrong with having a nice yak wool coat
| hinoki wrote:
| Hey, all I want to do is shave yaks, and now you want a
| coat?
|
| That will involve sorting, carding/combing, spinning,
| weaving/knitting, and all sorts of other stuff that
| doesn't involve razor blades and yaks.
| hallway_monitor wrote:
| I never thought about the implication that shaving a yak
| is the most fun thing you want to do all day. It's so
| great you would rather shun all your other
| responsibilities to shave some yaks. I guess I'd better
| try it.
| prewett wrote:
| I really depends on the species of yak. Shave _your_
| matted, smelly yak? No thank you! But _my_ silky black
| yak, absolutely!
|
| I guess the trick is to fall in love with a species of
| yak that everyone else needs but wants to avoid, so
| they'll pay you to shave your favorite yaks.
| derefr wrote:
| Sometimes all you have to do is shave the yak and give
| the wool away, and a nice yak-wool coat will come back to
| you. :)
|
| Which is to say: sometimes, if you build a low-level
| library/infrastructure service and release it, someone
| else will take advantage of it to write the high-level
| thing you were originally aiming to create.
|
| I'm speaking from experience -- my company's DBaaS is
| built on the premise of just building a really good
| database domain-model to hold a certain type of large,
| public-available datasets, for efficient, flexible
| querying of them; loading those datasets into it; and
| then giving people access to it (through SQL or various
| use-case-shaped APIs.) It's a really thorough yak-shave
| of the DB+ETL layer of what was originally planned to be
| a higher-level B2C product.
|
| But it turns out I have a pretty unique view of what
| should be considered "fun", because _my_ yak-shave was
| _everyone else 's_ schlep. Everyone turned out to be
| dying to get their hands on this thing, because they
| wanted to spend all their time on a _product_ , rather
| than getting good data to feed their product. Once we
| realized that, we stopped trying to build a B2C product
| at all, and just started selling the yak wool directly.
| smcl wrote:
| > People get into game development because they want to have
| fun programming
|
| Totally agree. I think the only real issue here is
| expectations. If the project mentioned was crowdfunded
| specifically and only with the goal to deliver a game, then I
| think people would be right to be a little bit irked that the
| developer is instead tinkering with their own programming
| language rather than the game, after eight full years.
| However if the project was funded with the understanding that
| the developer was just going to explore and share the process
| of game development and everyone is on board with them going
| off-piste to develop something interesting, then I guess
| that's fine.
|
| That said, the amount of money in question is $67k spread
| over 1660 backers (~$40 each) so it's not like this person
| has grifted millions then done a rug-pull :)
| Centigonal wrote:
| I don't know about other backers, but I'm happy with how
| this has turned out myself. I think backing anything comes
| with a level of risk, and the fact that they're working on
| _something_ publicly, eight years later, is more than a lot
| of campaigns manage.
| paniq303 wrote:
| Thank you. It's not a grift (or is that what a grifter
| would say - oh god I hope it isn't). I didn't want us to
| overpromise and become the next No Man's Sky (which has
| by now fully redeemed itself) so I never spent much time
| on advertising and trailers. As a result, we didn't get
| much money. People were skeptical from the beginning,
| which was expected. What we got in support largely came
| from a handful of friends who wanted to see it done, and
| most of their names are going to end up in the credit
| roll. 99% of our present funding comes out of our own
| pockets and from Sylvia's illustration business.
| smcl wrote:
| To clarify, I was trying to say that it _doesn 't_ sound
| like a grift. The last sentence of my comment was badly
| worded :)
| marginalia_nu wrote:
| Game development is a weird place. You want to be low level to
| get the most performance, but you also want to be expressive to
| be able to write an ambitious game. Really does invite the
| notion that there ought to be a better way, you get a sort of
| itch you can't quite reach to scratch.
|
| I'm having a lot of the same struggles working on my search
| engine. What I want to do with files is often somewhere between
| what the operating system provides (too low level), and what a
| DBMS provides (too high level). So I'm having to build all
| these weird bespoke disk-based data structures myself. It's
| clear these things can be done and there is a lot to gain from
| doing it, but the language support for non-trivial disk based
| data structures is a bigger pain in the ass than sitting on a
| burning cactus covered in tabasco sauce.
| maccard wrote:
| > Game development is a weird place. You want to be low level
| to get the most performance, but you also want to be
| expressive to be able to write an ambitious game.
|
| The vast majority of games don't need to be low level for
| performance. Practically nobody outside of massive AAA
| studios is writing architecture specific assembly for modern
| PCs or consoles (and even in those studios, there are very
| few people doing so). The majority of gameplay programmers
| are writing bog standard C++ that would be just as performant
| in C#, or in many cases a lot of the logic is written in a
| higher level scripting language that is orders of magnitude
| slower than the native C++, or even just writing all of the
| game code in something like C#.
|
| > Really does invite the notion that there ought to be a
| better way, you get a sort of itch you can't quite reach to
| scratch.
|
| Oh for sure, and there often are better ways to solve these
| problems. In my experience, one of the most common reasons
| for not doing things better is because the codebase is based
| on an engine from 20+ years ago when they _did_ have to avoid
| interfaces and virtual function calls for game performance,
| and you have "modern" systems that are built on top of those
| abstractions (in the same way that lots of modern networking
| libraries still leak details about concerns from the 80s/90s)
| marginalia_nu wrote:
| Depends entirely on what you want to do. Use a bog standard
| engine, and you get Satisfactory. If you build your own,
| you can have Factorio. The former will _never_ reach the
| sort of simulation complexity the latter can even on modest
| hardware.
| maccard wrote:
| > The former will never reach the sort of simulation
| complexity the latter can even on modest hardware.
|
| You're comparing games rather than engines here. There is
| no reason at all that you can't write your simulation
| logic in vanilla bare bones C++ as factorio has done, and
| still get the benefit of using an existing engine. You
| get all the neat (and hard) things like serialisation,
| multiplatform support, networking, asset management,
| patching, and a bunch of other things. Sure, factorio may
| not need a 3d renderer, but it definitely needs and uses
| the rest of what I listed above.
| marginalia_nu wrote:
| The problem is you can't deal with the number of entities
| factorio regularly does on a stock engine. They just
| aren't made to deal with hundreds of millions of stateful
| and non-trivially interacting entities. That's not what
| game engines are built optimized for.
| maccard wrote:
| Just because you're using unreal doesn't mean you need to
| have one actor per entity (for example). Using [0] as an
| example, there's no reason you can't implement a cache
| optimized simulation algorithm in C++ and pass the
| results out to UE4 instead of whatever layer factorio is
| using.
|
| To be fair, factorio is a pretty good example of when the
| existing options offer limited value (lock step
| networking, _very_ simplistic rendering, very little in
| the vein of "gameplay" features), but it's one of very
| very few. For every factorio, there's 100 2d side
| scrollin platforms that are written in a custom C++
| engine rather than using unity.
|
| [0] https://factorio.com/blog/post/fff-209
| AnIdiotOnTheNet wrote:
| Using Unity for a 2D side scroller is like using a
| sledgehammer to swat a fly. 2D side scrollers don't
| really need much in the way of an 'engine'.
| maccard wrote:
| Reimplementing all of the features that unity provides
| for you is time spent on "just" adding a level editor,
| asset loading, character animations, scalable UI,
| collision detection, networking, state management,
| serialization,gamepad support, multiplatform support,
| store/platform integrations, when you could have been
| building a game. I can spend a month building a bare
| bones C++ engine that gives me all of the above and start
| into my game, or I can download unity, start with all of
| those features and spend a month working on my game.
| AnIdiotOnTheNet wrote:
| Sure, and then deal with leaky abstractions and fighting
| the engine wherever its abstractions don't give you what
| you want.
|
| > adding a level editor, asset loading, character
| animations, scalable UI, collision detection, networking,
| state management, serialization,gamepad support,
| multiplatform support, store/platform integrations
|
| None of these are nearly as hard as cult-of-always-use-
| an-engine makes them out to be. And there's value in
| having complete control over your product and
| understanding how every part of it works. You don't have
| to wait for Unity to support a new platform, or fix a bug
| that's blocking you, or implement a feature you want, you
| just do that yourself.
|
| I'm not saying it's the wrong choice to use a bespoke
| engine, indeed many games that are made with bespoke
| engines would not have been made otherwise and I'm
| grateful that such things exist and enable those games to
| be made, I'm just saying it's not necessarily a bad idea
| to make your own engine. Hell, Jonathan Blow is a
| successful game developer who made his own engines for
| Braid and The Witness, and now he's gone as far as making
| his own language and compiler to make games with going
| forward because he feels C++'s eccentricities get in the
| way too much.
| maccard wrote:
| > None of these are nearly as hard as cult-of-always-use-
| an-engine makes them out to be.
|
| I never said they were _hard_, but they take time. Time
| that can be spent on your game.
|
| > You don't have to wait for Unity to support a new
| platform, or fix a bug that's blocking you, or implement
| a feature you want, you just do that yourself.
|
| Every system has bugs. You're always going to have to
| make tradeoffs when building projects, and building an
| entire framework from scratch to avoid those bugs is
| throwing the baby out with the bathwater. You're trading
| the possibility of at some point in the future being
| blocked from developing a very specific part of your game
| for the guarantee of spending time up front yak shaving.
|
| > Hell, Jonathan Blow is a successful game developer who
| made his own engines for Braid and The Witness, and now
| he's gone as far as making his own language and compiler
| to make games with going forward because he feels C++'s
| eccentricities get in the way too much.
|
| Blow has shipped two games in 20 years, and one of those
| (braid) predates _any_ of the existing engines being free
| and easily accessible. Another of the "build it from the
| ground up" camp is Casey Muratori, who started handmade
| hero almost 8 years ago, and is nowhere even close to a
| game. The post we're commenting on here is entitled
| "Accidentally Making a Language, for an Engine, for a
| Game". If your take away from those things is that
| "you'll spend more time fighting the engine" then I don't
| really know what else to say.
| AnIdiotOnTheNet wrote:
| > Blow has shipped two games in 20 years
|
| You say that like it is a bad thing. By (nearly) all
| accounts Braid and The Witness are lovingly and expertly
| crafted, unconventional, and brilliant games. He's not
| making the annual Madden or Call of Battlefield here.
|
| > Casey Muratori, who started handmade hero almost 8
| years ago, and is nowhere even close to a game
|
| Be fair to Casey, Handmade Hero is primarily an
| educational project and he only devotes a few hours to it
| each week. Though admittedly he has allowed the scope to
| creep quite a bit from the original goals.
|
| > The post we're commenting on here is entitled
| "Accidentally Making a Language, for an Engine, for a
| Game". If your take away from those things is that
| "you'll spend more time fighting the engine" then I don't
| really know what else to say.
|
| My point is more that I'm kind of sick of people being so
| down on the concept of building your own engine even for
| relatively simple 2D games. Yes, I agree that it takes
| time, but so does learning the ins and outs of an
| existing engine and the time you invest in the latter
| nets you less generalizable skills than the former and
| leaves you with less control over the end product. It
| _is_ a tradeoff, and like all tradeoffs there are good
| reasons to go one way or another.
| Agentlien wrote:
| I think you're underestimating what can be done with the
| industry standard engines. From a rendering perspective
| modern game engines can handle so much stuff that it will
| fill your screen entirely. Just look at UE5's Nanite
| which supports ridiculously massive scenes and splits the
| frame into roughly pixel-sized triangles to render at
| interactive frame rates.
|
| If you do end up in a situations where you have more
| objects than is suitable for even these systems to
| simulate you don't need to throw the baby out with the
| bath water. Create your own managers running whatever
| simulation you wish without tying the units directly to
| the most obvious game engine entities, with whatever
| scheduling you need to make the updates work with the
| compute budget you have. Use the engine entities to
| represent whatever higher level object makes the code
| manageable and easy to work with.
|
| Then you can surely leverage the game engine for input
| handling, rendering, and a lot of your logic, just
| writing your own code for whatever challenges are unique
| to your game and where the standard approach for that
| engine is unsuitable.
| AnIdiotOnTheNet wrote:
| But you'll always be fighting the engine, because these
| kinds of "one size fits all" engines are complex enough
| to be essentially another operating system above the one
| you'd otherwise be dealing with. As long as your desires
| are well aligned with the abstractions it presents it
| will probably save you time, but the more you drift from
| that the less time it will save you and eventually
| there's a point where dealing with it costs more time
| than it saves.
|
| For the level of performance the Factorio devs want it
| makes sense they'd opt for maximum control over
| everything rather than fighting someone else's
| implementations.
| eternityforest wrote:
| Is that really true though? Aside from graphics and physics,
| which seems to be highly reusable, where's the performance
| critical stuff? Lots of engines seem to be mostly using
| scripting languages for everything a game developer needs to
| do.
|
| I wonder if there's a DBMS out there somewhere that already
| does what you need? Seems like by the time you got to a scale
| where you would need custom stuff, you'd have money to redo
| it(Unless it's a foss thing meant to be big but not
| commercial, or to run on a server you're paying for yourself)
| Agentlien wrote:
| I work specifically with video game performance, mainly as
| a graphics programmer, and often focusing on getting things
| to work well across multiple platforms. In my experience
| the performance issues are almost always a combination of
| how much is being simulated and rendered, how it's being
| rendered, and how much stuff is kept in memory at any given
| time.
|
| If you can improve culling before rendering and physics,
| minimize the surroundings streamed in to your immediate
| vicinity, and optimize some of the heaviest materials and
| post effects, that goes a really long way.
|
| Of course, there's an endless list of caveats depending on
| what your game specifically is, but even in an open world
| game where things happen off screen the above applies. You
| just have very simply LODs/imposters for faraway visuals
| and simplified logic running at lower frame rate for
| characters in other parts of the world.
| marginalia_nu wrote:
| Sure. What about simulation? Like I mentioned Factorio in
| your neighboring comment. It does things with a custom
| engine that you simply can't do using "highly reusable"
| systems.
|
| Existing engines are great as long as you want your game to
| look and behave like every other game written in the same
| engine. It's gotten to a point where a careful observer can
| tell which engine a game is written in just by looking at
| it and feeling how much input lag and framerate variance it
| has.
| paniq303 wrote:
| Oh no, we are on Hacker News. ;-)
|
| Hi, this is the yak shaving developer in question speaking. I
| was worried we'd get grilled hard over our slow progress, but
| I'm relieved to read that most of you understand how perilous
| and long-winded gamedev can be. Our backers are also very
| patient with us, and I don't want to destroy this relationship,
| but keep being as open and forthright as I can with our
| progress.
|
| I don't mind the jokes (after all, yes, the whole undertaking
| _is_ a bit ridiculous), but just want to make sure the facts
| are understood as they really are:
|
| * Yes, the premise of Nowhere continues to be that it's an
| alien life simulator (as in: simulating the everyday life of an
| alien).
|
| * The game is being developed by not just one, but two people:
| My wife Sylvia Ritter[1] is responsible for the concept art
| that drives the procedural design (she has given me a lot of
| work), and I am responsible for programming and direction. We
| both have a hand in the game design.
|
| * Yes, development is still going strong, and will continue to
| do so, until the game is done or I keel over, whichever comes
| first ;-)
|
| * Yes, I am absolutely yak shaving, and there's definitely some
| sunken cost thing going on here, but there is still no project
| I'd rather work on than this one. When we launched the
| crowdfunding, I had a hunch that this would end up taking us 10
| years. Now we are on the far side of it and I had to start
| cutting features and workflow improvement ideas in order to
| have a chance at making it in time.
|
| * Yes, I developed a programming language for the game, because
| the art is procedurally driven, and that requires both fast
| turnaround in prototyping (close to Scheme or Python) while
| providing C level performance at the same time. There simply
| was at the time that I started, and still is, no adequate
| solution available. Originally, I didn't want to do it, but we
| rationalized that innovation of technique requires innovation
| of tooling, and hence worth the effort, provided we'd open
| source everything we made in pursuit of our goal.
|
| * No, Scopes' string implementation is complete for several
| years already, the recent commits are all touch-ups,
| augmentations and small fixes for the userbase that has grown
| around the language, which were quick to do and cost me no
| significant time. We have in fact other, much larger, support
| problems that I can not adequately cover because the game is
| main priority, and the language exists to service the game.
|
| * Yes, I developed a pure functional reactive language on top
| of Scopes for our game engine that I wrote a few examples with,
| in the intent of finally merging the CPU and GPU models so we
| save 90% of pointless and repetitive boilerplate code for
| CPU/GPU resource management. It's a fantastic idea that is
| going to go places, but after realizing how much more I'd have
| to write to get it all the way to its final, visual programming
| oriented form, I aborted the prototype and focused back on the
| game.
|
| * What else have I spent my time on? I spent most of those
| years writing a bunch of prototype shadertoys to explore
| possible technology used for the game and also teach
| mathematical concepts to other developers, and they're all
| released here[2]
|
| * What's going on right now? After streamlining package
| management[3] for both Scopes and Nowhere, I am presently
| working on our sculptable terrain engine. There is a by now
| somewhat outdated video demo[4] of one of its earliest
| incarnations. The LOD stitching has been fixed, and we have
| occlusion culling now, but I still have to rewrite parts of it
| to get a rock solid sub 10ms per frame performance. It would
| have been more fun to do all that with FRP instead, but tooling
| is never quite where you want it.
|
| Thanks for reading all that,
|
| Leonard
|
| [1] http://sylvia-ritter.art/
|
| [2] https://www.shadertoy.com/user/paniq
|
| [3] http://majoreo.rocks
|
| [4] https://www.youtube.com/watch?v=5JOzqsJZmCo
| pkaye wrote:
| Now I know how to get funding to develop a cool programming
| language!
| tikkabhuna wrote:
| Game development methodology has fascinated me recently. With
| the Battlefield 2042 debacle, its interesting to compare it to
| what I know (financial trading platforms).
|
| With trading platforms, they last for years, decades maybe.
| They're created with some ideas around how to manage
| performance and to support evolving requirements. Developers
| know this thing is going to be around for a long time, so its
| treated as such. Years down the line, you start creating a new
| platform and look to do a long migration to keep clients happy
| because you can't just turn off their favourite functionality.
|
| Modern AAA FPS games seem to be the complete opposite. Reinvent
| significant amounts every release. Dump the old game as the new
| one is released. Much seems to be from scratch. The BF2042
| scoreboard issue seems like it should be almost off the shelf.
| There also seems to be this big shift towards short release
| cycles which pushes even more churn and reinventing the wheel.
| Look and feel must be updated to keep things "fresh". Although
| most of the popular games on Steam[1] are older games that have
| been around for years.
|
| So many places to shave a yak, I'm surprised games get shipped
| at all.
|
| Of course take all of this comment as an outsider who just
| yearns for the old days of cool mods and custom servers.
|
| [1] https://store.steampowered.com/stats/
| midnightclubbed wrote:
| The days where AAA games dumped the engine between releases
| are long gone (like Playstation 1 long gone).
|
| For franchise games there will be incremental improvements to
| engine systems; some to support new gameplay features, some
| to help with development tooling/pain-points, and some to
| improve visual fidelity. The trick is choosing the correct
| number of upgrades/refactors that fit the release schedule
| while remaining relevant and not dooming your next franchise
| release with insurmountable feature debt.
|
| In my experience the biggest engine changes come with new
| hardware platform support, typically a console generation
| jump. More power requires a toolchain that can handle more
| complex assets (and more of them), new graphical features and
| expectations, different optimizations, new API, different
| storage types or capabilities etc. Bigger franchises may use
| a new console generation as an opportunity to gut an existing
| engine and rework to the strengths of the new hardware
| generation (and remove the support for older hardware, such
| as removing 32bit pointer support, DirectX9, Windows7 etc).
|
| Historically where game engines get in trouble is when a
| codebase is written to one franchise and then forced on to a
| team making a fundamentally different game with fundamentally
| different requirements (open world vs compact maps, physics
| heavy vs platformer, single player vs MMO). At the executive
| level it makes total sense, they spent x million$ on a game
| engine and are told by everyone how great an investment it
| was... why not spin up a new game using that amazing (and
| paid for) technology?
|
| The flip-side has also sunk numerous game engine efforts,
| which are often buried without ever becoming public. Doing
| everything all at once is impossible, you can either do many
| things generically but with restricted performance and
| capabilities. Or you can do 'everything' required by a
| specific game and slowly introduce features that support
| other games and make things more generic.
| jhanschoo wrote:
| > Modern AAA FPS games seem to be the complete opposite.
| Reinvent significant amounts every release. Much seems to be
| from scratch.
|
| I think this should be qualified. The audience and creative
| workers demand new assets for new titles, but gameplay
| concepts and codebase seem to move at a slower pace, though
| live services seem to be distinct systems and not expected to
| live long, of course.
|
| On one extreme, you have EA's sports titles, where new
| releases have just incremental updates.
| adampk wrote:
| If you don't mind a digression for someone who needs help...
|
| What is the architecture pattern of a trading platform?
|
| I am looking to build a system that is able to: - receive
| 1000s incoming streams of data - save the data - make data
| available to live subscribers
|
| The closest analogous system I can think of is
| bond/stock/commodity/etc price subscriptions for traders.
|
| I feel like this many in - many out data stream architecture
| should be solved by now and I rather not start from scratch
| in architecture and technology choices.
|
| I can't find the right phrase to even google to get started.
| tikkabhuna wrote:
| I assume your live subscribers are external people over the
| internet?
|
| The trading platforms I've worked on tend to order things
| into a single stream that you can act upon. This helps with
| testing, race conditions, auditability. You will want to be
| able to replay an exact series of events to recreate
| conditions.
|
| LMAX Disruptor[1] and Aeron[2] are two open source examples
| of something widely used, either using the libraries
| themselves or as concepts.
|
| Some things that trading systems (generally?) need which
| you may not, which might simplify your architecture:
|
| - Every message must be delivered and in order. UDP is
| usually used over TCP, as the platform will likely want
| more control over handling missed messages. - It will be
| common to have read/write applications that need to add a
| message as a response. Writing is difficult as you need to
| be quick, otherwise a subsequent message from another
| application might invalidate your message.
|
| Do subscribers need older data? How do dropped packets
| impact the system? Can they just be forgotten? What latency
| requirements do you have? Do subscribers also write to the
| same stream?
|
| - [1] https://lmax-exchange.github.io/disruptor/ - [2]
| https://github.com/real-logic/aeron
| shultays wrote:
| Well, it's been eight years, and development is still going
| strong! The developer is currently working on the
| String implementation for the programming language he
| invented[2], which he's using to write the other programming
| language he invented[3], which is eventually going to be used
| to write the game.
|
| Haha, sorry but was that intentionally snarky or just happened
| to be?
| matheusmoreira wrote:
| Truth is developing the engines is a lot more fun than
| developing finished products. Game engines are like virtual
| machines purpose built for interactive audiovisual program
| execution. The games themselves aren't that interesting.
| Operating systems are fun, the applications running on them are
| boring. Browsers are fun, the web sites are boring.
| mattgreenrocks wrote:
| Working on languages and runtimes is just fun on its own. It
| ends up pulling in many facets of CS: graphs, perf, grammars,
| automata, resource allocation, etc.
| ngc248 wrote:
| The name is apt then, since its nowhere :)
| ReactiveJelly wrote:
| Hey, making games isn't my job, so I'm just as happy making
| OpenGL demos instead of games.
|
| > It's like I've been driving a Honda Civic in city traffic, and
| now I'm in a BMW cruising down the highway.
|
| There's a certain satisfaction in doing my own thing, even if
| it's crappy. Like Gilfoyle's electric car in "Silicon Valley".
| throwaway81523 wrote:
| Greenspun's 10th law?
| jokoon wrote:
| I decided to use Godot to make a lowpoly online FPS, I don't
| think it's a great choice, but I've read good things about godot
| networking...
|
| I first wanted to make it in C++ and opengl, and it did not look
| like a difficult thing to do, but godot is good enough for a lot
| of things, it's small, and it allows me to do multiplatform,
| which is such a big bonus, since C++ is never easy to use on
| several platforms.
|
| I have no idea if I will be able to implement network prediction
| with godot.
| candiddevmike wrote:
| Are you using GDScript? How are you liking it?
|
| To me, the biggest hurdle with game development is always
| assets. I'm a terrible artist/musician.
| jokoon wrote:
| Well it's not as comfortable as python, but it's good.
|
| I plan to make assets using procedural generation of terrain,
| building indoors and streets.
| verdagon wrote:
| Always a pleasant surprise to be scrolling through HN and seeing
| one of my articles on the front page!
|
| For anyone interested in how that code would get zero memory
| safety overhead without the classic borrow checker, a big part of
| it is because of the "region borrow checker" [0]. There are some
| other factors (iso regions, hybrid-generational-memory, etc.) but
| region borrow checking is the big one.
|
| [0] https://verdagon.dev/blog/zero-cost-refs-regions
| mijoharas wrote:
| fyi, your links on that page to hybrid generational memory seem
| incorrect (i.e. 7 in the sidebar, but I think there was
| another).
|
| I'd not heard of vale, but after reading around a little looks
| very interesting. Nice job!
|
| [0] https://verdagon.dev/blog/hybrid-generational-memory
| ilovejosysss wrote:
| readthenotes1 wrote:
| It was Fred Brooks, not Confucius who said that, but I think
| you got the date right.
| runevault wrote:
| To someone else's point the article says it was not implemented
| yet at the time. Assuming it is I'd love to see a follow up
| after you built what you discuss in this post.
| EdwardDiego wrote:
| Is this blog entry out of date? Or is this still a WIP?
|
| > Note that hybrid-generational-memory is not implemented yet,
| it's still just a design.
|
| From https://verdagon.dev/blog/hybrid-generational-memory
| vsroy wrote:
| What are some of the interesting tradeoffs this language has
| made? Ideally with super small code samples
| skywal_l wrote:
| The author details some of them in the "Featuring" section in
| the front page [0]. There is also a comparison with different
| languages [1].
|
| It seems the language is still in very early stages. Not
| production ready.
|
| [0] https://vale.dev/
|
| [1] https://vale.dev/comparisons
| arduinomancer wrote:
| I don't get why are programmers so obsessed with the tools they
| use for the job?
|
| More than any profession
| linspace wrote:
| Aren't computers tool themselves? It's only natural people
| interested in computers are interested in tool making
| carrolldunham wrote:
| I can't believe all the catty defensive replies. The answer is
| that programming is designing automation (automatic
| computation) and functionality of computers. So getting into
| that mindset naturally leads to "well, what If I can automate
| what I'm doing too? What if I can make a function that makes
| these functions?". Not to mention, a gardener isn't tempted to
| trim his rake into a better rake, because that wouldn't work -
| the tools are made by a different process than what they are
| used for. Not so in programming
| tikhonj wrote:
| Why are musicians so obsessed with their instruments? Just use
| the right tool for the right job, don't call yourself a
| "pianist" or a "drummer", call yourself a _musician_.
| TillE wrote:
| Yeah semi-pro musicians are probably the worst. It's really
| easy to get obsessed with both accumulating shiny new (or
| vintage) toys, and tweaking your favorite instruments so
| they're set up exactly how you want.
| Rochus wrote:
| Because it takes the fameous 10'000 hours to become a master?
| pjmlp wrote:
| That is what being a music composer is all about actually,
| not siloing oneself in a instrument category.
| eternityforest wrote:
| Playing an instrument is harder than any basic non-
| mathematical programming. It's almost shocking to finish a
| project, clock out, practice guitar a bit and realize the
| difficulty difference.
|
| Buying stuff on the other hand is very easy.
|
| Just like running is(I assume, having never seriously done
| any sports) way harder. Buying more crap and then not even
| using it is easy.
|
| Everyone always wants their fast instant gratification hits,
| regardless of hobby.
| alx__ wrote:
| Obsession with the tools is part of every interest/job/hobby!
|
| There's always someone who thinks: "I could make this better".
| Some of them even try to. Emphasis on try :)
| astrange wrote:
| Rich amateur photographers are a lot more concerned with
| their tools than professionals are, and about different parts
| of the toolset too.
| stuu99 wrote:
| rileyphone wrote:
| Because languages are not tools, but rather media. They are the
| basis for the structured thought that unveils, as such their
| form and function is critical to the process of programming.
| burnished wrote:
| You should check out the comment section of a woodcrafting (or
| the like) Youtube channel. I think 'tool obsession' is probably
| a personality trait and one you're more likely to see in your
| day to day in programmers than in other crafters due to
| proximity to the internet. Oh, sewing rooms are another good
| hit for that as well.
| omniscient_oce wrote:
| In Table Tennis we call it "being an EJ" or "EJ-ing" where EJ
| stands for Equipment Junkie.
| burnished wrote:
| ..what kind of equipment do you even get in Table Tennis? I
| understand there are different makes of paddles but I
| thought it was limited to a couple materials applied to one
| or both sides. If you don't mind I'd love to know more.
| sandos wrote:
| The rubber and the wood (or other material) itself, that
| is enough for people to delve deep into. Different
| rubbers on different sides.
| omniscient_oce wrote:
| The wood part is called the 'blade' in English and there
| are MANY different brands and models. They come in either
| 5 ply or 7 ply, where it might be full (5 or 7) wood or 5
| wood plies + 2 thin carbon wafers. I use a carbon blade
| (Viscaria) - they are more stiff with less vibration, or
| feedback, but generally have a higher speed ceiling and
| larger sweet spot at the expense of a little bit of
| control at lower speeds (gears). The other component of a
| setup is the rubbers, you can have one black rubber and
| one red rubber (although new colours are soon being made
| an official part of the sport) - generally they're split
| into two categories "tensors" and "tacky" or "chinese"
| rubbers and recently "hybrid" rubbers. Rubbers are
| comprised of a sponge and a top-sheet - which
| manufacturers can customise to produce different playing
| characteristics. Long story short: tensor rubbers
| historically were favoured by Europeans (on both sides,
| whereas Chinese would use a hard tacky rubber on forehand
| + softer tensor backhand) and are more elastic with built
| in catapult effect. They require less physical effort to
| produce good spin and speed. Tacky Chinese rubbers are
| very hard with a very tacky surface, the harder sponge
| makes them easier to control at low gears (close to the
| net for short game) and have great top-end spin as well
| as spin on serves. They require more physical exertion
| and efficient use of the body to use effectively
| (although there are also substances called "booster"
| which we apply to make hard tacky rubbers come alive).
| Hybrids are a sort of mixture of the two that have become
| popular with the new 40mm plastic ball and can be used on
| either side. Typically you will use a harder rubber on
| the forehand than on the backhand, but it's up to
| personal preference.
| vasco wrote:
| The first page of results for "table tennis ej" on Google
| has all the answers. I had no clue about it either.
| bobnamob wrote:
| As much as I think the other replies to this question hit the
| nail on the head, I think there's more to it than just tool
| obsession.
|
| Software developers are in the fairly unique position where
| most of our tools are software defined. We are experts in the
| discipline required to improve our own day to day work lives.
|
| How many other professions have this liberty? Woodworking does
| to an extent, carpenters regularly make their own jigs and
| clamps but rarely venture into the realm of sharpened tools.
|
| Contrast this with anyone working in the medical or retail(?)
| industries. People working in these fields are close to
| powerless to improve the tools they use every day.
|
| Embrace the tool improvement life, there's still a long way to
| go before software tooling is "finished"
| eternityforest wrote:
| It's hard to tell what benefit there actually is from this
| kind of thing. There's definitely great new tools developed
| all the time, but most of them seem to be planned
| megaprojects.
|
| I've never seen a custom build system or VCS or
| personal/project specific tooling I'd want to use.
|
| Seems like most of it happens just cause devs enjoy it.
|
| Making your own clamps seems very much the same.
|
| The other reason is there's a real cult of assuming that
| minimal is always best, and devs resent using any tool that
| has more features than they absolutely need.
|
| They also resent any more opinionated structure than they
| need, even if it makes things safer and easier, because they
| seem to really enjoy blank canvas creativity.
| arduinomancer wrote:
| Ya this is what I was thinking as well, the unique thing is
| that making the tools and doing the work are the exact same
| process
|
| Plus its just very easy to work on a tool, I don't need to go
| buy a bunch of materials or anything
| exdsq wrote:
| You should see the arguments gardeners can get into over
| lawnmowers
| Agentlien wrote:
| I am only moderately into gardening and somehow I've ended up
| with three lawnmowers.
| SeasonalEnnui wrote:
| For any comparison to C# (it being slower or having GC pauses),
| it probably doesn't take into account the latest advances (.NET
| 6). That's understandable given there isn't really incentive to
| gain a mastery in every language during a comparison.
|
| With regards to C#/.NET 6, it is now easy to:
|
| - Have zero-allocation code through the whole stack, making
| garbage collection zero/near-zero. [Span<T>, Memory<T>]
|
| - Distribute platform specific all-in-one binaries with no
| unbundling/uncompression or need to install any runtime. [dotnet
| publish -r win-x64 -c Release -p:PublishSingleFile=true
| -p:PublishTrimmed=true]
|
| - For hot-path optimisation (many available profiling tools),
| dive into new high-performance APIs such as CPU vector
| intrinsics, or native memory allocation (aligned or unaligned).
| [System.Runtime.Intrinsics.X86,
| System.Runtime.InteropServices.NativeMemory]
|
| - For faster startup times: AOT compilation. (Not necessarily
| faster at runtime in general; JIT has advantages there with being
| able to detect hot paths)
|
| These are just the features I've used, there are doubtless many
| more. In the future .NET 7, it will be possible to disable
| runtime marshalling so interop calls to C DLLs have no overhead
| (along with a compile-time analyzer to throw errors if the types
| you're using are not compatible, aka 'blittable').
|
| Credit to Vale - it appears to be addressing all these things so
| there's certainly an interesting future ahead.
| pjmlp wrote:
| I think many of these complaints tend to be focused on the
| aging Mono runtime experience used by Unity pre-DOTS, or
| classical pre-.NET Framework 4.5.
| SeasonalEnnui wrote:
| Agreed, that would be a worthwhile caveat for authors to add.
| ncmncm wrote:
| That just seems like poor discipline.
|
| But not like creating a typesetting system to use to write your
| book.
|
| It seems like it is shaping up to a pretty nice language. But
| writing the compiler in itself is very 20th-century. Just add a
| parser to LLVM or Gcc and call it good.
|
| But don't make the mistake C, C++, and Rust did, using a prefix
| dereference operator. Pascal got that one right.
|
| BTW: "get" in a pure function name is code smell. More generally,
| transitive verbs in pure function names are code smell.
| lifthrasiir wrote:
| > [D]on't make the mistake C, C++, and Rust did, using a prefix
| dereference operator.
|
| This is only a mistake when the deference is frequently
| followed by postfix operators, in most cases field and method
| accesses. Unlike C or C++, Rust does auto-dereference that
| essentially eliminates such situations and thus a prefix
| operator doesn't do much harm.
| miloignis wrote:
| Based on the "Compiler Overview" page, they do use LLVM for
| codegen: https://github.com/ValeLang/Vale/blob/master/compiler-
| overvi...
| slewis wrote:
| This comment is a roller-coaster and I love it.
| quickthrower2 wrote:
| Writing the compiler is YACC shaving.
| stevage wrote:
| The difference is the original goal of writing a game was
| frivolous anyway, so it doesn't matter if it gets done. Whereas
| if you have a book contract, writing LaTeX instead is a bit
| irresponsible.
| ffhhj wrote:
| If someone had told me the second part of that mantra: "... but
| don't make a game, make an MVP and check with your friends if the
| game mechanics are fun, first!"
| RugnirViking wrote:
| We did this for Patafour https://github.com/OwocekTV/V4Hero
|
| Hasn't gone quite as far as making our own language, we did it
| all in c++. For us we know doing things this way is a vastly more
| difficult approach, but nonetheless we plough on. Yesterday I was
| learning how bezier curves work so we can animate wind effects.
| The list of interesting maths and physics problems to solve are
| endless but oh so satisfying, and ultimately its a hobby not
| something we sell for money.
| Magnusmaster wrote:
| Vale looks very interesting and I hope it takes off
| Nijikokun wrote:
| It's unfortunate that the majority of comments are centered
| around Yak Shaving rather than the amazing leaps that this small
| language has done.
| eternityforest wrote:
| Yak shaving is easy to understand and evaluate, whereas the
| value in creating a language makes no sense to anyone outside
| the language scene.
|
| Most people have no way to guess of the new ideas will be
| influential, but we do know we aren't interested in using niche
| tools regardless of what they are.
|
| It could be an amazing leap forward for computer science, or a
| slightly interesting toy, and either way it's above most
| people's heads.
| pjmlp wrote:
| Every year millions of CS students invent new languages, and
| publish SIGPLAN papers about them.
|
| This language is great for the author as learning process, and
| that is about it.
| alwyn wrote:
| I didn't even know what yak shaving was! Not sure if I'd ever
| heard the term before.
|
| Alas: http://catb.org/jargon/html/Y/yak-shaving.html
| ryukoposting wrote:
| How timely! I'm sketching out a visual novel engine that
| implements a simple DSL (think of it like Ren'Py, but with Ruby
| instead of Python). Yesterday, I spent hours rewriting the line-
| by-line preprocessor into an LR parser.
|
| Oh, and I had to write my own FFI library to bind into the MRI.
|
| Oh, and the language I'm using has an SDL2 library available, but
| it was incomplete the last time I checked.
|
| Fun!
| Townley wrote:
| It's interesting that this phenomenon is much more prevalent in
| game development, as opposed to (for example) web development:
| some people build their own web development frameworks, but it
| seems like every game dev tries to make an engine at some point.
|
| My theory why: good web frameworks consider developer experience
| to be of paramount importance, and invest heavily into examples,
| documentation, and API improvements. Unreal and Unity by
| comparison are unpleasant to work in. The UI is clunky, the
| examples cap out after a certain point of complexity, and
| community input is almost nothing when compared to the Django,
| Express, Rails, or language-specific ecosystems.
|
| Anyway, I can't say I've ever made it far enough down the rabbit
| hole to want to make my own language... but I know for me, the
| desire to make my own engine* has punctuated every attempt over
| the years to get better at both Unity and Unreal
|
| *Acknowledgment that I might be partially disproving my own
| point, as I've tried to build both my own web framework, AND my
| own game engine... but I spent a lot more time on the game engine
| (https://github.com/RobertTownley/gamehook)
| pizza234 wrote:
| Probably, many programmers played videogames when they were
| little, so there's always an underlying dream of creating one.
|
| I dabbled in games development, but I've met the same problem;
| videogames development is actually much more than programming
| (the engine), and the creative part, which is the primary one,
| may not appeal people who are technically-minded.
|
| This phenomenon is very visible in Rust; there are several game
| engines, but very few production quality games. The most famous
| game engine, Bevy, is very popular, but after approximately two
| years of development is still an alpha (and a very changing
| one); contrast this with Fyrox, which is much more stable, but
| is considerably less popular (essentially, unused).
| coptun wrote:
| Take a look at Godot. At least then it will be "our own game
| engine" rather than "my own game engine".
| BeefySwain wrote:
| Speaking of making a language for an engine for a game...
| blt wrote:
| I pondered this for a while, still not sure why.
|
| It could be the connection to the physical world. There is
| something satisfying about working with geometry and
| differential equations.
|
| The realtime constraints force you to care about performance,
| which many people find a fun challenge.
|
| Your output is the frame buffer instead of the DOM. It's more
| of a blank canvas.
|
| Most web development is utilitarian, whereas games are more
| artistic.
|
| I am not sure, but I would love to be a game engine developer
| in another life. I have zero interest in web framework
| development.
| vvanders wrote:
| I would hazard that game engines are an order of magnitude more
| complex than web frameworks. A better analogy may be game
| engine vs db engine or web framework+runtime(ex:
| Erlang/Elixir+Phoenix). If you have performance issues with a
| web framework you can scale it horizontally to a
| degree(depending on downstream dependencies like your DB).
| Games are built to run against resource constrained hardware
| and so they optimize for specific usage patterns.
|
| There's also the issue that most engines are built to be good
| at a specific game type and may make trade-offs in terms of how
| assets are managed and scene complexity. An open-world has much
| more different requirements than an on-rails shooter. For
| instance I had to do some pretty heavy retrofitting of one of
| those engines to handle LoD/geometry streaming and a bunch of
| other optimizations to make them work well with a large sight-
| distance game.
| pjmlp wrote:
| Depends on the game engine, most 2D ones are quite
| comparable.
| Kuinox wrote:
| No no, browser contain components similar to a game engine,
| browser are way more complex, and frustrating, because you
| do not control the specs.
| pjmlp wrote:
| Depends on what the game engine X and Web Framework Y are
| trying to achieve.
| Kuinox wrote:
| That's true, but you can see new open source engines
| rising becoming a serious choice to make games. Not so
| much for web browsers.
| pjmlp wrote:
| Depends on the motivation and how much of ChromeOS one
| wants to implement.
|
| https://twitter.com/awesomekling/status/15089533948363530
| 24
| meheleventyone wrote:
| I'd go an order of complexity above again. The real
| comparison is to the browser, particularly for general
| purpose engines like Unreal and Unity. I'd hazard most game
| engine teams are bigger than most browser teams.
| j-krieger wrote:
| I disagree. Modern web browsers are the most complicated
| pieces of technology we have today. The amount of work that
| goes into sandboxing and security alone probably eclipses
| the complexity of game engines.
| WJW wrote:
| That seems very optimistic when compared to some of the
| bigger engineering projects we have going as humanity.
| Aircraft carriers and nuclear submarines as a whole
| system (including the multiple computer networks and
| their software) are much more complex than browsers, to
| say nothing of one-offs like the ISS (lots of cutting
| edge hardware but also full of software) and the systems
| controlling modern factories. Browsers don't even come
| close.
| remus wrote:
| I think it's kind of hard to quantify complexity in a way
| that compares nicely across domains. For example, a lot
| of the complexity in a browser comes from needing to
| service ~billions of users across thousands of devices
| using loosely implemented standards. This is quite a
| different problem to building an aircraft carrier, where
| you're going to run in to hard engineering and physics
| problems but you only have to target ~10k well trained
| users.
| eternityforest wrote:
| Web frameworks are nowhere near as complicated as
| browsers
| dagw wrote:
| _I'd go an order of complexity above again._
|
| Not when you start. While UE5 is no doubt orders of
| magnitude more complex than any web framework, no one sets
| out to write UE5. In fact most people start writing their
| own game engine because they want something a lot less
| complex and more tailored than what is available.
|
| If you have the right background knocking out a very simple
| game engine isn't hard. Many people do it as part of a
| university course. The problem is that your 'simple' game
| engine ends up being not that simple very quickly once you
| start adding features.
| meheleventyone wrote:
| Right which is why in the following sentence I limit it
| to general purpose game engines like Unreal and Unity.
|
| Making a toy browser is something you can do as well.
| boredtofears wrote:
| Making a game is at least an order of magnitude harder than
| making a website. Web apps are constrained by the protocols
| upon which their built (mostly the lifecycle of HTTP requests).
| Games are gigantic state machines that also require complicated
| rendering cycles. Unity and godot et el ARE good developer
| experiences in that they remove much of the complicated stuff
| even if the abstractions they use require them to be a bit
| clunky.
| dagw wrote:
| _Making a game is at least an order of magnitude harder than
| making a website._
|
| Ridiculous statement. Making a polished AAA game is orders of
| magnitudes harder than making a React ToDo Clone. Making a
| Tetris or Snake clone is orders of magnitude easier than
| making Gmail. With engines like Unity you go from never
| having written a game to a shitty 3D fps game in a weekend.
| Aeolun wrote:
| This is only true if you talk about the average website, and
| the average game. Because there is a lot of wordpress spam.
|
| I can practically guarantee that any given AAA game is less
| complicated than the horrible morass of complicated system
| requirements a multinational company can invent for their
| internal systems.
|
| Mostly because it's designed to approximate reality, which is
| complex.
| qw wrote:
| Web developers may not create their own frameworks as much as
| game developers, but many spend a lot of time switching
| frameworks, libraries or simply just rewriting existing
| applications. I see this tendency at work, where the relatively
| simple React app has been rewritten 4 times in a couple of
| years. The recent hires would rather rewrite it from scratch
| than to refactor / improve the existing one. Apparently, the
| 5th rewrite will solve all problems with the first 4...
| Agentlien wrote:
| I've worked with a lot of game engines, and indeed made my own
| engines and editors.
|
| My reason for making my own was partly that it felt like less
| work to write what I needed than to learn the intricacies of an
| existing engine. Also, back then the big engines didn't have as
| generous licenses as now.
|
| As for Unity and Unreal: I found them both very easy to get
| into and get productive with.
| scotty79 wrote:
| > [...] prevalent in game development, as opposed to (for
| example) web development [...]
|
| Everybody made their own framework before some of those became
| popular. And people are constantly producing new frameworks.
| Because it always will be more entertaining and meaningful for
| someone to build a framework/engine that feels good than yet
| another app/game.
|
| Not to mention many compiled to js languages made by and for
| webdevelopers.
| j-krieger wrote:
| Both industry leaders and indie programmers have used Unity and
| Unreal to make finished games. Large studios may opt to create
| their own engines at one point or another, but even with all
| their resources, these custom engines don't always work out.
|
| An example of this would be the frostbite engine, of which
| multiple devs at EA reported that it was an absolute nightmare
| to work with. Turns out, if you need developers to work on the
| engine at the same time the game is developed, you just lose
| manpower to actually engineer your game. [1]
|
| [1]: https://www.usgamer.net/articles/ea-frostbite-engine-
| history...
| Agentlien wrote:
| I worked with Frostbite for five years. The engine is very
| capable. It's also developed in a vacuum with very little
| exposure to actual game development.
|
| It's used to create fancy new features and show them off in
| tiny toy projects. Then it's handed off to developers to make
| actual games and the issues begin.
|
| The biggest issue with Frostbite was always that its
| developers treated it like an ever revolving set of cool new
| projects. There was always some fancy new system meant to
| replace the old one in just a few years and never any fixes
| for the shipped and still broken systems.
| jfoutz wrote:
| I think part of it might be learning how to ask good questions.
| I wrote a terrible terrible C compiler for a class. But I
| learned so much about the choices between doing things the slow
| but probably correct way, vs the cool but hard way, or even the
| jaunt into esoteric decisions. This more than anything else in
| my career taught me how to evaluate random software. As a
| professional, or even serious hobbyist, I think it's a good
| idea to dive deep, build one yourself. Really get a feel for
| the tradeoffs and hassles of different choices.
|
| Even if nothing goes anywhere, it'll improve your craft.
| russellendicott wrote:
| This comment speaks to me. I hate modern web development but
| I always want to build user interfaces so one day, I thought
| to myself "Why don't I start from scratch and make my own
| protocol and write a browser but only for the terminal?"
|
| So that's what I've been doing and it's been a lot of fun. A
| lot of the time I'm pulling concepts from HTTP but what's
| great is that I can be very picky. Maybe I'll end up just
| rewriting HTTP but at least I'll understand deeply why all of
| those decisions were made.
| prewett wrote:
| If you want to build user interfaces, I'd recommend
| learning Cocoa or Qt, which are both well-designed UI
| libraries. (Java/Swing is okay, but Win32 has a limiting
| design, and MFC is crap. Was pretty unimpressed with
| Android's UI, but haven't really used it enough to have a
| quality opinion.) HTML was designed for documents and its
| model is unsuited for UI. If you're going to learn for
| research first, then in my opinion you'd be better off
| learning how to do it right, and then if you still want to
| use the DOM, you'll have a better idea on what would be an
| effective framework to make/use.
| Razengan wrote:
| Because making websites isn't near as fun as making games.
| csande17 wrote:
| For me, at least, I like to write my own engines to get the
| _end-user_ experience I want. Every game engine comes with a
| million little decisions about how games should work by
| default, and writing my own engine lets me make those decisions
| for myself.
|
| In the same way, every React app eventually starts to look and
| act like the Reddit redesign, but many web developers consider
| that more of a benefit than a drawback.
| mrcartmeneses wrote:
| That might be because there is a lot more creative freedom in
| game development because playing a game is essentially an
| exercise in coming to an understanding of the underlying
| dynamic. And a game is played for fun.
|
| Conversely users of a web app generally don't want to invest
| any time in understanding its underlying dynamic and instead
| want something that works in a familiar way. So we optimise
| for that.
| quickthrower2 wrote:
| That many react apps look like that is not a react thing but
| a design thing. You can make a react app that looks like HN.
| Or like a game!
| onion2k wrote:
| You can make a React app that's wildly different to all the
| others, but if you follow "best practises", and you learned
| from the same tutorials, and you're using the same
| component libraries as other React devs your app will
| probably drift towards looking and working like other React
| apps unless you make a conscious choice to stop that
| happening.
| csande17 wrote:
| Yeah, one difference between React and, say, Unreal
| Engine is that Unreal Engine is the brand for the whole
| package while React is the brand for one of the core
| components. ("I'd just like to interject for a moment.
| What you're referring to as React is, in fact,
| React/Redux/Tailwind...")
|
| Once you've bought into the whole ecosystem, you get an
| "engine" that wants your app to look and work a certain
| way just like how Unreal wants your game to look and work
| a certain way. You can customize it however you want, but
| every decision you _don 't_ make is made for you by the
| engine.
|
| And even when you are making the decisions, the engine is
| always there, nudging you in a certain direction by
| making some things easier than others.
| j-krieger wrote:
| That is just not true, no matter how hard you try to make
| it seem that way.
| quickthrower2 wrote:
| There is some truth.m to that. Tutorials need to decide
| where to focus on React but want to make you feel like
| you are building something cool so they will bring in
| style frameworks to assist so you can focus on the react.
|
| I assume this is also true for jquery/angular/vue and
| other library tutorials.
|
| Maybe just for fun they should use alternative
| frameworks!
|
| Then on the job, well unless you are a designery company
| it will be devs who do design and will happily delegate
| that thinking to a framework. Again not a react thing but
| a general dev thing.
|
| I have seen this too in desktop apps of 90s. Just use MFC
| or some popular toolkit.
| iamsaitam wrote:
| "In the same way, every React app eventually starts to look
| and act like the Reddit redesign, but many web developers
| consider that more of a benefit than a drawback." - Erm,
| nope. You might be talking about people relying on UI
| component libraries, which has nothing to do with React.
| neoberg wrote:
| I've been using React full time almost since its first
| release and I somewhat agree with the previous comment.
| While the choice of framework usually doesn't really
| restrict what can be done; it's often easier/harder to do
| specific things with a given framework.
|
| For example; animations responding to user interactions are
| easier to do in frameworks with an OOP approach. It is
| generally more "different" in a declarative way. So most
| React apps simply don't have those. There are lots of small
| things like this that over time make React apps feel
| Reacty.
| maccard wrote:
| > every React app eventually starts to look and act like the
| Reddit redesign,
|
| Not every unreal engine game starts to look and behave like
| gears of war. If you drop a bunch of asset packs from the
| store it's going to look like every other asset flip out
| there, but so will your game engine if you use the same
| assets.
|
| > , I like to write my own engines to get the end-user
| experience I want.
|
| My day job is working in unreal engine, and in the last 7
| years of using it I can only think of one scenario where the
| engine was the limiting factor in the user experience I
| wanted, and not something I could easily work around. If you
| think you're going to be limited in your end user experience
| in unity or unreal you probably need to reconsider how much
| you know about those engines.
| simulate-me wrote:
| Many Unreal games released around the time of the original
| GoW did look very similar though. I think it was the
| lighting. Two examples: Bioshock and Batman Arkham Asylum.
| csande17 wrote:
| I don't think anything is _impossible_ in big commercial
| engines. I mean, IIRC Unreal Engine gives you a Visual
| Studio project containing all of the engine 's C++ code, so
| theoretically if you use Unreal your game could be any
| legal C++ program.
|
| But as a practical matter, using Unreal turns every
| decision you make from "what behavior do I want" into "what
| behavior do I want and is it worth fighting Unreal on
| this", so Unreal games are a lot more Unreal-y than they
| otherwise would be. (This is especially true on PC, where
| things like "how are the game assets organized on disk" are
| visible to end-users.)
|
| Particularly on the 2D hobbyist stuff that I do, writing my
| own engine is less work than becoming an expert in an
| engine I don't really like so I can change most of it.
| maccard wrote:
| > But as a practical matter, using Unreal turns every
| decision you make from "what behavior do I want" into
| "what behavior do I want and is it worth fighting Unreal
| on this",
|
| I don't agree with this at all - Unreal gives you
| defaults that can be easily replaced. The decision is "do
| I use what unreal gives me or do I write my own" for most
| systems, compared to "do I write my own or do without" if
| you're starting from scratch.
|
| > so theoretically if you use Unreal your game could be
| any legal C++ program.
|
| That's a bit reductionist, and not really fair. All of
| the "behavioural" parts of the engine are exposed in very
| customisable ways. As an example if you're not happy with
| the collision detection behaviour/triggers, they are
| designed to be modified and changed around. If you're not
| happy with character movement, you provide your own
| character movement definitions.
|
| > (This is especially true on PC, where things like "how
| are the game assets organized on disk" are visible to
| end-users
|
| If your definition of end user experience of a game is
| file layout on disk, then so be it. Knowing that
| something is made with unreal engine doesn't immediately
| turn it into another copycat unreal engine project.
| Besides looking at the disk layout, you could also just
| see the splash screen that you're legally required to use
| when licensing the engine. Also, you have source code to
| the engine, to the automation process, and the pak tools.
| If you want a different layout on disk, go ahead and
| change it.
|
| > Particularly on the 2D hobbyist stuff that I do
|
| If you want to do hobbyist engine development work,
| _that's_ a great reason to write game engines. Not
| "liking" an engine and wanting things done differently
| isn't the same as wanting something that's incompatible
| with a game engine's design and architecture. If you want
| a lock step multiplayer game with rollback then sure,
| you're probably not going to find it. But if you want
| "less floaty" character physics, or a different camera
| perspective, a different startup flow/implemention, you
| can _definitely make that within the bounds of Unity and
| Unreal
|
| > writing my own engine is less work than becoming an
| expert in an engine I don't really like so I can change
| most of it.
|
| You definitely don't _need_ to be an expert in an engine
| to use it, any more than you need to be an expert in
| python to start writing some scripts. Also, how can you
| know how much of the engine you need to throw out before
| you actually know how to use it?
| Agentlien wrote:
| In essence I agree that the big engines very seldom get in
| the way and should be good enough for almost any project.
|
| However, I will say that I've constantly (during 10+ years
| of working full time with various game engines) come across
| cases where I need to extend or modify the engines I work
| with to either fix bugs or add missing features.
|
| To take a fairly recent Unity example I worked on a game
| using the Universal Render Pipeline (URP) and found myself
| having to implement some things I just couldn't understand
| were missing. For instance, URP supports a depth prepass
| for opaque objects but still uses an empty depth buffer on
| opaque rendering instead of utilising the one generated
| during the prepass.
|
| Just binding the already generated one instead allows you
| to get a lot of free depth culling and in my mind is one of
| the main reason to use a depth pass. But in URP it was
| apparently used exclusively to feed depth information to
| shaders.
| maccard wrote:
| > I will say that I've constantly (during 10+ years of
| working full time with various game engines) come across
| cases where I need to extend or modify the engines I work
| with to either fix bugs or add missing features.
|
| Agreed wholeheartedly, and this is part of game
| development. Sometimes that comes in the shape of adding
| features that are straight up unfinished, other times it
| comes in bugfixes/workarounds. I hope my original message
| didn't come across as "there is no work involved in using
| a preexisting engine!"
|
| > To take a fairly recent Unity example I worked on a
| game using the Universal Render Pipeline (URP) <...>
| still uses an empty depth buffer on opaque rendering
| instead of utilising the one generated during the
| prepass.
|
| Presumably implementing that was _far_ less work than
| writing a URP yourself, and that's before you take into
| account the benefit of the art/design pipelines being
| able to use the render pipeline for the X months it would
| take you to write one yourself.
|
| That example doesn't effect the "user experience" of the
| game either (which is what the GP comment claimed they
| wrote their own engines for), but that's not to say it's
| not worth doing!
| Agentlien wrote:
| It was absolutely a tiny amount of effort in comparison
| to developing your own fully featured render pipeline. As
| is anything I've had to do. That is, after all, the point
| of using a commercial engine. It does the heavy lifting,
| I just need to tweak it.
|
| > I hope my original message didn't come across as "there
| is no work involved in using a preexisting engine!"
|
| Absolutely not. I've come across the argument about
| making a game for the end user experience before and it
| always strikes me as a case of not understanding the
| capabilities of your tools. I just wished, more for
| others who come across this than people with our
| experience, to add that some modification of the tools is
| to be expected.
|
| > That example doesn't effect the "user experience" of
| the game either
|
| Let me finish by saying that it's true, unless you count
| your game having stable frame rate on weaker platforms as
| part of the user experience. ;)
| maccard wrote:
| > Let me finish by saying that it's true, unless you
| count your game having stable frame rate on weaker
| platforms as part of the user experience. ;)
|
| While this is true, it's also not a "given" from a custom
| engine and needs to be planned for. It's a big ask for a
| team to reimplement their renderer as a forward renderer,
| but it's a checkbox in UE4 (plus reimplementing all the
| materials etc).
| Agentlien wrote:
| I certainly agree. I'm really not arguing for writing
| your own engine as anything other than an excellent
| learning exercise. I've written my own engines and
| renderers (both forward and deferred) and I'm more than
| happy to rely on whatever engine we happen to be using at
| work to solve most hairy issues for me.
| resonious wrote:
| When I was a kid, I had this messed up idea in my head that if
| I used a game engine then the resulting game wouldn't be one
| that "I built". It's like I built this "Unity game" rather than
| I _built this game_. I don 't really buy into that mindset
| anymore nowadays, but I guess there's something to be said
| about how the tools we use influence the products we produce.
| [deleted]
___________________________________________________________________
(page generated 2022-04-05 23:02 UTC)