I've been doing a lot of programming in Unreal lately, and I agree: It is hard. The docs are shockingly terrible, and 99% of the time I just end up reading the source code of the engine for documentation.
It is also re-igniting my passion for software development and learning.
So far I have:
- Learned a LOT of linear algebra and vector math through "learning by doing" with 3d games
- Learned C++
- Made a bunch of dumb little games during "game jams"
- Built a particle system using Niagara, made it into a component, and attached it to my player character for a movement indicator
- Made a valiant attempt at developing a procedural animated suspension system for a little car. If you have a path for learning how to do this procedural animation stuff, please @ me!!
- Learned how to configure and implement the pathfinding and AI systems for Unreal
- Realized I need to do a bit of a deep dive into shader development, and picked up a book as an introduction to shaders and have been watching tutorials. Fun stuff!!
- Had to think a LOT about architecture for my game.
- Learned basic blender modeling and rigging, rigged a model
I have spent so much time and... I still do not have a functional game. But that is OK. If I was trying to do something simpler, I would have something. But I'm not, i want to learn and build something cool.
Overall I see my gamedev as a "punk rock" kind of thing: I don't do it for the money, I do it because I want to and it fills the time with intellectually stimulating work.
Not sure if that's what you're looking for, but check out Pixar's collection on Khan Academy. It helped me a lot even though it's not extremely deep https://www.khanacademy.org/computing/pixar
Try blueprints. Not because they're easier, but because they expose the engine API and make it so much more discoverable. IMO its a much better way to learn the engine. When I write c++ for unreal or c# for unity, I find I'm much more likely to end up time trying to implement a concept that the engine already handles, in a far superior approach than what I'm doing.
Procedural animation isn't quite there yet, but control rig is slowly improving.
On the other hand if you make blueprints without really knowing the engine you'll quickly end up with a mess of cobbled together poor solutions which sort of work.
Absolutely, but I've seen it happen a lot more in visual scripting languages than in C++. Mainly because it lowers the entry requirements to people who don't understand what they're doing.
That sounds fine for hobby projects but I used to work in a AAA studio where much of the game logic was made this way and a lot of engineering time went into identifying and fixing issues (both functional and performance) caused by designers or TAs working this way without asking help when they needed it.
- Port it to C++ for refactoring and long-term code quality
I was bullish on the node based programming, but over time I've liked it less and less.
I've been a software engineer for 10+ years so I am very comfortable in the IDE and coding workflow.
But yeah, discoverability in blueprints is out of this world. And the C++ classes use the same functions as the blueprint classes. Once you figure out how to find the C++ the blueprint is calling into, it becomes very productive.
> - Made a valiant attempt at developing a procedural animated suspension system for a little car. If you have a path for learning how to do this procedural animation stuff, please @ me!!
> - Realized I need to do a bit of a deep dive into shader development, and picked up a book as an introduction to shaders and have been watching tutorials. Fun stuff!!
Can you point me in the direction of resources for both of these? Or give me your contact information? Would love to chat!
For procedural animation: I have yet to find the path to learning this skill. It is very opaque, and I think you just need to attack it with your brain and learn it.
I spent a good number of years doing similar. Back in day with Blender, Microsoft XNA. I did a bunch of work on shaders, modeling concept art, linear algebra, C# and then had reached demo stage where my main vehicles were interacting in a physics engine I had essentially coding using 3d models with basic art I put together.
At that point I realized I needed marketing, business/legal framework, and more importantly distribution. I didn't even own an XBox, why am I targeting it? I decided to start over with LibGDX with primary platform being Android which was exploding - and the rest is history. Off and on 3-4 years down the drain I suppose.
My advice to anyone considering this is do a minimal indie game compo. Set the bar as low as possible so that you get a feel for all of these important pieces of actually producing a game from start to finish.
I still think my concept is sound, and I have 1 other idea I'd love to work on, but there's no time now that I'm old and with a family. My interests have pivoted back to music which is more quickly gratifying and easier to share. It doesn't help that the gaming community is a toxic user base in my experience.
Finally, what does it even mean to make a game these days. It seems all people care about are in game items, markets to trade them etc. Nothing fun about that for me at all.
There're some skills that are transferable in game programming. Mostly math-related - linear algebra, some basic geometry and trigonometry, algorithms like A*, graph stuff.
I've done a lot of hobby game programming but never worked in gamedev, and the only time I had to use serious math at a job interview was the one time I applied for a gamedev position. It was very refreshing exercising these atrophied math muscles.
EDIT: ok, not THE ONLY time, I remembered a few more, but it's much less common in non-gamedev
This is part of what I like about it. I work mainly with graphics and I use linear algebra, trigonometry, and the like on a daily basis. I need other types of math, mainly calculus, every other month or so.
My work itself is largely focused around performance and trying to get our games to work as well as possible across many different platforms. I also do some new feature development, though that has mainly been focused on implementing efficient replacements for nice but expensive effects. Near releases my focus also shifts when needed to help out with various crashes or other bugs.
Most of my work is spent capturing frames in graphic debuggers, analyzing them to identify issues, then implementing necessary performance improvements. For a fairly representative example you can read this article I wrote about one aspect of my work for Lost in Random: https://agentlien.github.io/fog . It doesn't go very deep into technical details since it was more aimed at people with some technical knowledge curious about game development rather than fellow graphics programmers. As such it doesn't mention the actual performance optimizations brought up during my internal presentation at the company.
As for necessary skills: A lot of it is simply low level programming and knowledge about the target hardware. There's also the specific knowledge of graphics APIs and the languages and tools to work with them. When it comes to math there's a very heavy focus on linear algebra, even more so than in game development overall. Everything is about vertices and transforms applied to them. For modern shaders there's also a fair bit of calculus since everything from BRDFs in physically based rendering to effects such as ambient occlusion are described using integrals.
One more harsh truth: the easier it becomes to make games, the higher the standard of quality needed to be considered "good". Everybody else benefits from improved tools too, and they're your competition.
Exactly, even if you make something novel and win the indie lottery, it's going to be ripped off immediately. Apple and Google are really failing at maintaining any level of quality in their app stores.
It’s pretty much all their fault. The same way the internet is overflowing with ad-riddled blogspam due to Google, the appstores are filled with scammy/exploitative clones because that’s what makes the most money when there’s no competitive forces to drive quality control of any kind.
For example, if the Epic game store became known as a source for good mobile games, customers will stop browsing the App/Play store for games and will instead go to the curated and high quality alternative, because why the hell wouldn’t they.
If Apple and Google are forced to stop suppressing competition on iOS/Android, it may lead to an entirely new mobile gaming industry that’s actually somewhat respectable.
If you make a game which can be cloned quickly, you've made something extremely simple. Don't do that.
Anyway, I would certainly not choose to develop mobile games, seems like a bad idea for many reasons. But look at PC games: you can make something as absolutely weird (and arguably 'unmarketable') as Disco Elysium, which needed no "lottery", it's simply a masterpiece.
I agree, when it comes to larger indie games. But there are still simple games that are worth playing, and certainly don't deserve to have their revenue stolen by content farms. The game referenced in the video above is an example of this. And people forget that 2048 was heavily "inspired" by Threes.
It's a separate discussion, but I believe there's still a "lottery" aspect to indie games. There's a lots of survivorship bias as play there. For every Hollow Knight or Disco Elysium, how many other passion projects run out of funding, or get released and go unnoticed?
There's a huge infrastructure for game discovery - Dedicated subreddits with millions of subscribers, curators, massive infrastructure from companies like Valve (Steam) and Google to help discoverability, forums and discussion groups and Discords and Kickstarter...
People are hunting endlessly for good games. But cannot find them.
Even me! I'm a knowledgeable nerd with time, but I can't find anything worth playing. I know many people in the same situation.
There aren't really unknown gems. Great games don't go unnoticed. Many indie devs just like to think they do because they don't want to accept that their game just isn't very good.
Hollow Knight and Disco Elysium are great examples. These could never have gone unnoticed. These are professional efforts from teams of dedicated, very skilled developers, who did a lot of non-obvious things the right way. Nothing replaces a game like Disco Elysium especially. It was always going to get noticed. (I don't know HK as well but from what I've heard it is also exceptional at what it does.)
I'd be interested if you could name any unnoticed game that approaches either of these two in being compelling to play.
> Exactly, even if you make something novel and win the indie lottery, it's going to be ripped off immediately.
Yep, see any of the 200+ Wordle clones and derivatives out there, only about two months after it went viral.
One of my video games has had at least five clones made that I'm aware of (probably several more than that), and it didn't have anywhere near the same success that a game like Wordle did.
This generalizes interestingly to any tooling that makes things easier. You may feel more efficient with better tooling but it's an arms race and once everyone has access to it you're all competing equally again (and it's back to whoever puts in the biggest product of time and energy).
Hence why you should sell shovels in a gold rush, and why it's a bit of a lie to sell any tool as "be able to do 2x in the same amount of time", since that's only a short term effect until everyone is aware of it and '2x' is the expected new norm.
Maybe if you substituted "AAA" for "good". But the plethora of tools for making games have once again made it possible to make some really good games with comparatively small teams.
I've seen several people online talking about their grandiose plans for making a game better than Grand Theft Auto or something, and my advice to them is to sit down and read aloud the entire ending credits for Grand Theft Auto or whatever game they think they're going to do so much better. Then remember each of those names probably represents at least a year of their time.
Even "indie" games typically take a dedicated team of several people a few years.
If you want to do a game by yourself, you either need a ton of skills or you need to be brutal about cutting the features. For example, a single person can build an interesting ASCII roguelike today. But you're not going to get an AAA look, that's for sure.
Or alternatively, you need to define better in different terms. Something that I feel has stricken the heart of what good is the nature of run as found via Minecraft or Roblox. For anyone that cares about graphics, this was a punch in the face.
Completely agree. However there are a few exceptions to the rule, for example Minecraft was written by one person (Notch) which was successful before he expanded the team and then sold it off to Microsoft.
I mean arguably Minecraft is in the same category of "feature" cutting that the OP is mentioning. It certainly did not feel like it was a AAA game. I started playing Minecraft in Alpha and it sure felt like one person made it.
I don’t think that example contradicts what he said. Notch falls into the “have a lot of skills” category. Minecraft was built with a custom engine, and prior to that he worked on a two-man MMORPG (Wurm Online).
I think the game industry has a lot of extremely talented “10x” developers that are also underpaid and overworked.
That people are willing to put up with the terrible conditions in the game industry is an example of how interesting and fulfilling work is many times more attractive than a good salary and work/life balance. A boring SAAS company will probably never beat a game company with a fraction of the budget when it comes to hiring/retaining the best devs.
That's really hard to answer, because in practice there seems to be "indie" and AAA, and no words in between.
This is a terminology hole that I hope we fill, because I feel like the indie space is definitely rich with games that are certainly not 2022 AAA, but also obviously miles above ASCII Nethack or 2D pixel sprite art (which I like and all, but is not in the same league of difficulty). It feels like there's a lot of stuff in the sort of "pretty good looking for an XBox360/PS3 game" range.
There's definitely tons of ps3 games that look better than any indie games I can think of (mgs4 comes immediately to mind, what a visual feast.) I don't think it's inappropriate to say my game and many other indies are visually competitive with horse racing 2016, a game with a ps4 release.
Hardly AAA competition -- I'm just charting the territory of the bands.
The conversation muddies between talking about rendering features and aesthetic execution. If all we're talking about is rendering capabilities, I'm confident saying this segment here is beyond what a PS3 could do. The fillrate alone! https://twitter.com/LeapJosh/status/1455511983512436737
Regardless, of course it isn't reasonable to outcompete 100+ people teams solo, but we can be scrappy and punch above our weight. :D
Minecraft has already been mentioned elsewhere, but for me the comparison point I would draw people's attention to is Banished. The genre is pretty simple in terms of concepts and the game doesn't break any new ground (just executes on the formula really well). It was developed by an exceptionally talented solo dev with decades of game dev experience who could focus specifically on what he knew his game would need, and it still took north of two years to develop and still needed additional QA help from more contributors to get over the line. For anyone looking to get started on solo or small team game dev they really should temper their expectations.
You will probably have to make a game that is smaller in scope and/or less polished than Banished, or your game will take more than a single technology generation to ship.
Explain Undertale and a bunch of other games then.
Good games are good games. You can always sell a DRM-free executable and it'll have the potential to be considered "good" if it's..fun, memorable, clever, challenging, etc etc etc etc
Wordle alone proves you wrong. The "goodness" of the game is in its core mechanics and ideas, not what most people refer to as high quality (graphics, art assets, etc.).
I've seen a trend in porno games development. Digging around their communities I found their main source of income is crowd funding during the development stage.
They drag this period out for years and some are currently making $100k a month going by patreon statistics.
Maybe the gaming industry needs to change the way funding is managed?
Same here, first games in QBasic (no functions, all goto!) like Skifree. Used phaser.js for a bit. Last project implemented a sidescrolling beat em up in ASCII.
The most important thing i learned was that implementing your game as classes (with inheritance and all that) is futile. Use ECS (Entity-Component-System), its awesome.
Even a simple MVP takes like months or years to develop. During studying how Disney designed animations (the 12 principles, like anticipation, staging..) i realized just how deep you need to go into non-coding things like animations, music, graphics, UI, and more.
Shout out to the r/roguelikedev community though, they are awesome. People coding on their rougelikes for 12 years seems to be not extraordinary.
Sure: https://github.com/dobin/nkeyrollover. You can play it with "telnet exploit.courses". It will crash a lot. Stole some animations from "Stone Story" (Steam)
Thanks. Still, abandoned it like the author mentioned after nearly getting the MVP to work. All which is left to do is fixing all the bugs, implementing all the skills, animations, enemies and bosses with choreographed attacks, and designing a lot of maps, add a story... (at least there is no music or sound effects).
And of course, what often gets forgotten: Make sure it is fun, somehow. In my opinion, nobody can "make" a good game. Can just pump out a lot of games, and hope one is good. Be it EA, or King Digital Entertainment.
This is great! Thanks for sharing. I'm going to share it with some friends.
I once had a goal of working on a beat 'em up engine for fun. I wrote one version on Mac and then later thought to write it in javascript. Like many other projects I've done, I got it to a working state and moved on. :) Take a look here if you're curious: https://www.ussherpress.com/yokosukajs/
It's not "true" game development, i.e. using modern 3d engines, but it did cover the core issues to think about, and I was learning to write more fp-like code at the time, so it helped me learn functional programming a bit.
So, to echo other people's comments, there are transferable skills in game dev.
Except that changing direction quickly left/right feels kinda bad. Seems you wait for the animation to finish before checking for new key presses, not buffering the last pressed key.
Yup, good callout. There's definitely tweaks I could make to get a better "feel".
For some background, I have a state machine for the animations and I've set up some to be interruptible starting on certain animations, and in this case, I the "turn around" animation has to play out completely before I allow new directions from the "director". (I call the characters on the screen "actors" and the source of directions "directors", which can be a human or AI.) Anyway, the fun was in coming up with the engine, of course. :)
Seconded. Coding a roguelike in C and the amount of flexibility it gives even with no help from the language itself is crazy. It's really amazing how many concepts that were really hard to abstract become easy. Want a rock to move around and cast fireball? Give it the Actor and Spellcaster components. Do it dynamically at runtime. Now you can make a spell that makes rocks into wizards (.. if only, dynamic effects are more complicated than that, but it's a good showcase of the possibilities)
Could you possibly post a pseudo-code example of how the above would work with ECS? How do you attach the components to the rock object if not inheritance? Would you just have them be functions that you call to include within the rock via a header file or something? Or a separate code module you import, if using Python?
Basically, entities consist of components. Components should ideally just be data (a struct). Systems work on components (data), they are the code / functions. A system only cares about it's component (but for all entities, which have this component).
A entity "player" consists of the components like "texture", "input". A "monster" entity has components "texture", and "ai". The graphic processing done by the texture system doesnt care how the changes in x/y position is happening (via AI statemachine, or keyboard input).
Player and Monster should shoot too, so attach a "weapon" component to it. But then it's also possible to also create an entity with components "texture:door" and "portal" (portal system will teleport you to something, e.g. next level). No one stops you to attach the "ai" component too, making the door move around. And "weapon", which makes the door shoot too (then maybe call the entity something else, like portaling-monster).
As the components are just data stored outside your code, e.g. in files or a DB, you can change them at will. And load it, without recompiling or even restarting your game! This allows a large amount of creativity and innovation, without refactoring your code all the time.
I like to connect my systems with a message bus, where they send messages to each other. Messages change components, data, of entities. These may generate more messages. E.g. player clicking left mouse button creates a message, which gets handled by input system. This creates a message for the weapon system, reducing ammo count by one, and change its texture (-index) to like "shootingstance:1", and creating a new entity "bullet" with the source x/y and destination angle.
Sure, I'll give a simple example. Things can be done differently and must be more complex sometimes depending on the requirements, but it all basically boils down to this. So, ECS - Entity Component System.
The entity itself can be literally just an int id. To make a new entity, request a new id. Since everything about an entity is contained in what components it has, you don't need more information.
Components: they're just data. You can model them as structs:
struct c_actor {
int entity_id;
// action to execute once enough energy is accrued
struct action *action;
// Angband style energy level, to take a turn must be >=100 (ACTOR_ENERGY_TO_ACT)
int energy;
// amount of energy gained per game tick
int energy_gain_per_tick;
};
I hope the comments explain. This is all the component is, data. You can have a helper function which stores it in some data structure where you keep each entity's components, indexed by id.
Systems. They're just function which operate on entities which have their component.
int s_actor_do_acts(struct component_systems *c_systems)
{
// loop through your tracked entities
for (for (int i = 0; i < ACTOR_ENTITIES_NUM; i++) {
...
int *energy = &c_systems->actors[entity_id].energy;
if ((*energy) < ACTOR_ENERGY_TO_ACT) {
goto add_energy;
}
(*energy) -= ACTOR_ENERGY_TO_ACT;
...
// actually do action
if (c_actor.action != NULL) {
switch(c_actor.action->action_type) {
case ACTION_WALK:
action_walk_do((struct a_walk*)c_actor.action, &c_systems->positions[entity_id], c_systems->lmap);
break;
...
You call the system function in the main game loop.
Note: something a bit "unorthodox" here is the fact that the Actor system here also directly gets a handle on the position component. Others prefer event systems, where instead you would fire off an event. My RL is single-threaded (I can definitely wring enough CPU perfomance without needing to overcomplicate), so I've opted to just pass handles around and have each system call each other directly via passing handles. In this example, the Walk action would call into the position system's function via the handle passed. This greatly simplifies code, and allows me to do partial updates of the game state outside the main loop.
edit: Also, in case you're wondering how the data about what each entity is stored (since that seemed to be the crux of your questions). You can have a data file:
... many other components ..
[components.actor]
energy_gain_per_tick = 20
[components.fov]
radius = 10
...
Then you read this in and dynamically build an entity:
toml_table_t *actor = toml_table_in(comp, "actor");
if (actor) {
toml_datum_t energy_gain_per_tick = toml_int_in(actor, "energy_gain_per_tick");
if (!energy_gain_per_tick.ok) {
UNT_ERROR("energy_gain_per_tick not defined for actor");
return -1;
}
struct c_actor c_actor = {
.entity_id = entity_id,
.energy = 0,
.energy_gain_per_tick = energy_gain_per_tick.u.i,
.action = NULL
};
c_actor_add(c_systems, c_actor);
s_actor_track_entity(entity_id);
}
I hope the real code is readable enough to serve as pseudo code alternative.
One advantage is you can generate semi-randomized entities, and dynamically change their components at runtime. You can't do that with OOP.
The nice thing about using an event system is that you can just record all events. This allows you to record gameplay directly. This can be used as a demo, scripted scenes, and especially for debugging! Encountering a bug during playing? The recording can be used to reproduce the bug, as it will be a "pixel perfect" playback. Code until it is gone. Debugging is suddenly way easier, as you can just check the events wireshark/tcpdump style, and see what went wrong.
Even more, in networked games it can be used to roll-back actions you did (e.g. because someone with a 100ms ping shot you 50ms before launching a rocket, to roll-back rocket-launching animation). Or in the simulations of the behaviour of the other players (peeking around the wall).
Yep, I wasn't attacking event systems, they definitely allow a lot of cool behaviour. My approach was chosen since it was simpler, and for a solo project where I will have to dedicate months/years anyway, I choose to cut on non essential stuff that I might never use. I'd rather have something playable in a couple months to be able to prototype more, I can figure out what I need to add after.
ECS is sort of an in-memory database. The rock is not a class in the code: it's just an entity in the game that has X, Y and Z components "attached" to it, dynamically. Components are just structs. And finally Systems are just functions that runs once-per-frame doing something on entities that have a certain components on them. Normally, entities/components are serialised into some format so it's not static in the code.
The advantage of this is that this requires less code, permits very good separation of concerns and is very transferrable even between engines. Unity, for example, uses something similar where components and systems are in the same class together. For self-coded games, there's several libraries too.
If your goal is to make a game in a reasonable amount of time, I kind of disagree with this advice. Implementing an ECS system before anything else is a good way to find yourself spending time yak-shaving instead of actually building your game, and for most 2d games, YAGNI (at least not right away).
My personal advice would be program some of the major game systems and objects you want for your game first, they'll probably take you longer than expected but at least you'll have something that actually resembles game play and not just a framework for building a game. If you get to the point where you need ECS for performance or organizational reasons you'll probably have a good idea of how you want it to work by then instead of guessing at how you'll use it.
Agreed. Also for some smaller games the core gameplay itself is the easy part. The rest of it (menus, sound/music, levels, animations, game options, networking, localization, input flexibility, resolution/video settings, shaders, cross-platform support, achievements, leaderboards, statistics, a.i., etc.) is what can take forever.
For example, I've got game with a core game loop that's been finished for probably a year now, but I've still got a ways to go with everything else before I'm finished with the rest of it.
A tangential thing that I've found: I also started programming by doing games. Also did a "pong" clone in Basic, a "reverse" UFO game in BASIC as well (you controlled the ship and had to avoid getting shot, get to the bottom of the screen and "rescue" persons [white dots]). I also did some more sophisticated games in C using Allegro. And a bit later I experimented with Direct3D and OpenGL under Windows. I loved making games.
Fast forward 25 years later, I have installed Unity, Unreal and some other OpenSource game development environments, and I just cannot find heads or tails. I've followed some Udemy courses, but for me, the current "game development" process feels more of a "graphic designer" process than a programming process. I would love to make games, but it seems that the current "tools" are more tailored to artists type rather than programmer types.
Unity uses some kind of ECS, see other discussion.
And there is a bit of a difference between game, and game engine. Unity is really for creating games itself, where most part is not engine work. Like most developers, we like to do engine work though, not graphics.
If you want some fun, find a lower-level engine which just implements some parts (e.g. while Phaser.js is a big game engine, still need to do a lot of coding by hand). Alternatively, use weird things. ASCII, HTML Checkboxes, voxel graphics, svg, in rust...
I don't know about that. Yes, if you are only learning frameworks then sure. If you are digging deeper and understanding, GPU programming, math, performance optimization, architecture, physics modeling, network programming, all of those are very transferable skills.
I think that some of the problems boil down to the language used. Game engines tend to rely heavily some Editor (be it Unity, Unreal or Godot).
I'm hoping that Rust will solve some of this by having you use a pleasant language instead of relying on GUI tools.
I legit think that it would make sense for high schools to structure their curricula around game making. You will learn math, physics, writing, art, music, programming etc etc. And you will have fun doing it.
> I'm hoping that Rust will solve some of this by having you use a pleasant language instead of relying on GUI tools.
it takes years to make games
and you think a language that have horrible compile speed can succeed?
look at the market today, nobody wants to use C++ anymore to make games
people moved to unity because it is fast to iterate
unreal? people use blueprints for everything nowadays BECAUSE c++ is a pain and slow to compile, it hurts iteration time
rust/c++ are anti fast iteration, it's anti-gamedev
the people who push rust in gamedev are clueless and they deserve the language, best way to make people hate the language even more
look, 5minutes to compile a single line of code in Rust in this game made fully in Rust, what's the advantage? the biggest advantage is these devs will be able to think about doing something else, because they'll never be able to release a game within the next 10 years at this rate
Regarding the OPs comments on the non-transferability of learning Godot and Unity to marketable jobs skills as compared to learning about AWS, GCP etc. in your spare time - I somewhat agree with this. A potential way to make learning game programming potentially more useful on the job/marketable is when you get into the multiplayer gaming aspects of game development.
There's a ton of realtime networking concepts (web sockets for realtime chat, etc.) as well as potential investigations into cloud management and realtime databases for multiplayer game state/sync etc. that could be useful during a technical interview.
It might even be that multiplayer games are probably on the leading edge of the application of some of this technology and would give you a leg up compared to other candidates.
There's also the potential you could end up with a more social game that broadens the potential audience for the game in terms of players and code contributors.
Bah. A scene tree is a scene tree. A collision callback is a collision callback. My knowledge of ogre 3d transferred almost directly to other more modern engines, minus the API.
If you think of the game world as a representation of its internal state, all games are similar. Editor's are only easier way to build the initial scene tree. Shaders are just a coat of paint on top, etc.
There's nothing fundamentally different between the unity editor, the Eden editor and the build editor.
Nobody who is capable of finishing a game alone thinks it's easy. How could it be? The programming touches on so many highly complex areas, you need both
visual art and music, on top of having to engage with what's going to be a completely new area for most: game design. From the perspective of a developer, not a player. If you're doing 3D, say hello to even more advanced programming topics, plus an entire world of 3D art techniques.
You don't do it because it's easy, you do it because you enjoy the journey. If you actually want to produce a video game for commercial reasons in a reasonable time frame, hire a team or partner with like-minded people. Cut your scope in half, or more.
I'm trying to learn unity and game development as well.
My day job is salesforce integrations, and wow I'm finding game development mindbogglingly hard.
I thought it would a cute fun thing to with my kids since they love minecraft but . . . I'm not finding tutorials or books that work for me.
Tons of documentation, tutorials, books are out of date, and I find the unity official tutorials not that great, they seem to be focused on super specialized tracks.
Anyone have any good tutorials, books, videos they'd recommend ?
I'd really like something concise and focused on 3d game development in unity without too much frills just to get handle on the basics.
One thing that can help is to step back and do some very very basic game programming from scratch first. Make a simple 2d game like pong first. This will give you some basic understanding of how to draw pixels on the screen, how to collect input, how to track game states and do a game loop. Once these basic ideas are better understood, you can hop into a game engine and have some context for what the heck is going on. It will make more sense.
Get familiar with the fundamentals before hopping into a huge game engine. Also avoid 3d for a while, the introduces so many complications and its hard enough just making a 2d game. A simpler game framework that unity can be used as well, like MonoGame, or Godot, or one of the Python game frameworks.
I've had to kinda bootstrap myself into this process as our company decided they wanted to try their hand at making a game and have me help with the process.
The books, tutorials, and videos out there are okay. They will more often than not get things working. But the problem is they don't really go beyond that. They kinda assume you're a solo game dev working on a solo indie project and that's that.
To go to the next step requires a mix of game dev knowledge (I've obtained a bit over the years), lots of software design sensibilities (to recognize when something doesn't feel right), and lots of digging on the internet (to try to find out how professionals are solving the problem you just ran across).
> I'm trying to learn unity and game development as well. My day job is salesforce integrations, and wow I'm finding game development mindbogglingly hard.
What are you finding difficult? It's hard to make recommendations without a good idea of where you're stuck.
My general advice, however, would be to just make things. Figure out a mechanic you want to implement, find any resource that describes how to implement it, implement that mechanic, and then move to the next thing.
It's much more valuable to just build things and figure out how the systems interact as you go than it is to try and get a bunch of theory out of the gate, especially if you're not building your own engine.
It seems like there are a lot of ways to do things which seems overwhelming to a new user.
Everyone has different opinions on how to approach things in the books, videos, and tutorials I've gone through.
For example some people like to code custom components heavily in c# including animation transitions, but others highly recommend not doing that.
Also many tutorials and examples are too toyish and are missing practical concerns like cross controller compatibility, and other real world concerns. I've got some very simple 3d games working, but I'm missing how to take them further feature wise and make them closer to "real games".
I'd really like a resource that's very opinionated and pragmatic for independent game development.
> Also many tutorials and examples are too toyish and are missing practical concerns like cross controller compatibility, and other real world concerns.
Don't worry about "real world concerns" until you have stuff that works at all. You're not building a winning product on your first try.
> I'd really like a resource that's very opinionated and pragmatic for independent game development.
Sounds like you're finding a lot of very opinionated resources. :)
However, there is no one "pragmatic" resource in game development. The pragmatic solutions are scattered about. Not to mention that, as you are already aware, there are lots of ways to do things. You just have to pick one and run with it.
Just to clarify, I have stuff that works, but not in a rigorous software engineering kinda of way.
Yes, I'm finding lots of opinionated resources, but not informed opinions from experienced game developers/software engineers. Instead I'm getting lots of non expert, new to game dev, or new to programming opinions.
When I follow them, I immediately run into an issue, that requires extremely in-depth thinking and usually a different architecture. It all just feels half-baked.
Though I suspect I'm heavily spoiled by the fantastic salesforce learning ecosystem.
Yeah, that's the thing - the people who do have the experience largely either don't share (heavily introverted/low social presence overall, takes too much time to write blog posts, open source various efforts with poor documentation) or can't share (proprietary knowledge). Most of what you're going to find is low quality. The reality is that, if they're not career programmers who have spent x amount of years at a AAA developer, the code is probably bad. Even if they have, there's a chance that the code is bad. Most of what you're going to find is definitely of the "if it works, we're done" variety (part of this has to do with the time and effort that it takes to make games in general).
If you want "rigorous software engineering," you really have to look at formerly commercial (or even still commercial) games that have been open-sourced and try and figure things out from there. Good learning materials are just hard to find. That's why I said just build stuff. You build it, you apply whatever optimizations to the structure or code itself, and you learn good practices through experience.
Try doing something SUPER simple in Roblox. Really. Don’t get out off by the fact that all the YouTube tutorials for Roblox programming are made by 13-year-olds! It’s a good start. Then go back to Unity if you feel like you’re running into Roblox’s limits.
I've been making games for most of my life and I've been working full time with game development for a good while* and I disagree about skills not being transferable between engines. I feel once you move past a beginner stage you can focus on the similarities and quite quickly learn and look past their idiosyncrasies.
I feel it's very similar to learning new languages. Once you understand the common principles and low level details you can very quickly learn and become quite efficient with a new one.
* 7 years in the game industry proper, 4 years in surgical simulation
Regarding skills not being transferable. This is only somewhat true and the author is doing some goal post shifting here. What he said really only applies to game engines, not game frameworks and certainly not game programming in general. If you want to learn game programming and not a game engine, I recommend using something like Pygame or LOVE2D which are less prescriptive game frameworks as opposed to engines.
However, even with game engines, I have spoken with AAA developers who have worked with both Unity and Unreal and they all say the same thing. Game engines are a lot like programming languages in the sense that once you learn truly learn how one works, picking up a new one isn't that difficult.
> Game engines are a lot like programming languages in the sense that once you learn truly learn how one works, picking up a new one isn't that difficult.
As someone who has worked as a AAA game dev for almost 13 years, can confirm this analogy holds true. Off the top of my head, I can recall 8 different game engines I've worked on (all proprietary). You start to pick up on the common patterns and ideas between them, and learning a new one boils down to figuring out familiar interfaces. Just like when learning a programming language, you look for the fundamentals (loops, conditions, data types, etc).
At the end of the day, "game engine" is a fancy way of describing an amalgamation of systems that gather input, maintain a complex state machine/simulation, and draw it on a screen. And from my experience, the way different engines accomplish this doesn't truly vary that much.
The studio I'm at has hopped around a bunch, so I've gotten to do work for a range of franchises over the years. Guitar Hero/Band Hero, Call of Duty, Skylanders, Crash Bandicoot, Destiny 2, and most recently Diablo II Resurrected. And also quite a few different platforms (Nintendo DS/Wii/Switch, PS3/4/5/Vita, XB360/1/SX, Apple TV and iOS).
I've mainly done engine and tools work, often for UI or scripting systems. From my experience, each studio and franchise tends to make its own custom engine and tools. Although, in some cases we managed to reuse a decent amount of in-house technology across projects. The Tony Hawk remaster was an unusual case which used Unreal Engine instead.
It's given me an interesting perspective behind the scenes of AAA games. These titles may all use different software but they're fundamentally built on the same principles. Once you get the gist of how games like this are put together, learning another isn't a big stretch.
I would argue the opposite, there's a really strong skill transfer between gamedev(esp on the engine side of things) <-> embedded development. Both deal with hard constraints(performance, memory, storage) and you use similar approaches to deal with them.
At a more high-level HMI/game design has a pretty large overlap. No one knows what "fun" or "easy to use" are, so the approaches to converge there are similar(rapid prototyping, etc).
Yeah I spent a little over four years in the game industry and successfully transferred to enterprise and web development (while still doing some games on the side). I'd say there's quite a bit of overlap depending on the tools or languages you use.
And yeah, I've switched between many game engines over the years myself. Unity, Love2D, Flash Actionscript, Pico-8, XNA, Cocos2D, QBasic, TI-BASIC (texas instruments calculators), Hypercard, PyGame, Popcap Game Framework (C++), straight up OpenGL, J2ME, Kindle Active Content (basically Java), PhaserJS, and Swift + SpriteKit. It's about as transferable as going from Angular to React (which I did when I switched jobs six months ago). Yeah you have to learn how to do some things differently but you can pick up the new one pretty quickly if you've had experience with the other.
I do have a lot of unfinished projects, but that's also true for me for websites, apps, writing, puzzles, and board game designs as well. It's not specific to video games. Also most of them are unfinished because I got distracted by other projects or decided to go a different direction, not because game dev is hard (although it can be). I do have about 20 video games I worked on that were released into the world at one point, also.
I want to make games, but even some years ago I realized it was not a great path for a multitude of reason (many of which are in this article).
My path, and what I recommend, is do something hard and important which pays the bills at a premium. I did infrastructure work, and I was lucky to have a great decade long career allowing me to "retire early".
Now, I can work on a game at my pace building the tools that I see fit. I'm focused on board games because they have a timeless quality about them. I'm developing an entire SaaS platform and programming language to make the network goo beyond easy. http://www.adama-lang.org/
As I'm getting close to some kind of launch for the SaaS, my next thing is to build up my own web based IDE with a release-often ideology such that I can build a Roblox for online 2D board games. Honestly, I'm having a blast because I'm not suffering tools which are going to fade.
I'm pretty much in the same boat as you. Would love to become some kind of indie game developer after leaving FAANG, but no interest in getting worked to death at a big studio. For my understanding, what level of net worth did you reach before pulling the trigger on early retirement? I can't imagine that the indie game dev route can generate income comparable to big tech, except in very rare cases.
The level is different for everyone, but a really simple model is to spend no more than 4% of your investments every year, so it depends on how much you spend. https://old.reddit.com/r/financialindependence/ is a reddit community that goes in depth about this
I don't imagine I'll ever make as much as I made within big tech, but I use the 2.5% rule (instead of the 4% rule), and I moved back to the Midwest where things are much cheaper.
Games programming is rather difficult, yes. Especially 3D games. But also, it's easier than ever. I would have loved to make 3D games as a kid, but my lack of art skills made it impossible. Now with the Unity Asset Store, suddenly a simple programmer like myself can make some really good-looking 3D stuff.
I've been working on a Metroid Prime clone in my spare time just for fun in Unity. And yes, what the author says is true - it's really freaking hard to get all the details right. Even something like weapon bobbing when you move takes some thought. But it's really rewarding and fun, and I am basically making my dream game. I don't expect to ever release anything, but I'm enjoying the ride.
Also, anybody ever write DarkBASIC as a kid? This was the first programming language I ever learned, because I wanted to make games. It was a great intro to programming.
For whatever reason, I’ve been helping people solve problems with their games for something close to 20 years. I have a particular memory from 2004, where somebody sent me the source code to their game and I fixed the 3D transformation code in it and explained what was going on. It was a bit more cumbersome without GitHub, Pastebin, or Stack Overflow.
Over that course you see a lot of people come into the community, have all sorts of beautiful visions and grand ideas, run face-first into the harsh reality that they are ill-equipped to realize their dream, work on arcane technical aspects of their code with the dubious goal of developing some kind of interesting skill, and eventually burn out.
The thing is—I agree with the first point that “most developers will never finish their game” but I think the wrong lessons are being taken here.
If you try to understand the problem, there multiple contributing factors which explain why amateur developers fail to make games, and once you start to understand these factors, you can nudge people in the right direction or at least give them a map of the territory.
- Cause: The gap between skills and vision is large. Mitigation: Reduce game scope, study relevant skills, work with teammates.
- Cause: The gap between skills and vision is unknown. Mitigation: Complete small projects to get a better idea of what skills you have and a better ability to estimate the size of projects.
- Cause: The developer never finishes any projects. Mitigation: Game jams and short deadlines.
- Cause: Projects fail to attrition—the developer’s interest wanes over time, and the project gets less fun over time. Mitigation: Shorter timelines, smaller projects.
- Cause: Poor technology choices. Mitigation: Use mainstream / popular technology such as Unity, Unreal, Godot, etc, and give yourself a limited number of passes to pick a weird technology.
- Cause: Deep, unexpected technical problems with the game. Mitigation: Start by making games that are more similar to existing games made by teams with similar resources and experience levels, until you have more expertise.
- Cause: The game looks terrible. Mitigation: Work on a team with an artist. Or dedicate time to studying art, and find an art style that you are comfortable with that does not require too much effort.
- Cause: Can’t figure out how to solve basic programming problems without a tutorial. Mitigation: Work on a team with a programmer. Or dedicate time to studying programming.
- Cause: Design choices unexpectedly cause high workload. Mitigation: Make prototypes to test critical design choices.
- Cause: Iteration time is too long. Mitigation: Use technology that supports faster iteration times.
This stuff seems obvious and yet there are so many obvious things that typically go wrong in a failed project. “I never considered working with teammates” is common enough. “I don’t want to give up my idea of an action RPG with Metroidvania platforming segments and a massive branching storyline” is a common enough type of problem. These problems can be solved much more easily when people working on games spend time in contact with people who have the experience—professional game developers or successful amateurs are one obvious choice, but school is another good choice. You can make the same mistakes over and over again, it helps to have other people around to point it out for you.
> I myself have abandoned 2 dozen games, in platforms ranging from PhaserJs to Unity to Godot.
This is, frankly, a bit worrying. It reminds me of Schopenhauer’s take on will, how he calls will “blind incessant impulse without knowledge”. We feel the strong urge to make games, but these incessant impulses must somehow be tempered and refined if they are going to achieve anything.
These are great points, many of which would apply to indie software development or side projects too. Your point on Iteration time (and tangentially scope, workload and never finishing) do you think agile practices can help?
I'm thinking of the concept of focusing on a vertical slice, not a minimum viable product (MVP) or any particular capital "A" Agile framework. In a CRUD webapp this concept could be a user login, on its own it doesn't do much but its a functional part of the app - vertical slice in the sense that it cuts across all parts of the tech stack - UI, app server, and database.
In game development maybe this could be something that focuses on building something functioning that involves artwork, music/sounds, animation and data (state of some kind). For example, a fully working character model that can jump, shoot, collect objects, whatever.
The three things I see in game development are prototypes, vertical slices, and MVPs. All exist to get quick feedback on something. Prototypes let you test out some particular gameplay mechanic or a bit of core gameplay to see if your designs are viable (or you could prototype something else, like graphics, of course). Vertical slices are a small but complete section of the game with polished assets and everything works, but it might be very short, and these exist to help you get funding or make publishing deals for the complete game. MVPs are there to test out the market.
As an amateur, I think prototypes are just the bee’s knees. They can be as ugly or as unpolished as you like, and you can just print debugging information straight to the screen. Even if they don’t turn into real games they’re often valuable, because prototype #10 might refine various ideas from prototypes #2, #4, and #7, and turn into a viable game.
I'll say that I haven't taken a game beyond a game jam myself yet, much, but I have done that 8 times now, and when I think about the Grenade example OP gave, I believe myself competent to pull it off either in a M-F week of side-project time, or inside of a weekend of the same, depending on assets of course.
Godot does take a little bit to learn, but it is quite rewarding.
There are a number of larger side projects, game and no, that I've either completed or abandoned over the years, and, like you said, scoping down has been a primary way to help actually get them done.
But, I've also just now found a time slot to work on something consistently in, which has made a big difference.
Many folks don't account for how much "project management" is a key skill in efforts like this.
I'm surprised people praise the unity asset store so much. It seems very unlikely that I would ever be satisfied using a significant portion of it. Not because its low quality but its often very specific in style or content or whatever. I could never adapt my (shitty) artistic vision to adapt to what I happen to find on the store.
There's a book about quitting smoking that spends the first 99% of the book providing the proof that smoking kills. The last page is how to quit smoking: "Never put another cigarette in your mouth and light it."
Here's my book on how to make a video game: "start writing a game and don't work on anything else until it's finished."
I started writing a game in college, and despite having tons of cool ideas, I didn't work on anything else until it was published. It got me a good couple of decades in the industry.
>It's easy to lose heart and just quit.
Not if you love it.
>There is no treasure at the end of this rainbow: You can spend years with nothing to show for it
Do you mean money? Sounds like you mean money. Because a great game is a great game. My game made me less than $1000. Which was a bummer, sure. But there's reviews of it on youtube. People enjoyed it. I am happy, and I had a great time building it.
If this is a means to an end, sure, quit. You simply can't compete against someone who is as good as you but who also loves what they do.
>Sure you can outsource or buy art
Or you can make a friend! I met a guy who had mad art skills, and could create awesome tracker music.
Celeste [1] is one of my favorite games. My favorite indie game. I suck at it but my kid as completed it. It is insane hard, massively rewarding, and the story is moving. IIRC these folks got a house together. Make friends!
It seems like the barrier to release a game and actually have people play it is so damn high.
But before Apple effectively killed it, the Flash ecosystem was beautiful. The games were simple, came out fast, and fun! You could have a proof of concept with less than an hour of gameplay, get it published on Armor Games or Kongregate, and have people gush on it and give feedback.
is there a YCombinator for game development? Seems like a decent idea, give enough money for teams to have some runway to work on it full time in return for equity. The investor could also have a few full time people to help out with skills that the average game dev doesn't have. Eventually the network becomes the most valuable part and a flywheel effect is created
closest thing I can find seems to be Unreal offering grants
Pitches are pretty worthless. Ability to execute is what matters. It’s not like business where you can easily identify a novel need to solve and the value is self evident.
Indie devs are particularly susceptible to imagining their game is fun, and attributing that to the fact that their idea must be a good one. This is triply terrible when the plan is to make a game that is big and has tons of story.
Godot has me so excited. Finally a good open source python(like) engine with all the bells and whistles.
I have only done the tutorials for godot. Not even trying to start my own project. The real caveat for me on video game programming. The programming isn't the problem. It has everything to do with 3d modeling, texturing, etc.
I kind of dream about starting my own video game project up using godot, stream on twitch/youtube making it so I could get some revenue going. Kind of what star citizen wanted to be, starfield will likely be, with my own take. Kind of a skyrim meets han solo meets the martian meets chess meets piano meets metasploit.
But I really hold back because family to feed, diapers to buy, mortgage to pay. Boring game dev streaming like that won't be paying those bills.
My big feature I would be supporting 100000% is BCI. Being able to play without keyboard/mouse/pad just your brain.
The game wouldn't be super serious. Kind of TF2 style where it's more casual. Robot's would pick between 'binary and non-binary' for their gender lol, tongue in cheek joking obviously.
I think there would be a factor of trying to build teams as well. Han Solo isn't Han Solo without Chewbacca. So obviously at least co-op to start.
But alas, as I said. On hold until a million $ lands in my backyard.
Just get a cheap/free 3d asset pack from itch.io and go nuts. It helps to know some concepts about 3d like UVs, normal/AO/specular etc maps, triplanar mapping, vertex colouring etc. but other than learning a bunch of new words it's not that difficult. But making 3d assets yourself is super time consuming.
There's also a lot you can do with 2d pixel art assets in 3d if you like a retro style. Godot has (Animated)Sprite3D which makes it very easy.
Though it may be fun, setting up a whole streaming platform and engaging an audience is a whole shitload of extra work on top of the actual gamedev, so if you have limited time best to really truly treat it as a hobby and squeeze in an hour or two on certain evenings or something.
>Just get a cheap/free 3d asset pack from itch.io and go nuts. It helps to know some concepts about 3d like UVs, normal/AO/specular etc maps, triplanar mapping, vertex colouring etc. but other than learning a bunch of new words it's not that difficult. But making 3d assets yourself is super time consuming.
Oh for sure. I've been 3d modeling for years. I'm big into cad and 3d printing, I used to know blender decently until they moved everything on me in a recently big release. Really should have taught myself shortcuts lol.
>Though it may be fun, setting up a whole streaming platform and engaging an audience is a whole shitload of extra work on top of the actual gamedev, so if you have limited time best to really truly treat it as a hobby and squeeze in an hour or two on certain evenings or something.
Gotta pay the bills. Without those options, where does one make enough money?
I disagree slightly on the transferable skills. I've been in the video game creation hobby for 1+ years now. Embarrassingly, programming for video games is helping me break down problems and invent mental models & solutions to solve those problems. This has helped immensely I'm my ability to think more abstractly, and how to push libraries away from the 'core' domain of my solution space.
I relate to this a lot, having also started and then not finished a lot of games like the author.
Perhaps it seems obvious to say, but I have only recently fully internalized that making games is not the same activity as playing games, and that it will take many orders of magnitude more time to polish even one gameplay feature compared to how long it will take for that gameplay feature to become stale _to me_ as the dev playtesting that feature over and over again.
I wonder if a lot of gamedevs just get tired of playing their own game and thus don't care about it anymore as a result?
Seth Godin has a book called The Dip about the slog in the middle that many creative projects have (business starting as well). I wonder if gamedev has a particularly nasty dip and that is why so few finish.
I usually take the Friday + Monday off of Ludum Dare, and I block out the entire weekend for the event. Turns out, making space for gamedev makes me make games.
> I wonder if a lot of gamedevs just get tired of playing their own game and thus don't care about it anymore as a result?
FWIW, if you work on large enough projects, you probably aren't playing the game that much at all unless you're a gameplay programmer (and even then, you might only play the small fraction of the game that your feature touches). I do graphics/engine programming for games and the closest I get to playing the game is "load into level, teleport to position X, use a cheat code to give me item Y, use Y, see rendering bug"
I've joked on some projects that I'm excited for the game to ship so I can learn how to play.
195 comments
[ 5.3 ms ] story [ 221 ms ] threadIt is also re-igniting my passion for software development and learning.
So far I have:
- Learned a LOT of linear algebra and vector math through "learning by doing" with 3d games
- Learned C++
- Made a bunch of dumb little games during "game jams"
- Built a particle system using Niagara, made it into a component, and attached it to my player character for a movement indicator
- Made a valiant attempt at developing a procedural animated suspension system for a little car. If you have a path for learning how to do this procedural animation stuff, please @ me!!
- Learned how to configure and implement the pathfinding and AI systems for Unreal
- Realized I need to do a bit of a deep dive into shader development, and picked up a book as an introduction to shaders and have been watching tutorials. Fun stuff!!
- Had to think a LOT about architecture for my game.
- Learned basic blender modeling and rigging, rigged a model
I have spent so much time and... I still do not have a functional game. But that is OK. If I was trying to do something simpler, I would have something. But I'm not, i want to learn and build something cool.
Overall I see my gamedev as a "punk rock" kind of thing: I don't do it for the money, I do it because I want to and it fills the time with intellectually stimulating work.
Procedural animation isn't quite there yet, but control rig is slowly improving.
- Build it in blueprints for rapid iteration
- Port it to C++ for refactoring and long-term code quality
I was bullish on the node based programming, but over time I've liked it less and less.
I've been a software engineer for 10+ years so I am very comfortable in the IDE and coding workflow.
But yeah, discoverability in blueprints is out of this world. And the C++ classes use the same functions as the blueprint classes. Once you figure out how to find the C++ the blueprint is calling into, it becomes very productive.
> - Realized I need to do a bit of a deep dive into shader development, and picked up a book as an introduction to shaders and have been watching tutorials. Fun stuff!!
Can you point me in the direction of resources for both of these? Or give me your contact information? Would love to chat!
For shader and graphics programming: I liked this tutorial series as a "first steps" by Freya Holmér: https://www.youtube.com/watch?v=kfM-yu0iQBk
Here is another list: https://www.alanzucconi.com/2018/01/03/learning-shaders/
The Book of Shaders is a popular suggestion, but it appears to be abandoned: https://thebookofshaders.com/
For general Unreal? Tom Looman's $300 Unreal C++ class, available on his website. It is pricey but really excellent.
I also discovered this AWESOME list of learning paths for all gamedev concepts: https://github.com/miloyip/game-programmer
At that point I realized I needed marketing, business/legal framework, and more importantly distribution. I didn't even own an XBox, why am I targeting it? I decided to start over with LibGDX with primary platform being Android which was exploding - and the rest is history. Off and on 3-4 years down the drain I suppose.
My advice to anyone considering this is do a minimal indie game compo. Set the bar as low as possible so that you get a feel for all of these important pieces of actually producing a game from start to finish.
I still think my concept is sound, and I have 1 other idea I'd love to work on, but there's no time now that I'm old and with a family. My interests have pivoted back to music which is more quickly gratifying and easier to share. It doesn't help that the gaming community is a toxic user base in my experience.
Finally, what does it even mean to make a game these days. It seems all people care about are in game items, markets to trade them etc. Nothing fun about that for me at all.
I've done a lot of hobby game programming but never worked in gamedev, and the only time I had to use serious math at a job interview was the one time I applied for a gamedev position. It was very refreshing exercising these atrophied math muscles.
EDIT: ok, not THE ONLY time, I remembered a few more, but it's much less common in non-gamedev
Most of my work is spent capturing frames in graphic debuggers, analyzing them to identify issues, then implementing necessary performance improvements. For a fairly representative example you can read this article I wrote about one aspect of my work for Lost in Random: https://agentlien.github.io/fog . It doesn't go very deep into technical details since it was more aimed at people with some technical knowledge curious about game development rather than fellow graphics programmers. As such it doesn't mention the actual performance optimizations brought up during my internal presentation at the company.
As for necessary skills: A lot of it is simply low level programming and knowledge about the target hardware. There's also the specific knowledge of graphics APIs and the languages and tools to work with them. When it comes to math there's a very heavy focus on linear algebra, even more so than in game development overall. Everything is about vertices and transforms applied to them. For modern shaders there's also a fair bit of calculus since everything from BRDFs in physically based rendering to effects such as ambient occlusion are described using integrals.
I hope that answers your question.
Relevant Escapist video about out-of-control rampant copying in Mobile Gaming: https://www.youtube.com/watch?v=Q30qZSEnI9Q
For example, if the Epic game store became known as a source for good mobile games, customers will stop browsing the App/Play store for games and will instead go to the curated and high quality alternative, because why the hell wouldn’t they.
If Apple and Google are forced to stop suppressing competition on iOS/Android, it may lead to an entirely new mobile gaming industry that’s actually somewhat respectable.
Anyway, I would certainly not choose to develop mobile games, seems like a bad idea for many reasons. But look at PC games: you can make something as absolutely weird (and arguably 'unmarketable') as Disco Elysium, which needed no "lottery", it's simply a masterpiece.
It's a separate discussion, but I believe there's still a "lottery" aspect to indie games. There's a lots of survivorship bias as play there. For every Hollow Knight or Disco Elysium, how many other passion projects run out of funding, or get released and go unnoticed?
People are hunting endlessly for good games. But cannot find them.
Even me! I'm a knowledgeable nerd with time, but I can't find anything worth playing. I know many people in the same situation.
There aren't really unknown gems. Great games don't go unnoticed. Many indie devs just like to think they do because they don't want to accept that their game just isn't very good.
Hollow Knight and Disco Elysium are great examples. These could never have gone unnoticed. These are professional efforts from teams of dedicated, very skilled developers, who did a lot of non-obvious things the right way. Nothing replaces a game like Disco Elysium especially. It was always going to get noticed. (I don't know HK as well but from what I've heard it is also exceptional at what it does.)
I'd be interested if you could name any unnoticed game that approaches either of these two in being compelling to play.
Yep, see any of the 200+ Wordle clones and derivatives out there, only about two months after it went viral.
One of my video games has had at least five clones made that I'm aware of (probably several more than that), and it didn't have anywhere near the same success that a game like Wordle did.
Hence why you should sell shovels in a gold rush, and why it's a bit of a lie to sell any tool as "be able to do 2x in the same amount of time", since that's only a short term effect until everyone is aware of it and '2x' is the expected new norm.
Maybe if you substituted "AAA" for "good". But the plethora of tools for making games have once again made it possible to make some really good games with comparatively small teams.
Even "indie" games typically take a dedicated team of several people a few years.
If you want to do a game by yourself, you either need a ton of skills or you need to be brutal about cutting the features. For example, a single person can build an interesting ASCII roguelike today. But you're not going to get an AAA look, that's for sure.
Fun, however, is a much harder quality to define.
I think the game industry has a lot of extremely talented “10x” developers that are also underpaid and overworked.
That people are willing to put up with the terrible conditions in the game industry is an example of how interesting and fulfilling work is many times more attractive than a good salary and work/life balance. A boring SAAS company will probably never beat a game company with a fraction of the budget when it comes to hiring/retaining the best devs.
I've got videos for days but this one's short and pretty representative. https://twitter.com/LeapJosh/status/1493974909936189440
I'm shooting for AAA ASCII.
This is a terminology hole that I hope we fill, because I feel like the indie space is definitely rich with games that are certainly not 2022 AAA, but also obviously miles above ASCII Nethack or 2D pixel sprite art (which I like and all, but is not in the same league of difficulty). It feels like there's a lot of stuff in the sort of "pretty good looking for an XBox360/PS3 game" range.
There's definitely tons of ps3 games that look better than any indie games I can think of (mgs4 comes immediately to mind, what a visual feast.) I don't think it's inappropriate to say my game and many other indies are visually competitive with horse racing 2016, a game with a ps4 release.
Hardly AAA competition -- I'm just charting the territory of the bands.
The conversation muddies between talking about rendering features and aesthetic execution. If all we're talking about is rendering capabilities, I'm confident saying this segment here is beyond what a PS3 could do. The fillrate alone! https://twitter.com/LeapJosh/status/1455511983512436737
Regardless, of course it isn't reasonable to outcompete 100+ people teams solo, but we can be scrappy and punch above our weight. :D
There are some. III and AA come to mind.
You will probably have to make a game that is smaller in scope and/or less polished than Banished, or your game will take more than a single technology generation to ship.
Good games are good games. You can always sell a DRM-free executable and it'll have the potential to be considered "good" if it's..fun, memorable, clever, challenging, etc etc etc etc
Maybe the gaming industry needs to change the way funding is managed?
The most important thing i learned was that implementing your game as classes (with inheritance and all that) is futile. Use ECS (Entity-Component-System), its awesome.
Even a simple MVP takes like months or years to develop. During studying how Disney designed animations (the 12 principles, like anticipation, staging..) i realized just how deep you need to go into non-coding things like animations, music, graphics, UI, and more.
Shout out to the r/roguelikedev community though, they are awesome. People coding on their rougelikes for 12 years seems to be not extraordinary.
And of course, what often gets forgotten: Make sure it is fun, somehow. In my opinion, nobody can "make" a good game. Can just pump out a lot of games, and hope one is good. Be it EA, or King Digital Entertainment.
I once had a goal of working on a beat 'em up engine for fun. I wrote one version on Mac and then later thought to write it in javascript. Like many other projects I've done, I got it to a working state and moved on. :) Take a look here if you're curious: https://www.ussherpress.com/yokosukajs/
It's not "true" game development, i.e. using modern 3d engines, but it did cover the core issues to think about, and I was learning to write more fp-like code at the time, so it helped me learn functional programming a bit.
So, to echo other people's comments, there are transferable skills in game dev.
Except that changing direction quickly left/right feels kinda bad. Seems you wait for the animation to finish before checking for new key presses, not buffering the last pressed key.
For some background, I have a state machine for the animations and I've set up some to be interruptible starting on certain animations, and in this case, I the "turn around" animation has to play out completely before I allow new directions from the "director". (I call the characters on the screen "actors" and the source of directions "directors", which can be a human or AI.) Anyway, the fun was in coming up with the engine, of course. :)
Seconded. Coding a roguelike in C and the amount of flexibility it gives even with no help from the language itself is crazy. It's really amazing how many concepts that were really hard to abstract become easy. Want a rock to move around and cast fireball? Give it the Actor and Spellcaster components. Do it dynamically at runtime. Now you can make a spell that makes rocks into wizards (.. if only, dynamic effects are more complicated than that, but it's a good showcase of the possibilities)
Basically, entities consist of components. Components should ideally just be data (a struct). Systems work on components (data), they are the code / functions. A system only cares about it's component (but for all entities, which have this component).
A entity "player" consists of the components like "texture", "input". A "monster" entity has components "texture", and "ai". The graphic processing done by the texture system doesnt care how the changes in x/y position is happening (via AI statemachine, or keyboard input).
Player and Monster should shoot too, so attach a "weapon" component to it. But then it's also possible to also create an entity with components "texture:door" and "portal" (portal system will teleport you to something, e.g. next level). No one stops you to attach the "ai" component too, making the door move around. And "weapon", which makes the door shoot too (then maybe call the entity something else, like portaling-monster).
As the components are just data stored outside your code, e.g. in files or a DB, you can change them at will. And load it, without recompiling or even restarting your game! This allows a large amount of creativity and innovation, without refactoring your code all the time.
I like to connect my systems with a message bus, where they send messages to each other. Messages change components, data, of entities. These may generate more messages. E.g. player clicking left mouse button creates a message, which gets handled by input system. This creates a message for the weapon system, reducing ammo count by one, and change its texture (-index) to like "shootingstance:1", and creating a new entity "bullet" with the source x/y and destination angle.
There's lots of great example code in the docs and within the repo itself, for what it's worth!
The entity itself can be literally just an int id. To make a new entity, request a new id. Since everything about an entity is contained in what components it has, you don't need more information.
Components: they're just data. You can model them as structs:
I hope the comments explain. This is all the component is, data. You can have a helper function which stores it in some data structure where you keep each entity's components, indexed by id.Systems. They're just function which operate on entities which have their component.
You call the system function in the main game loop.Note: something a bit "unorthodox" here is the fact that the Actor system here also directly gets a handle on the position component. Others prefer event systems, where instead you would fire off an event. My RL is single-threaded (I can definitely wring enough CPU perfomance without needing to overcomplicate), so I've opted to just pass handles around and have each system call each other directly via passing handles. In this example, the Walk action would call into the position system's function via the handle passed. This greatly simplifies code, and allows me to do partial updates of the game state outside the main loop.
edit: Also, in case you're wondering how the data about what each entity is stored (since that seemed to be the crux of your questions). You can have a data file:
Then you read this in and dynamically build an entity: I hope the real code is readable enough to serve as pseudo code alternative.One advantage is you can generate semi-randomized entities, and dynamically change their components at runtime. You can't do that with OOP.
Even more, in networked games it can be used to roll-back actions you did (e.g. because someone with a 100ms ping shot you 50ms before launching a rocket, to roll-back rocket-launching animation). Or in the simulations of the behaviour of the other players (peeking around the wall).
The advantage of this is that this requires less code, permits very good separation of concerns and is very transferrable even between engines. Unity, for example, uses something similar where components and systems are in the same class together. For self-coded games, there's several libraries too.
If your goal is to make a game in a reasonable amount of time, I kind of disagree with this advice. Implementing an ECS system before anything else is a good way to find yourself spending time yak-shaving instead of actually building your game, and for most 2d games, YAGNI (at least not right away).
My personal advice would be program some of the major game systems and objects you want for your game first, they'll probably take you longer than expected but at least you'll have something that actually resembles game play and not just a framework for building a game. If you get to the point where you need ECS for performance or organizational reasons you'll probably have a good idea of how you want it to work by then instead of guessing at how you'll use it.
For example, I've got game with a core game loop that's been finished for probably a year now, but I've still got a ways to go with everything else before I'm finished with the rest of it.
Fast forward 25 years later, I have installed Unity, Unreal and some other OpenSource game development environments, and I just cannot find heads or tails. I've followed some Udemy courses, but for me, the current "game development" process feels more of a "graphic designer" process than a programming process. I would love to make games, but it seems that the current "tools" are more tailored to artists type rather than programmer types.
And there is a bit of a difference between game, and game engine. Unity is really for creating games itself, where most part is not engine work. Like most developers, we like to do engine work though, not graphics.
If you want some fun, find a lower-level engine which just implements some parts (e.g. while Phaser.js is a big game engine, still need to do a lot of coding by hand). Alternatively, use weird things. ASCII, HTML Checkboxes, voxel graphics, svg, in rust...
sips coffee
I don't know about that. Yes, if you are only learning frameworks then sure. If you are digging deeper and understanding, GPU programming, math, performance optimization, architecture, physics modeling, network programming, all of those are very transferable skills.
I think that some of the problems boil down to the language used. Game engines tend to rely heavily some Editor (be it Unity, Unreal or Godot).
I'm hoping that Rust will solve some of this by having you use a pleasant language instead of relying on GUI tools.
I legit think that it would make sense for high schools to structure their curricula around game making. You will learn math, physics, writing, art, music, programming etc etc. And you will have fun doing it.
But, it's odd, the author says in the same article: "you have to know about art, music, AI, level design, dialogue, story, just to mention a few."
Many of these skills ARE transferable! They're also a lot of fun!
The larger point of the article still stands. I've never completed a game (maybe someday...) but I really enjoy the hobby aspect of it.
it takes years to make games
and you think a language that have horrible compile speed can succeed?
look at the market today, nobody wants to use C++ anymore to make games
people moved to unity because it is fast to iterate
unreal? people use blueprints for everything nowadays BECAUSE c++ is a pain and slow to compile, it hurts iteration time
rust/c++ are anti fast iteration, it's anti-gamedev
the people who push rust in gamedev are clueless and they deserve the language, best way to make people hate the language even more
look, 5minutes to compile a single line of code in Rust in this game made fully in Rust, what's the advantage? the biggest advantage is these devs will be able to think about doing something else, because they'll never be able to release a game within the next 10 years at this rate
https://www.youtube.com/watch?v=nR2WDBMjkh8&t=976s
i cringe each time people mention rust in gamedev, i cringe very hard
There's a ton of realtime networking concepts (web sockets for realtime chat, etc.) as well as potential investigations into cloud management and realtime databases for multiplayer game state/sync etc. that could be useful during a technical interview.
It might even be that multiplayer games are probably on the leading edge of the application of some of this technology and would give you a leg up compared to other candidates.
There's also the potential you could end up with a more social game that broadens the potential audience for the game in terms of players and code contributors.
Specifically with godot:
Godot Multiplayer Docs https://docs.godotengine.org/en/stable/tutorials/networking/...
Godot with Firebase https://www.youtube.com/watch?v=-vDNk7BzOGc
If you think of the game world as a representation of its internal state, all games are similar. Editor's are only easier way to build the initial scene tree. Shaders are just a coat of paint on top, etc.
There's nothing fundamentally different between the unity editor, the Eden editor and the build editor.
You don't do it because it's easy, you do it because you enjoy the journey. If you actually want to produce a video game for commercial reasons in a reasonable time frame, hire a team or partner with like-minded people. Cut your scope in half, or more.
I thought it would a cute fun thing to with my kids since they love minecraft but . . . I'm not finding tutorials or books that work for me. Tons of documentation, tutorials, books are out of date, and I find the unity official tutorials not that great, they seem to be focused on super specialized tracks.
Anyone have any good tutorials, books, videos they'd recommend ? I'd really like something concise and focused on 3d game development in unity without too much frills just to get handle on the basics.
Get familiar with the fundamentals before hopping into a huge game engine. Also avoid 3d for a while, the introduces so many complications and its hard enough just making a 2d game. A simpler game framework that unity can be used as well, like MonoGame, or Godot, or one of the Python game frameworks.
The books, tutorials, and videos out there are okay. They will more often than not get things working. But the problem is they don't really go beyond that. They kinda assume you're a solo game dev working on a solo indie project and that's that.
To go to the next step requires a mix of game dev knowledge (I've obtained a bit over the years), lots of software design sensibilities (to recognize when something doesn't feel right), and lots of digging on the internet (to try to find out how professionals are solving the problem you just ran across).
What are you finding difficult? It's hard to make recommendations without a good idea of where you're stuck.
My general advice, however, would be to just make things. Figure out a mechanic you want to implement, find any resource that describes how to implement it, implement that mechanic, and then move to the next thing.
It's much more valuable to just build things and figure out how the systems interact as you go than it is to try and get a bunch of theory out of the gate, especially if you're not building your own engine.
Also many tutorials and examples are too toyish and are missing practical concerns like cross controller compatibility, and other real world concerns. I've got some very simple 3d games working, but I'm missing how to take them further feature wise and make them closer to "real games".
I'd really like a resource that's very opinionated and pragmatic for independent game development.
Don't worry about "real world concerns" until you have stuff that works at all. You're not building a winning product on your first try.
> I'd really like a resource that's very opinionated and pragmatic for independent game development.
Sounds like you're finding a lot of very opinionated resources. :)
However, there is no one "pragmatic" resource in game development. The pragmatic solutions are scattered about. Not to mention that, as you are already aware, there are lots of ways to do things. You just have to pick one and run with it.
Yes, I'm finding lots of opinionated resources, but not informed opinions from experienced game developers/software engineers. Instead I'm getting lots of non expert, new to game dev, or new to programming opinions. When I follow them, I immediately run into an issue, that requires extremely in-depth thinking and usually a different architecture. It all just feels half-baked.
Though I suspect I'm heavily spoiled by the fantastic salesforce learning ecosystem.
If you want "rigorous software engineering," you really have to look at formerly commercial (or even still commercial) games that have been open-sourced and try and figure things out from there. Good learning materials are just hard to find. That's why I said just build stuff. You build it, you apply whatever optimizations to the structure or code itself, and you learn good practices through experience.
I feel it's very similar to learning new languages. Once you understand the common principles and low level details you can very quickly learn and become quite efficient with a new one.
* 7 years in the game industry proper, 4 years in surgical simulation
However, even with game engines, I have spoken with AAA developers who have worked with both Unity and Unreal and they all say the same thing. Game engines are a lot like programming languages in the sense that once you learn truly learn how one works, picking up a new one isn't that difficult.
As someone who has worked as a AAA game dev for almost 13 years, can confirm this analogy holds true. Off the top of my head, I can recall 8 different game engines I've worked on (all proprietary). You start to pick up on the common patterns and ideas between them, and learning a new one boils down to figuring out familiar interfaces. Just like when learning a programming language, you look for the fundamentals (loops, conditions, data types, etc).
At the end of the day, "game engine" is a fancy way of describing an amalgamation of systems that gather input, maintain a complex state machine/simulation, and draw it on a screen. And from my experience, the way different engines accomplish this doesn't truly vary that much.
I've mainly done engine and tools work, often for UI or scripting systems. From my experience, each studio and franchise tends to make its own custom engine and tools. Although, in some cases we managed to reuse a decent amount of in-house technology across projects. The Tony Hawk remaster was an unusual case which used Unreal Engine instead.
It's given me an interesting perspective behind the scenes of AAA games. These titles may all use different software but they're fundamentally built on the same principles. Once you get the gist of how games like this are put together, learning another isn't a big stretch.
At a more high-level HMI/game design has a pretty large overlap. No one knows what "fun" or "easy to use" are, so the approaches to converge there are similar(rapid prototyping, etc).
Indeed, understanding how a computer actually works is probably the most transferable skill there is.
And yeah, I've switched between many game engines over the years myself. Unity, Love2D, Flash Actionscript, Pico-8, XNA, Cocos2D, QBasic, TI-BASIC (texas instruments calculators), Hypercard, PyGame, Popcap Game Framework (C++), straight up OpenGL, J2ME, Kindle Active Content (basically Java), PhaserJS, and Swift + SpriteKit. It's about as transferable as going from Angular to React (which I did when I switched jobs six months ago). Yeah you have to learn how to do some things differently but you can pick up the new one pretty quickly if you've had experience with the other.
I do have a lot of unfinished projects, but that's also true for me for websites, apps, writing, puzzles, and board game designs as well. It's not specific to video games. Also most of them are unfinished because I got distracted by other projects or decided to go a different direction, not because game dev is hard (although it can be). I do have about 20 video games I worked on that were released into the world at one point, also.
8 MILLISECONDS
your skill when you write sloppy REST API code in nodejs is not transferable here
you have to be creative while being able to write performance first code
you can't pump more hardware to solve problems, if your customers have a shitty PC, your code has to run well on that shitty PC
My path, and what I recommend, is do something hard and important which pays the bills at a premium. I did infrastructure work, and I was lucky to have a great decade long career allowing me to "retire early".
Now, I can work on a game at my pace building the tools that I see fit. I'm focused on board games because they have a timeless quality about them. I'm developing an entire SaaS platform and programming language to make the network goo beyond easy. http://www.adama-lang.org/
As I'm getting close to some kind of launch for the SaaS, my next thing is to build up my own web based IDE with a release-often ideology such that I can build a Roblox for online 2D board games. Honestly, I'm having a blast because I'm not suffering tools which are going to fade.
I'm going to be building the production cluster soon
I've been working on a Metroid Prime clone in my spare time just for fun in Unity. And yes, what the author says is true - it's really freaking hard to get all the details right. Even something like weapon bobbing when you move takes some thought. But it's really rewarding and fun, and I am basically making my dream game. I don't expect to ever release anything, but I'm enjoying the ride.
Also, anybody ever write DarkBASIC as a kid? This was the first programming language I ever learned, because I wanted to make games. It was a great intro to programming.
Over that course you see a lot of people come into the community, have all sorts of beautiful visions and grand ideas, run face-first into the harsh reality that they are ill-equipped to realize their dream, work on arcane technical aspects of their code with the dubious goal of developing some kind of interesting skill, and eventually burn out.
The thing is—I agree with the first point that “most developers will never finish their game” but I think the wrong lessons are being taken here.
If you try to understand the problem, there multiple contributing factors which explain why amateur developers fail to make games, and once you start to understand these factors, you can nudge people in the right direction or at least give them a map of the territory.
- Cause: The gap between skills and vision is large. Mitigation: Reduce game scope, study relevant skills, work with teammates.
- Cause: The gap between skills and vision is unknown. Mitigation: Complete small projects to get a better idea of what skills you have and a better ability to estimate the size of projects.
- Cause: The developer never finishes any projects. Mitigation: Game jams and short deadlines.
- Cause: Projects fail to attrition—the developer’s interest wanes over time, and the project gets less fun over time. Mitigation: Shorter timelines, smaller projects.
- Cause: Poor technology choices. Mitigation: Use mainstream / popular technology such as Unity, Unreal, Godot, etc, and give yourself a limited number of passes to pick a weird technology.
- Cause: Deep, unexpected technical problems with the game. Mitigation: Start by making games that are more similar to existing games made by teams with similar resources and experience levels, until you have more expertise.
- Cause: The game looks terrible. Mitigation: Work on a team with an artist. Or dedicate time to studying art, and find an art style that you are comfortable with that does not require too much effort.
- Cause: Can’t figure out how to solve basic programming problems without a tutorial. Mitigation: Work on a team with a programmer. Or dedicate time to studying programming.
- Cause: Design choices unexpectedly cause high workload. Mitigation: Make prototypes to test critical design choices.
- Cause: Iteration time is too long. Mitigation: Use technology that supports faster iteration times.
This stuff seems obvious and yet there are so many obvious things that typically go wrong in a failed project. “I never considered working with teammates” is common enough. “I don’t want to give up my idea of an action RPG with Metroidvania platforming segments and a massive branching storyline” is a common enough type of problem. These problems can be solved much more easily when people working on games spend time in contact with people who have the experience—professional game developers or successful amateurs are one obvious choice, but school is another good choice. You can make the same mistakes over and over again, it helps to have other people around to point it out for you.
> I myself have abandoned 2 dozen games, in platforms ranging from PhaserJs to Unity to Godot.
This is, frankly, a bit worrying. It reminds me of Schopenhauer’s take on will, how he calls will “blind incessant impulse without knowledge”. We feel the strong urge to make games, but these incessant impulses must somehow be tempered and refined if they are going to achieve anything.
Have you given a talk or written more in depth on this? If so I for one would be interested in it.
https://www.moria.us/blog/2021/07/9-reasons-why-nintendo-64-...
I'm thinking of the concept of focusing on a vertical slice, not a minimum viable product (MVP) or any particular capital "A" Agile framework. In a CRUD webapp this concept could be a user login, on its own it doesn't do much but its a functional part of the app - vertical slice in the sense that it cuts across all parts of the tech stack - UI, app server, and database.
In game development maybe this could be something that focuses on building something functioning that involves artwork, music/sounds, animation and data (state of some kind). For example, a fully working character model that can jump, shoot, collect objects, whatever.
As an amateur, I think prototypes are just the bee’s knees. They can be as ugly or as unpolished as you like, and you can just print debugging information straight to the screen. Even if they don’t turn into real games they’re often valuable, because prototype #10 might refine various ideas from prototypes #2, #4, and #7, and turn into a viable game.
Godot does take a little bit to learn, but it is quite rewarding.
There are a number of larger side projects, game and no, that I've either completed or abandoned over the years, and, like you said, scoping down has been a primary way to help actually get them done.
But, I've also just now found a time slot to work on something consistently in, which has made a big difference.
Many folks don't account for how much "project management" is a key skill in efforts like this.
There's a book about quitting smoking that spends the first 99% of the book providing the proof that smoking kills. The last page is how to quit smoking: "Never put another cigarette in your mouth and light it."
Here's my book on how to make a video game: "start writing a game and don't work on anything else until it's finished."
I started writing a game in college, and despite having tons of cool ideas, I didn't work on anything else until it was published. It got me a good couple of decades in the industry.
>It's easy to lose heart and just quit.
Not if you love it.
>There is no treasure at the end of this rainbow: You can spend years with nothing to show for it
Do you mean money? Sounds like you mean money. Because a great game is a great game. My game made me less than $1000. Which was a bummer, sure. But there's reviews of it on youtube. People enjoyed it. I am happy, and I had a great time building it.
If this is a means to an end, sure, quit. You simply can't compete against someone who is as good as you but who also loves what they do.
>Sure you can outsource or buy art
Or you can make a friend! I met a guy who had mad art skills, and could create awesome tracker music.
Celeste [1] is one of my favorite games. My favorite indie game. I suck at it but my kid as completed it. It is insane hard, massively rewarding, and the story is moving. IIRC these folks got a house together. Make friends!
[1] http://www.mattmakesgames.com / http://www.celestegame.com
It seems like the barrier to release a game and actually have people play it is so damn high.
But before Apple effectively killed it, the Flash ecosystem was beautiful. The games were simple, came out fast, and fun! You could have a proof of concept with less than an hour of gameplay, get it published on Armor Games or Kongregate, and have people gush on it and give feedback.
closest thing I can find seems to be Unreal offering grants
Indie devs are particularly susceptible to imagining their game is fun, and attributing that to the fact that their idea must be a good one. This is triply terrible when the plan is to make a game that is big and has tons of story.
I have only done the tutorials for godot. Not even trying to start my own project. The real caveat for me on video game programming. The programming isn't the problem. It has everything to do with 3d modeling, texturing, etc.
I kind of dream about starting my own video game project up using godot, stream on twitch/youtube making it so I could get some revenue going. Kind of what star citizen wanted to be, starfield will likely be, with my own take. Kind of a skyrim meets han solo meets the martian meets chess meets piano meets metasploit.
But I really hold back because family to feed, diapers to buy, mortgage to pay. Boring game dev streaming like that won't be paying those bills.
Oh for sure, godot has that built into the engine I believe.
https://godotengine.org/article/godot-3-vr-and-ar-support
My big feature I would be supporting 100000% is BCI. Being able to play without keyboard/mouse/pad just your brain.
The game wouldn't be super serious. Kind of TF2 style where it's more casual. Robot's would pick between 'binary and non-binary' for their gender lol, tongue in cheek joking obviously.
I think there would be a factor of trying to build teams as well. Han Solo isn't Han Solo without Chewbacca. So obviously at least co-op to start.
But alas, as I said. On hold until a million $ lands in my backyard.
There's also a lot you can do with 2d pixel art assets in 3d if you like a retro style. Godot has (Animated)Sprite3D which makes it very easy.
Though it may be fun, setting up a whole streaming platform and engaging an audience is a whole shitload of extra work on top of the actual gamedev, so if you have limited time best to really truly treat it as a hobby and squeeze in an hour or two on certain evenings or something.
I love Godot BTW, here's my latest project in it: https://twitter.com/TetrisMcKenna/status/1486629669252313088...
Oh for sure. I've been 3d modeling for years. I'm big into cad and 3d printing, I used to know blender decently until they moved everything on me in a recently big release. Really should have taught myself shortcuts lol.
>Though it may be fun, setting up a whole streaming platform and engaging an audience is a whole shitload of extra work on top of the actual gamedev, so if you have limited time best to really truly treat it as a hobby and squeeze in an hour or two on certain evenings or something.
Gotta pay the bills. Without those options, where does one make enough money?
>I love Godot BTW, here's my latest project in it: https://twitter.com/TetrisMcKenna/status/1486629669252313088...
<3 roguelikes.
It makes me a better programmer.
Perhaps it seems obvious to say, but I have only recently fully internalized that making games is not the same activity as playing games, and that it will take many orders of magnitude more time to polish even one gameplay feature compared to how long it will take for that gameplay feature to become stale _to me_ as the dev playtesting that feature over and over again.
I wonder if a lot of gamedevs just get tired of playing their own game and thus don't care about it anymore as a result?
Seth Godin has a book called The Dip about the slog in the middle that many creative projects have (business starting as well). I wonder if gamedev has a particularly nasty dip and that is why so few finish.
FWIW, if you work on large enough projects, you probably aren't playing the game that much at all unless you're a gameplay programmer (and even then, you might only play the small fraction of the game that your feature touches). I do graphics/engine programming for games and the closest I get to playing the game is "load into level, teleport to position X, use a cheat code to give me item Y, use Y, see rendering bug"
I've joked on some projects that I'm excited for the game to ship so I can learn how to play.
Having the commitment to finish (and know when it’s finished) is hard.