How to Make a Roguelike
gamasutra.com
gamasutra.com
Could anyone give advice on getting started learning some basic art concepts that are applicable to pixel art / game art?
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.
That said, Chris Hildenbrand's tutorials (http://www.2dgameartguru.com/) have been popular among the HN crowd. There are some good free roguelike tilesets on opengameart.org (Dawnlike is great https://opengameart.org/content/dawnlike-16x16-universal-rog...) and oryxdesignlab.com has some good cheap tilesets. This reddit thread (https://www.reddit.com/r/roguelikedev/comments/436sop/roguel...) is more comprehensive and includes both of those resources.
1. First built with an ascii tileset focusing on very tight mechanics and borrowing everything else from Doom (including sound set, music, setting, and theme). https://github.com/ChaosForge/doomrl + https://en.wikipedia.org/wiki/DRL_(video_game)
2. Then Derek Yu (of Spelunky fame) comes in with a gorgeous tileset that replaces ascii as the default as of drl 0.9.9.6 https://twitter.com/mossmouth/status/806211094960189440?lang...
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.
This is great advice that extends well beyond Roguelikes.
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.
My favorite ASCII roguelike is probably Brogue (available for Mac OS X, Windows and Linux): https://sites.google.com/site/broguegame/
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.
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.
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.
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.
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.
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.
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!)
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 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.)
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 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.
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.
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!
Do you think I could maybe enjoy Dwarf Fortress?!
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.
Honestly though try adventurer mode in DF, it's like LOTR meets Nethack. Or try fortress mode, and have fun! [1]
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.
Only in fortress mode. Dwarf Fortress has two modes, and the second (Adventurer mode) is like an open-world nethack.
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!
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!
See:
Basic pixel art tutorial: http://www.gamasutra.com/blogs/KennethNg/20151211/261577/Pix...
Deep dive into Crawl's pixel art https://www.gamasutra.com/view/news/300004/Game_Design_Deep_...
Another collection of pixel art tips (and examples) https://www.gamasutra.com/view/news/176663/5_tips_for_making...
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"
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.
Quite a few rougelikes use strictly ascii art, kind of negating your point
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.)
"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.
However, seems as you specifically mentioned pixel art, maybe the following are of interest:
https://www.youtube.com/user/achebit/videos
By the way, the author of those tutorial videos is set to release his game (Dungeon League) some time in the next 12 hours, after ~4 years of dev.
My favorite rogue-like, Hoplite, originally came with pretty basic tiles. Then after it took off, newer tiles were made.
The game mechanics were so good though that I'd love that game regardless of whether the art is "great".
I do megaman inspired art by simply cloning the megaman sprite sheets, then modifying things like palette and form.
Do it enough you get good and learning shadowing and other techniques
Yes, it's so much more important than gameplay.
/s
Here is my first result:
https://www.friendlyskies.net/notebook/free-pen-paper-rpg-ga...
It isn't amazing or anything, just a downloadable PDF with rules--but it's mine, I learned how to do it, and I love getting clobbered every time I play. I can also very easily see how to program it should I decide to do so.
[0] With real-time I mean that it is not turn based, unlike most roguelikes. It uses a future event list with time-stamped events that are waiting to happen.
The ship I was assaulting had about thirty people on it, a fairly large crew, but in my first attempt at breaking in, I was able to kill the captain of the ship. This is significant because if the captain is dead, the ship can't flee to an enemy station.
Everybody on the ship had electronic shields and armor, but they were only armed with concussive weapons; a concussive weapon will knock you out, but not deal any permanent damage.
It ended up being a horror movie in space. I'd attach my pod to the ship and board them, drop the glitch trap at my feet, and then get spotted by an enemy. They'd knock me out, pick up my body, and eject me into space, and I'd have to remote-control my pod to pick my body up so that I could board again. But crucially, when the enemy picked me up, the glitch trap disabled their shield! So now I'd board the ship, stalk and skeletonize the poor crewmember who found me last time, and then go get seen by another person so that I could glitch trap my body.
Eventually, people are carrying my unconcious body past like fifteen skeletons of their former crewmates, futilely dumping my body into space in the hopes that they'd be rid of me, and then I'd return to kill again, like the horror monster that just won't die.
When I finally killed everybody on the ship, I took what i came for and left a derelict ship filled with skeletons floating in space forever, and then retired and passed on the acid gun to somebody else.
Heat Signature is a fun game.
So many tricks and traps in this game. Did you ever see that you can throw traps? If you throw a trap, pause, teleport it to you, then use it normally, it comes out with the same velocity as when it was teleported. So you can throw an armed trap, causing it to teleport/crash/acid whoever it hits.
I hadn't tried throwing traps, although I know you can throw everything else; I've definitely done the "assault a room with six people and two weapons; shoot person A, throw weapon at person B, wrench person C, throw wrench at person D, grab a weapon that somebody dropped, shoot E, and throw weapon at F" before. Feels great when it all comes together.
https://www.reddit.com/r/roguelikes/comments/8loa8x/three_ye...
Mentioned in the post, but worth highlighting more.
Simple, but fun :)
The most naive solution (tracing a line to each tile and checking for collision) introduces weird artifacts, like illuminating a single cell 8 tiles away from a window when you're 45 degrees away from the window, that I couldn't persevere through the temptation of getting that perfect.
Then I realized this is just a taste of why all gamedev is hard. Is $GameMechanic going to be more fun implemented like $this or like $that? Well, you can't just git-branch and try both because both options are non-trivial. And it's easy to procrastinate by working on things off the critical path of finishing the game because that is what's hard.
Turns out it involves an impressive amount of visionary power + ability to laser-focus on the Hard Stuff That Matters to build a game. And I'll always respect the super heroes out there that are able to finish one. I suppose it's not so different from writing a book.
You can implement a solution like that in a few hours and move on. And that's how it tends to work as an experienced game dev: you don't commit to any "real solution" until at least the second go-round, cause you need the context of the whole design to do it properly anyway.
Maybe your LoS algorithm sucks with 1x1 columns and windows, so decide your game doesn't need them and you move on.
Kind of like how the classic mistake you hear about among gamedevs is that they built a game engine instead of the game, basically the end result of constantly following the siren's call of "I'll just generalize this."
I really like this viewpoint. The awesome thing about a game (and a roguelike in particular)is that YOU generate all the data your algorithms operate on. I'd take your solution a step further. If LoS is the thing holding you back... don't put ANY walls or LoS blocking terrain in your game. What would a roguelike look like without walls? Would it be any fun to play? Maybe you'd have to make it set on the high seas or in space to justify not having walls or LoS blockers.
Typically walls are used in a game to limit the players movement, limit information, and provide meaningful choices in terms of where to go next. Keeping in line with the LoS theme, you need some sort of gameplay mechanic to fulfill those criteria without forcing you to code a sophisticated LoS algorithm. Wind, current, and fog could fulfill those criteria without having to code any LoS beyond fog of war.
Line of sight would be a fantastic Ludum Dare theme!
Or you just don’t commit to a “real solution” ever. Nothing is more permanent than ‘temporary.’ =P
Aside from the fun problems the rest of that industry can die in a fire. The basic business model is to prey on people's passion so that they pour themselves into the job for 3-5 years and then burn out leaving open a slot for the next poor soul who signs up. There's an occasional studio that has a sane workload but I'd hazard they're less than 3% of the industry. Plus they usually are gone in 5-7 years when the market shifts(10% of the market captures 90% of the sales).
Building stuff in your spare time is the only sane way to spend time in that space as far as I'm concerned, otherwise you're setting yourself up for a world of pain.
Fellow ex-gamedev confirmed. :P
I ended up in robotics / industrial automation. Many of the same challenges without the issues. Plus, giant robots! Like, real ones.
One resource I used was: http://roguebasin.roguelikedevelopment.org/index.php?title=C...
Check out recursive shadow-casting. Had the best results of all the implementations I tried.
I feel like everything is easy, until it isnt.
CSS is easy, until you have one tiny annoyance on a front page feature.
Embedded is easy, until you need to buy a component that works only 99% of the time.
Full Stack is easy until you finally connect the front end and backend's auth.
Automation is easy until there is an update and it breaks your program.
All of this stuff is preventable with time/effort, but someone needs to do it.
There is a reason that I've started multiplying my estimates by 3, then by another 3 because getting a working system is good, but getting a perfect system is necessary.