Hacker News Reader

Comment by throwaway894345 | Hacker News Reader

Are there any resources for developing 2D game graphics, especially for hobbyists? It seems like game development articles focus so much on frameworks and just assume everyone knows where to find / how to make graphics, audio, etc. I would be especially interested in a high level "how to make a game" that didn't go so in-depth into the programming details but which did include procuring the assets and perhaps some standard patterns/strategies for managing them in your code. Also, even the general approach for game development--presumably there's some white boarding phase followed by a wireframe phase etc like you have with app dev? What does that look like in game dev land, what are some reasonable tools for hobbyists for each stage, etc?

View on HN

If you want to experience the high level game dev fun, DON'T use Rust, I recommend look at

- love2d (https://love2d.org/)

- PICO-8 (https://www.lexaloffle.com/pico-8.php)

- Clickteam Fusion (https://www.clickteam.com/clickteam-fusion-2-5)

- Godot (https://godotengine.org/)

- Stencyl (http://www.stencyl.com/)

- pygame (https://www.pygame.org/)

That's not what they're asking.

I don't know -- Pico-8 seems to be the perfect answer to what the author is asking for: it's a great environment to learn about these things, and there is a large and useful community and pool of resources around it which will tell you exactly how to develop 2D games (including the pico-zines, https://sectordub.itch.io/pico-8-fanzine-1, wiki etc). The0 "cartverse" and the already included games also provide plenty of examples of games that are both easy to learn from and actually fun.

There's also https://github.com/ggez/ggez for Rust specifically.

does it support webasm/html5?

README says, "Work in progress: WebAssembly".

Writing high level game logic in Rust is not fun, you spend more time waiting for compilation and dealing with language problems than real game dev fun.

Rust doesn't have to be slow, look at the Bevy engine for example

Bevy is the nicest ECS I've tried yet you can prototype something much faster in JS. And prototyping is the fun part.

After 2ys doing rust all I can say is that it is nice as long as you know exactly what you want to do. And you often hit the wall because rust is still very young and there are not many libraries.

And more you know rust and do advanced stuff the more you hit bugs & unfinished things in rust itself. And I can tell you it's really hard to swallow when you need to redo something for the third time just because you are ahead (and nightly doesn't really help, sometimes it just opens another bag of bugs because those new features do not work together)

Try doing some GUI in rust, there's literally nothing complete right now, druid & iced are the most promising ones but still far from production-ready.

Some more fun high level frameworks:

- HaxeFlixel (https://haxeflixel.com/) (Extremely portable)

- Phaser (https://phaser.io/) (HTML5 framework)

- Nico (https://github.com/ftsf/nico) (The PICO-8 API in Nim)

- Pixel Vision 8 (https://pixelvision8.github.io/PixelVision8Website/) (Another fantasy console)

I wrote a video game in pygame. It was fun!

I used it to master how to write a basic video game, without falling into the intricacies of C++ to hack out a video game.

I mastered all the mechanics of 2D video games, similar to the Nintendo and PlayStation games of the 1980s and 1990s.

I finished it in a weekend. Well, I put in 16 hour days, so it was more like a week’s work. Granted, I did have other development experience, but this was my first foray into video games.

I was driven to complete it, when I realized it was possible to actually make money as an independent video games developer. Still difficult, but possible.

I was thinking of turning this into a book or a video tutorial series. It would be helpful to crack the mysteries of game development for the new programmer.

I wonder if anybody would be interested in such a book? Or such knowledge.

> Also, even the general approach for game development--presumably there's some white boarding phase followed by a wireframe phase etc like you have with app dev? What does that look like in game dev land, what are some reasonable tools for hobbyists for each stage, etc?

If you're interested in learning more about this, I can't recommend enough The Art of Game Design: A Book of Lenses. The gist is that it's hard to make an actually fun game by working "from first principles", you need to iterate tens if not hundreds of times just to get a solid game idea down (more subtle aspects like balance may require thousands of iterations). So a lot of the work of a game designer is coming up with ways to iterate extremely fast, e.g. by making a prototype of the game using paper figurines and writing the rules in a google doc.

> it's hard to make an actually fun game

A zillion years ago I used to do hobby games as a solo dev, and it took me a long time to understand this. I was always interested in game engine elements (sprites, tilemaps, input, menus, audio, pathfinding, etc), and I could put those elements together to make halfway decent games (usually by copying existing genres). But assembling those elements is a skill of its own, and this is easy to overlook if you're a programmer who thinks programming is the only challenge to making a game (or making anything :)).

I didn't truly appreciate game design as a skill until I worked with a separate game designer on a project. He made decisions on things that would have never crossed my mind. From that point on, I started seeing game design everywhere. Notably, I started seeing it in older games, ones I had played many times and that inspired me to get into game dev in the first place. I hadn't realized how well thought out the classics were.

It might seem tangential to what you're asking, but I felt I learned more about 2d indie gsme dev from Yahtzee's Dev Diary, than most other resources out there: https://www.escapistmagazine.com/v2/category/yahtzees-dev-di...

You might want to look at bevy, there are some great tutorials available for it: https://bevyengine.org/

ECS is not for beginners who just want to get a quick game out, or anyone who has <500 entities in a scene

I've gotta say though as a beginner, I found ECS more approachable than the Actor/Object systems common in engines. Granted, I do a lot of FP and digesting data, so a series of systems to operate on data is sort of home turf. In the end though, I've been using the traditional OO systems in Unity because most educational resources + documentation are so focused around that

Interesting, the idea of ECS is intuitive to me but actually doing it is kinda hard, mainly because the scope of ECS is kinda vague there're some stuff that you aren't supposed to do with ECS, if you try to do every single aspect of your game in ECS that might result in some messier code. I actually think the Unity way is not bad, it's also a series of components compose an entity, the only difference is not separating data and logic which I found easy to work with and not bad at all.

I contend that ECS is overengineering in any game that isn't an immersive sim. It is certainly overengineering for beginners working on relatively simple 2D games.

Since no one has directly said it, I think bevy hides a significant amount of the ECS from the developer in a really elegant way.

I agree with Weebs assessment as well. But in particular, bevy has an extremely simple ECS api.

(Though, I will admit, I’ve only dabbled in this space and mainly followed some tutorials, so your mileage may vary)

The basic OOP solution relies on mutable aliasing being available, where any entity can reference any other entity.

Rust won't let you have arbitrary mutable aliasing or risk dangling pointers, so you'd end up fighting the language. In Rust ECS is actually easier, and it's a better fit for the single ownership, shared XOR mutable model.

That's also why I don't recommend Rust for game dev beginners, I think the most important thing for beginner is to experience the fun of game dev, which is making game logic and making the actual game, even if you go Rust with ECS, you'll still spend most of the time learning ECS, solving compile errors and waiting compilation, stuff that does not have any game dev fun.

A bunch of other comments threw out the Pico-8 I wanted to recommend the Tic80 as an open source alternative.

https://tic80.com/

I just started playing around with it and honestly, I like it a lot.

I've never used Pico-8 before, but from what I understand the Tic80 is pretty much the same, but with about twice the 'specs' of the pico-8.

The community is a lot smaller, but it'd be awesome to see it get more support.

It gives you a nice integrated environment for code, art, SFX and music, with limitations that make it more likely to avoid feature creep and actually letting a solo dev finish a full game in a reasonable time frame.

Hmmm looks fun.

I'm a mobile app (not game) perspective. For many years, I always want to make cool 3D game like GTA, unfortunately due to it's complexity it's impossible to write such game alone.

Probably I'll learn writing smaller games, instead :D

The thing that's been nice working on the tic80 is being able to work on both my phone and the computer it's kind of a hassle copying the cart back and forth, but it's cool being able to program features on the go.

For 2d gamedev, I recommend raylib, GMS2, or Godot

If I had to pick one, I'd say go with raylib. Free, open source, lightweight, portable, friendly and helpful Discord community, super helpful and friendly and engaged lead dev, bindings to tons of languages, builds for many platforms, straightforward high-level API that is sufficiently documented by a simple cheatsheet, a great set of related gamedev tools taht are also developed and maintained by the same lead dev, and it's just a (C99) library, not an inverted-control framework. So you just have a while loop in main() that checks for whether the window should be closed and lets you do whatever updates in whatever order you want.

If you ultimately develop commercial indie aspirations, you may want to move to GMS2 as it makes it easier to do things like publish to consoles and integrate Steam APIs. Tons of commercial indie hit have been made and continue to be made with GMS2.

Stay away from Unity....2d is a second-class citizen in Unity.

If you're looking for higher-level patterns, this book is great: https://gameprogrammingpatterns.com

I found these two resources helpful when I needed to do some 2d game development in C++.

- [Remaking Cavestory in c++](https://www.youtube.com/playlist?list=PLNOBk_id22bw6LXhrGfhV...)

- [Dive into C++11/14](https://www.youtube.com/playlist?list=PLTEcWGdSiQenl4YRPvSqW...)

This is hard to do in a one-size-fits-all fashion because there's a wide range of 2d techniques, tools, and processes available, depending on a multitude of factors, some example ones being:

- Game genre / mechanics

- Your team size/skill sets/experience

- Game engine

- Target platform(s)

- Monetization strategy

2d games in particular support a wide variety possibilities. If you narrow it down I can more easily point you in the direction of specific helpful resources.

Yeah, I guess I'm thinking "hobbyist", so team size of 1 and no monetization strategy. Simple game engine (preferably in Go or Rust or some similarly approachable language; my hobby time is to precious to be writing C/C++ again), but maybe getting into the nitty gritty of game engine is too low-level for the write-up that I'm thinking about. I don't have a specific idea for a game, but I'd probably like to putz around with top-down tilers a la Pokemon or Zelda.

So, for that, I can easily recommend Godot/GDScript and using Asperite for Pixel art, if that's the aesthetic you're going for.

Godot has a little bit of a learning curve, but easily justifies it. I've made some games in it: https://yumaikas.itch.io/. Godot, for 2D games, for me, has been a force multiplier in terms of what I can get done in X hours. For Hobbyist work, that just means you can take on more ambitious projects without having to do as much groundwork.

Barring that, you could look into bindings in your language of choice to Raylib. I've used a tiny bit of it with Janet via Jaylib.

If Lua or Fennel aren't hateful to you, there's always Love2D, TIC-80, or PICO-8. But, tbh, I really recommend learning Godot.

If you goal is to work on a top down Rpg-style game, as a single developer I would HIGHLY recommend using a tool like RPG Maker (https://www.rpgmakerweb.com/)

Games like Pokemon/Zelda are very content driven and usually don't have any sort of complex systems that require deep access to game engine internals. As someone working solo, you are going to want to spend most of your time creating fun/interesting content. Tools for this genre have been built many times before by people with far more experience building them. If you spend your time rebuilding them yourself, it's a recipe for stalling out without having much to show.

If your goal is really to just have fun building out gameplay systems as a programming challenge, I recommend using a lightweight code-oriented scripting language engine. Some good examples in this space are LÖVE (Lua, https://love2d.org/) or Phaser (Javascript, https://phaser.io/). These will allow you to jump right in to building games without needing to learn a graphical UI and are usually more agnostic about how you build your game than fully featured environments.

If you prefer the latter, but still want to end up with a finished game at the end, I recommend scoping down from an RPG to something like a Sokoban-style puzzler (https://en.wikipedia.org/wiki/Sokoban). Use a tool like Puzzlescript (https://www.puzzlescript.net/) to prototype your mechanics. Once you've finalized your mechanics you can then recreate it in the engine of your choice and add any polish. Having a playable prototype will make it much clearer what systems you will need to build.

Best of luck building!

For me, I'm interested in static typing, ECS-ish, fast feedback loops, and 2D games.

I've used Unity in the past and mostly liked it, but it is infuriating that they haven't fully solved the problem of feedback loops (slow refresh times in the Unity editor with a small project after code changes) given that they're operating in a fully managed context.

The book Game Engine Architecture by Jason Gregory might be more detailed than you'd like, but it still covers a lot of those issues (for both 2D and 3D). As a programmer-but-not-a-game-programmer, I was fascinated to read about the different modules within a game and how they interact. Before reading, if I ever did write a game, I probably would have ignored the "don't write your own engine" advice. Maybe I still would. :-) But at least I have a taste of the awesome amount an engine gives you.

If you can splurge, the GDC Vault has a lot of good talks with devs from every discipline.

The median quality of the talks is a fair bit higher than random blogs. There are some amazing gems and duds too.

Their YouTube channel is an immense resource, and IIRC all their talks are made public after 2 years (many also before that). So there's plenty to listen before you need to pay for the most recent stuff.

This is called "greyboxing" in game dev, where you build functionality (often levels) with plain grey boxes rather than actual art assets to test whether a concept is fun, playable, etc.

They're often not literally grey. You're kit-bashing for form rather than aesthetics. As such you need some ability to differentiate things. Similarly there's a minimum amount of FX feedback and UI you also need to make a game understandable.

I've found the DragonRuby Discord channel to be a great resource: http://discord.dragonruby.org/

There are friendly veterans there who will answer all kinds of game questions (not just about DragonRuby).

As for process, main advice for games is just to get to working prototype ASAP and start playtesting ASAP.

For 2D art https://2dgameartguru.com/ might be good. It started as a set of tutorials for game programmers struggling with making art. It specifically focuses on vector art, and pixel art might be more suitable, for that https://lospec.com/ links to many tutorials.

For game design process Game Design Workshop and Challenges for Game Designers are good books that cover process comprehensively (TLDR is quick concept, prototype, play test, refine).

Reply on news.ycombinator.com