One of the major selling points of making a traditional (ascii) roguelike is that development is all mechanics and programming. I understand that this isn't the current mainstream view of the genre, but its a great approach to making a game by yourself if you don't have much experience with art. Mechanics are also much harder than they appear on the surface, and art, once you're well practiced, is usually pretty straight forward in comparison to programming or game design.
I also understand that on HN games are mostly viewed as commercial opportunities, but if you're asking about basic pixel and game art concepts your art will probably not sell your game. Most roguelikes are hobbyist projects, or at least started as hobbyist projects, and the point of this talk is to foster hobbyist development. If art is a bottleneck, make a good game without art and then partner with an artist.
This is also why telnet MUDs are a great place to dabble in networked games. The lack of art + an easy networking model (no hard stuff like client-side prediction and interpolated animation) and you can spend almost all your time on the fun technical stuff.
For roguelikes IMO the "make or break" part is the world generation and gameplay balance. After all most old-school roguelikes work fine with ASCII symbols so there's no real "art" involved besides arguably the shape of rooms and maybe the colors used. Even those who actually use pixel art tend to have rather primitive sprites, including popular roguelike-likes like FTL or Rimworld.
I think it's one of the reason roguelikes are often so deep gameplay-wise. You want to add a new species of trolls who can fly to your game? Just implement the logic and associate a "T" character or whatever. Want to destroy a wall? Remove the "#". Want to make a lava pit? Display a red "~". You don't have to worry about having to create new models, new textures, new shaders, new sound effects etc...
Meanwhile generating interesting levels and tweaking the Random Number God to make the game interesting and challenging without making it unfairly difficult is pretty tricky.
Good roguelikes have a good mix of human-made "scripted" elements integrated in randomly generated worlds. Too much of the former and the game feels repetitive and predictable. Too much of the latter and the game feels soulless and aimless.
>Good roguelikes have a good mix of human-made "scripted" elements integrated in randomly generated worlds. Too much of the former and the game feels repetitive and predictable. Too much of the latter and the game feels soulless and aimless.
This is great advice that extends well beyond Roguelikes.
>After all most old-school roguelikes work fine with ASCII symbols so there's no real "art" involved besides arguably the shape of rooms and maybe the colors used.
I prefer ASCII in Roguelikes. And while yes, I do enjoy old roguelikes that were very plain, I'll also say that creative use of ASCII, and colors, and ASCII "animations" can make a game much more pleasurable (and if done poorly, much less pleasurable).
Saying there's no real "art" in these ASCII graphics is having a rather limiting view of what art is. Making aesthetic games with ASCII definitely involves art.
The tiled/sprite based Rogues - I never liked them. They always restricted my imagination, and had poor graphics.
The distinction I tend to make when talking about any kind of art fidelity type of thing(whether it's roguelikes or pixel art or lowpoly styles) is that you might not have art, but you still have assets. The procedural world generator: that's an asset. Different types of terrain and traps: those are assets. Stats and abilities: Assets. Special case messages on unusual events: Assets. And so on.
And when you add new assets, you still add some kind of burden to the design. Roguelikes just hit those design challenges much faster than most, since they have a world model that makes it straightforward to get to the part where you have the assets and now they have to be tied together in some sensible way.
Action games have it relatively easier when it comes time to do this design work: You know that the gameplay is mostly going to be about collisions, timers, and finite state. The bandwidth of what can be visualized gives you some hard limits on your design scope. Role-playing, in contrast, can keep piling on details. There's more of a UI/accessibility concern in good role-playing design, something that can produce interesting scenarios without resting on obscure details that the player has to sit there calculating out.
I bet for most folks on HN the mechanics and programming are the easy parts. The art is really what makes or breaks games.
This is true, but from what I've seen the gamedev community seems to generally take this adage too far. At a recent meetup, I spoke to a developer for a project updating a well known IP. Their multiplayer slows down then crashes. I started asking questions, like, do the synchronizing objects have an update cycle? He didn't know, and it had been going on for months.
There's some big fraction of gamedevs who seem to think of programming as almost an afterthought. I see a parallel with the fraction of recent grads who think all they need of programming is the ability to glue libraries together. The medium really needs a balance of multiple abilities. Otherwise, it's like a musician who can write lyrics, but can't sing and play, or someone who has excellent chops on the guitar, but can't sing and write lyrics.
You'll find this anywhere the entry barriers are slowly eroded. I think this is a good thing in most scenarios, because it means people can achieve equal or greater things with even less knowledge.
While it does cause gaps in logic and nobody wants to be supporting a code base in a professional setting that was built with design/architecture as an afterthought, it's still cool that more people than ever can do something like make a website or a game.
> it's still cool that more people than ever can do something like make a website or a game.
I really don't know if it is cool. Seeing the market saturated with mediocre (and worse) creations is more depressing than cool for me. And I feel like it's only lowering the bar, where people can't demand quality and those who create can't put in the effort because there's not enough demand for it.
Any reply likely relies on our assumptions about how we derive quality product from ourselves others.
I can spin a narrative whereby the app store fills up with fart soundboards, but famous artist (or team) is able to practice and later in life make really great app/game/art because they have a fresh, minority perspective. In the alternate narrative, said person (or team) wasn't able to build a portfolio enough for the first rung and pivoted to some other hobby/industry. Presumably we've already formed the assumptions that guide which narrative we value more.
The problem with tons of shovelware, is the particularly deceptive noise in the S/N ratio. The old adage is that you shouldn't hide a needle in a haystack. Instead you should hide it in a pile of other needles. A big problem with particular kinds of shovelware is that under-technically qualified people are able to make something that looks great, and even plays great for the 1st hour. Then the bugs start creeping in.
"it's like a musician who can write lyrics, but can't sing and play, or someone who has excellent chops on the guitar, but can't sing and write lyrics."
That's an interesting observation, because that's how a lot of the music industry works. Lots of songwriters who aren't good at performing, great performers who can't write well, instrumentalists who can't sing etc.
That's an interesting observation, because that's how a lot of the music industry works. Lots of songwriters who aren't good at performing, great performers who can't write well, instrumentalists who can't sing etc.
Right. But in the music industry, most people know if their only strength is singing, they know should team up with people who can handle the instruments and the songwriting.
Some strains of Unity game development seems to be especially susceptible to this kind of slamming together stuff from the asset store without understanding how it works. I've tried a couple times to get into Unity, because it looks like a fabulously productive tool, but I struggle a lot because it feels like there is a lot of slop in how everything works - at least compared to the sense of control you expect when you are used to having to write your own game loop and your own input handling and rendering etc etc.
I tend to wrap, or even refactor purchased assets to suit my needs. In that way it more closely resembles the workflow of collaboration with other developers - they provide a working implementation and you tweak it for your use case. This breaks future asset updates, though, so you need to be sure that you won't need them.
To be honest, the code quality in most assets I encounter is so low that sometimes I even throw away the scripts and only use the meshes/textures/shaders/etc. (I'm looking at you, that-one-very-popular-vfx-pack!)
To be honest, the code quality in most assets I encounter is so low that sometimes I even throw away the scripts and only use the meshes/textures/shaders/etc.
This is some kind of systemic market failure. The general population of the market itself is so low-information that it can't properly distinguish between good and bad. It's pretty much the same problem as non-technical people hiring technical people. It's non-technical people evaluating code.
On every networked game I worked on, there was one guy working on the in-game network code. Nobody else had the faintest idea how it worked, though it was typically fairly well known at least what not to do in order to make his life no more difficult.
(On two of those projects, I was the lead programmer, responsible, in theory, at some level, for all the code that went into the game. And I still couldn't have answered your question.)
Understanding the concepts behind e.g. how tcp/ip works is hard and requires a lot of dedicated effort. I think for those with an engineering/CS background it might be easier, but I can see why game artists or indie gamemakers may not always know these things.
Understanding the concepts behind e.g. how tcp/ip works is hard and requires a lot of dedicated effort.
In the case I cite, it's not TCP/IP at all! It's very generalized systemic thinking. Just picture a diagram with boxes and arrows, and start thinking about how the messages go across and what happens next. I also see a lack of generalized systemic thinking in too many of the high GPA Comp Sci grads I've interviewed at work. (Even to the point where they embarrassingly try to handwave entire fields in CS!)
I can see why game artists or indie gamemakers may not always know these things.
Everyone working on a movie needs to know some cinema/storytelling basics, so they know how the little piece they are working on can best contribute to the overall project. Everyone in a band needs to know stagecraft, so they know how to enhance the presentation and not commit a stagecraft faux pas.
I've seen multiple occasions where gamedevs are shooting themselves in the foot because they can't do basic systemic thinking.
I think perhaps this is a side-effect of the barrier to entry being lowered so far that it's feasible to be a single person game developer, and I think being a single person anything that requires for technical skill and artistic ability is hard, but also easy for an individual to fool themselves about (at least for a time).
I think in most industries where individuals can actually contribute usefully, the industry develops a way to supplement these people and make up for their shortcomings. For example, the talented singler, musician, songwriter, or author will find that if they look around (and are lucky and or actually talented), there are structures in place to help them find the feedback (or additional people to group with) that they need.
Perhaps indie game development just isn't quite to that maturity yet. Then again, the game industry seems both cutthroat and dysfunctional enough that it might take a while before something like this can develop.
> I think perhaps this is a side-effect of the barrier to entry being lowered so far that it's feasible to be a single person game developer, and I think being a single person anything that requires for technical skill and artistic ability is hard, but also easy for an individual to fool themselves about (at least for a time).
It was possible to be a single-person game developer since forever. The first games were made by individuals, and at no point there was a time where a single individual coudln't make a decent game. Of course, that requires knowing what battles to fight - you won't make an AAA shooter yourself, but you _might_ make a fun shooter, or you might make a small AAA-quality level alone.
Where the barrier to entry seems to be lowering is in technical skills per se. Each new generation of tools enables people with less knowledge to take on more ambitious projects. 15 years ago, building a 3D world required some understanding of 3D graphics, today you can slap something in Unity from asset store, not stopping at any point to understand what's going on.
I'm not entirely sure whether I think this is good or bad. So let me put it this way: it's good that more people can make games, and it's easier to learn how to do it. It's bad that this bred a mass influx of shovelware and people who don't want to learn.
> It was possible to be a single-person game developer since forever. The first games were made by individuals, and at no point there was a time where a single individual coudln't make a decent game. Of course, that requires knowing what battles to fight - you won't make an AAA shooter yourself, but you _might_ make a fun shooter, or you might make a small AAA-quality level alone.
Well, I think what it takes to be successful is a function of what the market expects. I believe for a while the market expected AAA quality and the tools to make that deliverable from an individual were lacking. I'm not sure from the late nineties to about 2010, anyone but the most talented could deliver to expectations while working alone.
> it's good that more people can make games, and it's easier to learn how to do it. It's bad that this bred a mass influx of shovelware and people who don't want to learn.
I agree. I think the shovelware is expected, and to some degree (at this point) necessary as a corrective measure on the industry. It's a useful indicator that it's not necessarily as easy as it looks, and offers examples of what not to do.
Also, it's sort of like blogs. Many more people distribute their writing now than before, and that has resulted in a log of crap flooding the internet. Then again, I'm sure at least a few of the people I read regularly either wouldn't write publicly or I wouldn't know about them if internet publishing hadn't lowered the barrier to entry so much.
As for people not wanting to learn, I think a portion of that is just people that haven't learned yet. Some people will put out crap and give up. Others will try to learn what worked and what didn't and try again. That may be crap too, but they are on the right path to eventually putting out something that isn't crap. I think, given the amount of crap we currently see, that's a reason to be optimistic. ;)
I've done pixel art, I'm a professional 3d artist, I can draw sculpt and imitate various styles, tend to work in low detail 3d field (previz) where speed and readability are the top priorities.
my advice for learning art naively (without significant outside help) is imitate and iterate, start by re-making pixel sprites from games.
When making variations on these imitations, think of your art as an information and communication problem, what information are you looking to encode into your asset, what are you trying to convey to the player. enemy power, level behavior so on, try and encode it in the least amount of "noise" and then add in the noise to encode mood, style, other things, see if your original information still reads through.
as for the actual skills of art, there are dozens of tutorials out there for various styles, i'd say just learn to draw a bit, and examine your symbols, your visual grammar. if you draw an eye on a character a specific way all the time, try changing and examining why you do it that way.
I know this is vague information but a lot of artistic ability is just practice * time * good criticism. but even with great skill a lot of artists I've worked with dont think of the purpose of their art in the grand picture of things. you do that and you already have a leg up on the competition!
A strong concept and implementation will overcome art limitations. Just look at the success of Rimworld for example, which has sold over 1m copies - or of course Minecraft (150m copies sold).
As others have said DF is very different than Nethack. Although it is often put in the roguelike category for a variety of reasons, I think of it more as a story generator/doll house than as a game like Nethack. It basically allows you to create a world and then live in that world. You can play in adventure mode, which is somewhat like most roguelikes or you can play in fortress mode which allows you to experience the lives of a group of dwarves as they build a fortress. There is no purpose to the game, so it's basically all up to your imagination. You do whatever you want with no restrictions, but also no real added motivation.
The main thing about DF is that it is full of bugs and/or strange coding artefacts. You need to have a kind of hacker mentality to play it because it's a massive puzzle to figure out how to do anything. It's surprisingly rewarding because you often think, "I wonder if X is possible" and after you hack away for a while you discover that it is. Or after you hack away for a while you discover that something even more wonderful is hiding away in there, the product of some weird unplanned generative properties of the massive game engine.
For me, it's really this latter thing that is most compelling about the game. In Nethack it's said that the developers thought of everything. In DF it's more like the game engine has so much complexity that it has taken on a life of its own. I doubt there is any game that has the depth that DF has, but you have to tease out that depth.
I think the game is well worth playing, though whether or not you will like it depends on a number of things. It is a massive time sink and requires endless fiddling, planning, and grinding. Sometimes it feels like a chore to play. But it is also massively rewarding. It depends a lot on the person.
Dwarf Fortress is more like if you liked Sim City but wished it was more like Nethack. It's quite a different beast, but you should give it a shot if that description sounds good. Also the UI is self-inconsistent and the learning curve is a cliff, so like... expect that going in.
If you haven't played other traditional roguelikes besides Nethack, I'd recommend giving them a shot. Brogue and Shiren The Wanderer are both focused on resource management and exploiting monster/item properties, which you'll have seen some of in Nethack. DCSS is more about streamlined tactical and strategic decision making in a dungeon.
Well, it actually has 3 modes. You can use the third (Legends Mode) to see the entire entity history of your world.
Because it roughly simulates thousands of years of activity and tracks them, you can read about a Human Necromancer, the books he wrote, and his disciples. You can follow the dwarf that killed him, see that he gave up being a poet after his wife and child were killed by Zombax Warfbringer, the bronze colossus, and joined the army before cutting his way through zombies into the tower. Of course, he looted books (his past as a poet) and read them - giving him the secrets of life and death! So whoops he's now a necromancer. Oh well!
Well, it actually has 4 modes. You can use the fourth (Object testing arena) to see who would win a hypothetical fight.
Because it roughly simulates every organ and layer of flesh on every limb of every creature and stores them in a combat log, you can read about how a Dwarven Axelord sliced off the left pinky toe of a Human Necromancer. You can track where that pinky toe flew into the face of another dwarf, distracting him just long enough to be impaled by a skeleton. So whoops now he's bleeding out. Oh well!
For sure. Having experience with a console game interface is a plus. I do, however, recommend the lazy newb pack. Especially since it contains DwarfTherapist, a tool that facilitates seeing the status and job assignments of each dwarf. Also I recommend following a beginner guide for the first couple games... or first several... or first dozen.
It's funny that minecraft sold itself to me because of the graphics, not despite them. I saw a screenshot, and that's all it took. Had it looked like a modern big budget production, wouldn't even have wanted to know what's in the screenshot.
Oops sorry for posting somewhat of a non-sequitur. I'm definitely not a designer (pixel art or otherwise), but Gamasutra often has solid community content and interesting deep dives across game design issues (like in the parent!).
This is true to the point where unless you have a really novel mechanic, it's likely that to build a 2D dungeon game, you probably need a game designer and artist far more than you need a programmer. Look at the number of shipping, cross-platform titles made with GUI-based game maker type tools:
Yup take a look at Nuclear Throne and other really cool indie titles built on tools like that. Also if you're building your own engine it's really easy to get sucked into that than the actual gameplay/development.
As they say: "Help a man to build a game and he'll ship a title, teach a man to build a game engine and he'll never ship anything"
I disagree that art makes or breaks games. I think it's really the design: difficulty balance, right number of mechanics, good progression, clever challenges etc. My most successful game to date was when I copied as closely as possible an existing franchise. Whenever I've tried to strike out with my own ideas I've never come up with a game that's very good at all. It's no wonder that successful indie game devs usually find that success by making a ton of games.
Regarding pixel art I find /r/pixelart on Reddit to be a good source of inspiration. If you want to learn pixelart, study how pixelart pieces you like were put together. Some tutorials are occasionally posted there as well.
DeviantArt used to have a good pixel art community. Don’t know if they still do these days but either way there are a lot of tutorials that have been put up there by pixel artists over time. Find the good ones.
Another option you might consider is to team up with an artist to take care of the artwork. If you find the right person then working together can be a lot of fun.
And start small! Don’t become another victim of feature creep. With fewer art assets and less code to write you can focus on making something that looks and plays great. If your idea is too big then either quality will suffer, or you will never finish it. Make small, good games first. And small, bad games too — it’s a learning experience :)
Make a team with an artist next Ludum Dare game jam and make a pixel art roguelike with very limited scope together.
If by art you mean presentation, then I agree. One of the reasons I love Slay the Spire so much is how darn fluid the card play is; they react in pretty much the exact way I expect them to, and that's no small feat for games. The dev said he spent about two weeks perfecting it, and I believe it.
The recent popular ones (edit: assuming I am reading correctly which games you refer to) are all pretty much spinoff genres that borrow heavily from traditional roguelikes, but break from the classic design attributes in very important ways. Many of them are excellent games, but I don't think it's being nitpicky to distinguish them. Note I make this objection without wanting to wade into the tedious war over terminology.
Dwarf Fortress has support for pixel-art tile sets and it's very easy to use them these days. I've played DF for close to a decade and never spent a significant amount of time looking at the base ASCII graphics.
Art is important, but having a rewarding, fun gameplay loop is more important.
Nailing that in a rogue-like is really, really hard. What does 'rewarding' mean? Your character getting stronger? Your player gaining mastery over the game? How do you square that with perma-death? Do you allow level-scumming? If not, how do you not put the player in an unwinnable position (too frequently)?
I am pretty sure I could learn how to do good pixel art, with a few months of training. I am pretty sure I could not strike gold with a cohesive set of compelling, fun roguelike gameplay mechanics in that period of time. (In the way that games like Dwarf Fortress, Minecraft, Angband, FTL, or Nethack (I despise Nethack) struck gold.)
The emphasis on art in games frequently goes way too far these days. There is frequently a very heavy investment in art assets to a degree that is pointlessly excessive or even actively undermines the quality of game play.
"Less is more"
When cartoons became a well established business and newcomers couldn't compete, some professional artist left the established studios doing things like Bugs Bunny and created Droopy The Dog which had a great deal less animation involved, yet did not fail to tell a story and amuse audiences.
Consider what information actually needs to be conveyed visually. It probably doesn't have to be anywhere near as elaborate as the art in games coming out of more established studios.
There are a ton of great resources that people that have have suggested here but the advice I would give is that, like most things, making games is a communal process so you can focus on what you do well and make some friends that do the other bits.
Could anyone give advice on getting started learning some basic art concepts that are applicable to pixel art / game art?