https://www.youtube.com/watch?v=Fy0aCDmgnxg
As for your first point, I would suggest aspiring devs to try to prepare themselves to take part in "game jams". The constraints (including a time constraint) help focus on important parts.
- Say, I know what I want to build exactly where do I start? a.k.a -- What's the equivalent to starting at the DAO / API layer and building the integration later, in the gamedev world?
- I know I'd like to make games, where do I start coding?
I focused a lot in the article about that first question (and only briefly alluded to prototyping, etc.) -- mostly because I was interested in the theoretical question of engineering practices.
Two little books that can help:
1. From A Theory of Fun book blurb:
“A Theory of Fun for Game Design is not your typical how-to book. It features a novel way of teaching interactive designers how to create and improve their designs to incorporate the highest degree of fun. As the book shows, designing for fun is all about making interactive products like games highly entertaining, engaging, and addictive.”
https://smile.amazon.com/gp/product/1932111972/
2. See also The Art of Game Design:
”Over 100 sets of questions, or different lenses, for viewing a game’s design. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again.“
https://smile.amazon.com/Art-Game-Design-Lenses-Third/dp/113...
As a professional software dev, I've noticed that while both game dev and software dev are "writing code", they are done in a very different way.
As a software dev, the value proposition is more or less clear before you start writing code. As a game dev, you can only start to see your value proposition after you have finished your code - that's why game code, especially as an indie without clear distinction between prototype and production phase, tend to become spaghetti really quick - and that's fine. If you spend too much time to make the code look nice, then you are not spending enough time to make the game actually fun.
Software usually has some logic behind it - it has to make "sense". A game doesn't necessarily have to make sense - it needs to "feel right" and "fun". That means your nicely designed abstractions actually won't be reusable - copy & paste is much more pragmatic. You can start to look to refactor after your game is actually successful (or fun at least) but even then you will realize that most of the code is not reusable.
A big part of your game code is actually "content", instead of "systems" - meaning they are closer to a "script" than a well architectured software code. So you write more if-else and less inheritance and encapsulation (unless you are writing your own engine, then in that case, your engine code is actually close to software projects).
And if you hate writing UI for software, you'll hate writing UI for games even more.
The best graphics abstractions allow artists to pretend they’re working with just another pencil or brush. To them, it should be as non technical as possible. Without tools a perfectly functional physics system is useless since it’s only simulation. There’s no content.
You’ve effectively created a new world for the artist to operate in, but have given them nothing to use. “You need a stage to act? Well there’s a tree over there...”
They’re really good at technique and learning things, but they tend to build the work around those techniques and limitations. The tools you give them focuses their energy in the places you want. The absolute best graphics programmers get this too, and it can all end up a creative and cohesive show if done properly. There are many games that intentionally limit the art in some way to create a theme. A way to get a bunch of artists in the same creative space.
The actors work together with the crew and backstage in the best shows. And that’s a game. A tight dance between the artists and technicians. Personally that’s where my love for it comes. Putting on a good show is hella fun. And artists respect tech. They may not get it, but they always respect it. Unlike business.
When you’re alone you have to do the same dance.
Recommended short read, I'm sure you'll find yourself here and relate to your non-indie-game-developer self too!
https://catlikecoding.com/unity/tutorials/
They're great for people who are already self-sufficient programmers, and just need to quickly get up to speed on how Unity does some specific things.
something I struggle as well is to find good 2d tutorials + handling multiplayer in unity.
Any link would be super helpful
I ended up engineering a fairly complex system of containers and components with mouse events, layering, conditional rendering and caching, but never finished the game.
Since then, any time I'm itching for something fun to work on, I revisit that code. I've had several attempts at moving it away from using Classes, to functional, to trying to build it in React. The last attempt led me to react-canvas, which while not exactly what I was trying to make, was close enough that I felt defeated.
That helped me realize I was more interested in the system than the game, because I could've just used react-canvas or plenty of other 2d game tools to build it, but I never chose to do so.
If you're a solo dev I think it's really important to focus on the areas where you don't have any skills. For example art, animation, effects etc. All of these could potentially be a big hurdle, depending on the idea that you are developing.
Learning how code works in Unity (as a developer) isn't that difficult, it just takes a bit of time. Say you need to add more advanced elements, for example you need some form of space partitioning? If you know the terms then searching for existing code (e.g. a good KD-tree implementation) on github is also not a problem, and you shouldn't have any issues implementing it in your game.
But figuring out what art assets you're going to need, how you're going to create them (or source them) and integrate them into the engine can be an issue. As per another comment, "juicing" the game up takes you out of your developer comfort area, you need to really tap into your creative side there.
Things like ambient occlusion, bloom, reflection probes, and physically based rendering/materials were totally unknown to me but were really essential to making a game look “AAA”.
Adrian Courreges has a great list of graphics studies that expose you to the space: https://www.adriancourreges.com/blog/2020/12/29/graphics-stu...
Following technical artists on Twitter is also a great way to get exposure on more one-off techniques (how to make a fire effect etc.)
I’m a big fan of @minionsart and @adrianmendezzg but there’s tons of other indie devs and technical artists sharing their work.
It's going pretty well and I'm happy with what I've been able to do. It'll make it easier to start marketing earlier as well, which is a huge plus.
Thanks!
Learn what GameObject's and Components are and how they work. In Unity you have MonoBehaviour derived classes, but then you might also want some of your own non-Mono classes (for example an Entity-Character-Player/Civilian/Enemy inheritance structure).
For my code framework in Unity I create a GameObject in my scene that I call MainScripts. On this I'm going to attach all my generic Mono classes such as Game, MapList, AudioManager, UnitList etc. I call DontDestroyOnLoad on MainScripts so that it will last through all successive scenes.
Game is the main game class, I use its update to drive as many updates as I can (for performance reasons you want as few Unity Update methods running as possible). So for example inside of game's update I'm also calling my input's update, my own timers etc.
The next big problem is how does code in random class X access another class? For Mono classes you can go through the whole GameObject.Find/GetComponent in your Awake or Start methods and store them; BUT you might not have direct references to all your own code that doesn't inherit from MonoBehaviour.
For that I create a Static class. I'm going to place static references in here for everything global in my game, the previously mentioned MainScripts, Game, etc. As a random example, some Mono class might need to know if the control key is down. Since we're doing all input in our own input class we don't want to test through Unity again if control is down. Our input will already have a flag set, so then we just test something like if (Static.input.isAnyControlDown).
To setup Static we call our custom Static.Create from Mono Game.Start, which Unity will automatically call. Place Game very high (low #) in the Unity Script Execution Order so it will always be created first.
After that you have a code framework to hang everything off of. Hope it makes sense!
Some folks in the replies mention just starting to code and while I totally agree, it was also helpful for me to understand... at least the concepts.
TBH when I started, the main way I did this was my finding a course on Udemy and watching it at 2x speed, still being bored out of my mind for huge chunks of it.
[0]: https://blog.eyas.sh/2020/10/unity-for-engineers-pt1-basic-c...
It's visual programming, but it's easy to explore around, there's nice debugging interfaces, and the type inference stuff makes it so that you are presented with a lot of the engine details in a nicely digestible manner.
Unity it's like "OK make a bunch of C# classes and coroutines!" and it gets real messy real quick if you don't know what tools are available to you.
One resource worth mentioning is: https://www.researchgate.net/publication/228884866_MDA_A_For.... Working backwards from the desired kind of game you want to make based on the 8 categories this paper talks about (sensation, fantasy, narrative, challenge, fellowship, discovery, expression, submission/abnegation) can give you a clearer way of measuring success than whether you did a good job implementing whatever mechanic you thought of.
Another thing the article doesn't mention that I think can be valuable for software engineers is doing paper prototypes. As engineers, we often think about producing code as the only way to build prototypes, but sometimes you can get mileage from testing a game mechanic through much cheaper to produce paper prototypes of the game (or a part of the game).
Get to the very core of what you want your players to feel, their mindset, etc... and then build on top of it.
Part of doing this well is playtesting (note that this is not QA or usability testing, and especially not focus testing). Think of game designs as hypotheses and playtests as experiments. You can learn an absolute ton about your game just from doing this every week or two. I've found that using Steam's Remote Play Together feature made this quite feasible during WFH.
[0] Link in bio if anybody is interested.
The text on this blog is huge and sparse, and two of the pictures take up more than 100% of my vertical screen space.
When did people forget about desktop browsers????
What would you change to make this a better desktop experience for you? Less of the full-width photos? Text that spans wider, or just lest line spacing?
I'm not sure what PC you're using but full-width is not nearly as egregious as full-height. On my 20" 4:3, the first photo is almost exactly 100% height, second is perhaps 120% height.
Are people surprised by this stuff? I can't be just an old coot shaking my fist at the kids on my yard. Compare the blog to HN, side by side. Or Wikipedia. Or Washington Post. Look at the content density side by side.
For many years one of my favorite talks about indie games development was Jonathan Blow's speech at UC Berkeley CSUA (2011) (http://the-witness.net/news/2011/06/how-to-program-independe...)
Initially I loved his main message during the talk: "You have to be brutally effective to finish a project in a reasonable amount of time."
But there's a part in the Q&A that later grew to be even more poignant to me:
https://www.youtube.com/watch?v=JjDsP5n2kSM#t=1h13m8s
> Q: You said you worked on many projects before Braid which didn't quite get completed. What was special about Braid which made you complete it?
> A: What was special was it had been a long time since I'd finished anything on my own, and I sat down and decided that "Dammit I'm going to finish something this time". And, "To that end, so I can finish this, I'm gonna make something that is technically pretty simple"...
For some of us, it's REALLY HARD to complete a side-project while working full-time job. For most of my career I had completed a real game only when it was for a job (or for a client) and I worked on it full-time.
The single reason I hadn't made a game as a side project was because I'd quit before I finished. I finally figured out something that worked for me, and it was counter to all the advice I'd heard. I'm sure this is different for other people, but for me the key to working day after day consistently (not quitting) on a project while working full-time was to eliminate all the "shoulds".
When my conscious brain is always telling myself that I should do the project a certain way, my subconscious rebels and suddenly I become unproductive. There's a ton of great advice out there such as: "Don't reinvent the wheel, build your game not a game engine." The problem is sometimes my subconscious wants to build the game engine, not the game. I can coerce it to do the right thing when it's for an employer, but it's a different story for a side project.
Ever since I stopped "should-ing" myself, I've become much more consistent and productive on side projects. If you want to make games on your own as an engineer, but are having trouble forcing yourself to spend a couple hours every day on it, then I'd suggest that you try to just code whatever the hell you want to code instead of the thing you're supposed to code. You may find, like I did, that it's better to gain some coding velocity, because this velocity gives you the momentum fly over humps that you weren't able to overcome back when you were trying to start working on your game from a standstill.
https://www.newyorker.com/magazine/2008/10/20/late-bloomers-...
> Ben Fountain did not make the decision to quit law and become a writer all by himself. He is married and has a family. [...] “When Ben first did this, we talked about the fact that it might not work, and we talked about, generally, ‘When will we know that it really isn’t working?’ and I’d say, ‘Well, give it ten years,’ ” Sharie recalled. To her, ten years didn’t seem unreasonable. “It takes a while to decide whether you like something or not,” she says. And when ten years became twelve and then fourteen and then sixteen, and the kids were off in high school, she stood by him, because, even during that long stretch when Ben had nothing published at all, she was confident that he was getting better.
Just a few months ago I read a blurb (in Scott Young's Ultralearning) about Eric Barone's 5 yr effort to build Stardew Valley. Amazing story. Imagine resisting the pressure to take "a real job" for 5 years so you can work on a game.
html input layer and javascript glue is a order magnitude more efficient than building a guy in a game engine, so unless you specifically want to push into 3d excellence and require full access to gpu performances and features, it can save a lot of tedious work.
I've tried both unity, godot and the previous approach coupled with phaser, and prototyping stuff goes ho so much faster.
first one was bootstrap with a custom theme on the user layer, phaser.js on the rendering layer. The interesting part is I was able to use the phaser render to texture function to have dynamic maps integrated in the html layer, and ship preview in the ship theme selector. I can send you source and everything, the game is basically completed in regards of the original idea I had. you can see it here https://parkedbits.com/Increstellar/ - it's not obfuscated or anything, but the prestige/bonus thing at start is not really implemented in this version
second one is using vue.js for the html frontend with a theme inspired from the NES.css style (but reimplemented as I didn't like their input widgets), with a phaser.js backend because I don't have time to learn two things at a time (vue being the first one). this just has the unit editor and there's no gameplay in sight, but the code is likewise available for inspection (it's just html, no node backend or anithyng, just static files)
Doing something polished as a one man band is incredibly difficult unless you are extremely multi-talented. Sound effects, graphics, music, game design are all skills that you probably don't have.
It is an amazingly fascinating world though and you learn a lot doing it. Just don't expect to become rich or famous!
https://opengameart.org (open art collection)
https://www.beepbox.co (music sequencer)
http://www.roguebasin.com/index.php?title=Finding_graphical_... (tilesets)
http://grafx2.chez.com/ (pixel art program)
http://www.wings3d.com/ (3d modeler, easy to use)
http://spiralgraphics.biz/packs/ (tiling textures)
I tried Wing3d, but somehow it never felt the same.
This build is really out of date, but if anyone is interested I’ll post a link. I’ll have a significantly updated one up sometime in March hopefully https://hertzrat.itch.io/a-few-nights-room-and-board
My favorite apps and games are my own creations. Since I don't need to make money on them, I don't bother releasing them on the App Store.
I've tried that, and the reviews I get are bizarre. Aside from not dealing with the unruly public, I save a lot of time not worrying about distribution or support or marketing.
So if you want to make games or apps, go for it! Ignore the cries to ship your stuff. It's pretty clear who are in it just to make money, vs. enjoying and being productive programming for yourself.
# Do. Then do it well.
I usually work like this:
1- Hack something as quickly as possible
2- See if it "works for the game"
- If it does, GOTO 3
- If not, abort and go do something else
3- Refactor, re-architect and polish
# Make it so that you can iterate FASTBeing able to change and test an element or a feature individually is crucial.
I have taken a data driven approach to some of the game elements. So I have a big JSON file with the data of monsters and moves. When iterating, I simply change values here, relaunch the game and check if I like the result. I also use this file for "design debugging", starting in a later level, making the character immortal, etc.
I'm using Godot, where each custom element can be a Scene. This means that if I, for example, create my special kind of button, this button is a Scene and I can run it on it's own.
I also have code that runs only when running as scene like this. I usually add buttons of keyboard input handlers to "simulate interactions" with the element.
# Everything is a prototype
Nothing is set is stone. Nothing is final. Everything is a prototype.
Many times, a new mechanic changes completely how the others feel. Don't be afraid to change previous elements to accommodate the new one.
The same applies to code. ATM I'm in my third "rewrite" of my game's Battle UI and UI logic. The new UI arrived[0] and it was somewhat different of the old one. I just create a new file named "NewBattleUI" and start copy pasting and changing stuff from the old one.
Don't get attached to anything.
# "Feel" is the objective
woko and yetihehe's shared talks explain this way better that I can: https://news.ycombinator.com/item?id=26247832 https://news.ycombinator.com/item?id=26248964
My game has a Pokemon-like battle system. After watching those talks I implements visual effects for the moves. They changed nothing for the "raw numerical gameplay" but totally changed the feel of battles.
# Post Scriptum
My game is called One Way Dungeon. It is a linear dungeon crawler with Pokemon-like battles. It's being developed for Android, but you can try the latest web build here: https://vaskivodev.gitlab.io/onewaydungeon/builds/2021-02-19...
[0] I've hired a UI/UX designer to help me design it.