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.
I can't recommended starting with a paper & pencil game highly enough. I did this myself recently and _actually got somewhere_, in contrast to the many times I had started with the computer programming part.
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.
Writing a small roguelike is the task that I use to learn/test new languages. Mine is a very simple one: you can just move the player and open doors and there are some monsters running around. But it uses bitmap graphics and things are moving in real-time [0], so it's an example covering some interesting aspects of a language and its libraries (and IDE).
[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.
My current gaming passion is Heat Signature, which is a "rogue-lite" along the lines of FTL, which was my previous gaming passion. Both of those replace the roguelike turn based mechanic with a "hit space to pause" mechanic which also lets you set up awesome combos.
Tom Francis (the heat sig developer) also made Gunpoint, which while not a rogue like is still a fantastic little game (and has a bunch of user built levels). Would highly recommend.
Just watched the trailer for it: that game looks outrageously, supernaturally fun, which is why there is no way in hell I'm going to buy it. I'd have no self control.
One time, I was playing Heat Signature and I was doing the final mission for a character (Characters have personal missions they can accomplish, which are much harder than normal missions and can give you special rewards). I had two useful weapons: an acid gun that would kill enemies by burning the flesh from their bones, and something called a Glitch Trap. You can place glitch traps at your feet, and if any enemies walk over them, it will disable any electronics they're carrying; this means that their shields will be disabled, and they won't be able to call for help on the radio.
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.
That's a crash trap. But if you were to have a glitch trap, that would be funny. A glitch trap teleports the person carrying you, probably into space to die, leaving you behind. Then you could go get the next one.
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.
There is a good, supportive community at https://www.reddit.com/r/roguelikedev with lots of links to libtcod tutorials. I love playing roguelikes, and although my attempts to make them have only gotten to the "move @ around the (non-procedurally generated) map" stage, I like reading posts there.
I'm one of the volunteer organizers of the Roguelike Celebration <https://roguelike.club/> where Josh Ge gave this talk. Thanks Josh for making it to the conference! For other readers, you might want to visit the conference website and stay in touch for updates about next year's event! :)
There is t-engine[1]. Ultimately, though, there's not so much that an engine can offer to a roguelike. Many use libraries such as SDL, bearlibterminal[2], or tcod for graphics, but aside from that most things are hand-rolled.
I started building grid-based ASCII-art roguelikes thinking it would be an easy way to enter gamedev. Next thing I know I've spent all my allocated freetime over many weeks trying to implement a good line-of-sight/fog-of-war!
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.
Of course, the original Rogue game had an elegant design solution: Rooms are fully visible when you enter them. Passages have a simple distance fog. Some rooms are marked "dark" and also use distance fog. And you can only shoot in the same directions you move in so there is no raycasting needed for projectiles either.
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.
That's a good example too of how the best option for a game (which is supposed to be fun) can amount to a hand-tuned game-specific solution despite the temptation I think most of us have as developers to come up with generalized solutions.
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."
>Maybe your LoS algorithm sucks with 1x1 columns and windows, so decide your game doesn't need them and you move on.
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.
Because it's two disciplines. The moment you have to decide wether to "generalize this" or not, you are a game designer, not a coder anymore. Completely different headspace. So, path of least resistance is to continue coding aka "I'll just generalize this."
Yeah, that's why I loved that industry. A million hard problems to solve. Along that lines Real Time Collusion Detection[1] is solid gold for a lot of these types of spatial issues. It's basically data structures for gamedev.
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.
> 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.
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.
When it comes to exact interactions with tile edges and measurements, you might want to take a look at the D&D 3.5 player's handbook (or Pathfinder, which is a derivative of it). The combat rules have a ton of thought put into line of effect and line of sight measurement, how to measure circular radii in squares, how things interact with multi-square creatures, etc.
> this is just a taste of why all gamedev is hard.
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.
Could anyone give advice on getting started learning some basic art concepts that are applicable to pixel art / game art?