ilreh

Members
  • Content count

    63
  • Joined

  • Last visited

Community Reputation

293 Neutral

About ilreh

  • Rank
    Member
  1. Although there's quite a bit of good info on pixel-art specifically on the internet, truth is that making pixel-art is not fundamentally different from doing any other picture-based art. If you're having trouble with palettes and shading you probably don't need help with pixel-art but with color theory in general. For an artist, pixel-art is just like painting but with a fat, square brush that you have to place on a grid-layout, comparable maybe to making mosaics. I'd suggest investing in some books rather than looking for quick breakdowns. Palettes are usually made from mood-setting artworks that were painted beforehand.   Don't forget that, altough SNES graphics contain little information and may look simple, they were made by professional artists.
  2. Crisp 2D art and resolution

    Thanks for your advice. It's going to be primarily a desktop-game but it should also work on mobile devices. The game itself uses pixel-graphics but I thought maybe doing the basic outline of art-assets in a vector-based program (before working out the details in Photoshop) will help optimizing graphics for each resolution. The more I think about it "fluid" scalability and crisp 2D graphics seem to not match very well unless as you said, one can handle the downsides of engine-filtering. If the displayquality of 2D pixel-graphics have a high priority, I think there's hardly a way around determining exactly what resolutions will be supported and then putting some extra handwork in optimzing.
  3. In yet another attempt to creating art-assets I'm not quite sure about the underlying technique. The game is a 2D game that is being built using opengl and textured quads. The screen resolution of this game can vary and this causes me lots of headache.   Should I base my graphics on vectorgraphics due to scalability? I could then give every resolution the appropriate texture, making it all look crisp. Should I base my graphics on large Photoshop files? I could downscale them all, however lower resolutions will require some bit of optimizing Or should I assume one "standard" resolution and simply let the opengl-filtering doing all the filtering (probably bad looking)?   Any suggestions or examples would be appreciated.
  4. Icebone1000 basically said it all, however I kind disagree on the school-argument (if you really want to and can afford it, go to a school). To answer your question: as a rule of thumb, it takes around 5 years of constant use (at least 5 hours every weekday) of a skill to be on a professional/useful level (some degree of talent required). I just want to emphasize how difficult it is to basically become a master in at least 2 high professions (don't forget audio, finance and management,...) and use both skills (programming and art) in a steady workflow (in order not to become rusty in one of them). Becoming a one-man sophisticated dev-studio is only possible by pure maths/theory. In practice nobody would dedicate his entire life (and by entire life I don't mean following a profession for all the time but literally ignoring a work-life-balance and neglecting relationships, family,... to transform your human being into a code-and-art-machine) for just one type of job that's not particularly known for stability / chances of getting it. Nowadays there are options though to make up for lack of practice (besides money/hiring). If you're an artsy type of guy but lack the muscle-memory you can try to design some new game-type around your particular way of composing or as pointed out already keep it minimal. Keep in mind that by taking such "shortcuts" your creative options are very limited but maybe it's worth a shot or two.
  5. The most simple, effective and free solution is rdiff-backup (linux solution based on rsync but via network you can backup your whole windows office). You simply tell it which files/folders to backup and it creates a full-backup if first started and then only patches/diffs for each file (with a command you can also make full backups afterwards like for example every week). You can easily at any time recreate any version of any file/folder (simply by providing date+time with a command). It's also pretty fast. Just get a cheap linux box (if you don't have one already) with big hdds, hook it up to the network, write the command with folders and files in a shellscript and add an entry to crontab for automated backups and you're set. All diffs are stored in a folder in the to-backup folder in a readable, timestamped format so it's also easy to find the right version.
  6. Unworkable project

      I really wouldn't do that. The outcome (the codebase) is primarily the result of management that has absolutely no clue about what's going on. The only reason why it's still ongoing is probably because there's one guy that's been here for ages and knows all the hidden screws under it all that keep things running. So that guy is able to satisfy management even though the product is crap.   So the combination of clueless management and one guy (or some guys) that can satisfy management will very likely lead to give the new guy the "always complaining but not delivering" stigma if he tries to make management understand how bad it is.   The only advice that I can give the OP is to compare pros and cons. If the codebase is a nightmare but everything else is awesome (payment, climate, flexible times, boss,...) then it might be worth it. If the other things aren't too sweet either I'd really consider looking for another job. There's little you can do to help this situation.
  7.   My best guess is that he just dug out his old game, polished it up and published it with some marketing around it. I guess many of us here have some decade-old games/hacks using old libraries lurking around somewhere on backups of backups. Because if you think about it the reasons he gives why it took so long don't make any sense:   1. consistent lighting: It would appear plausible if he made an isometric game with 6 walking-frames in every sky direction and a detailed color palette but how can making sprites using a like 10-color palette in a 2d-platformer with 2 shading-patterns be a justification to expand it to 13 years? That's obviously bull. Also "bigger characters means bigger levels". It's just the other way around, bigger characters make smaller levels. A probably valid interpretation would be that starting with making "big" characters resulted in having to turn up resolution and make everything more detailed (to implement a big level) but 1. it really didn't come across this way and 2. the difference in his game is very limited since he uses only a few colors and simple artstyle.   2. albatross: this is no reason why it took long at all. A "psychological burden" that tells you not to give up and follow through because you already spent so much effort into it is actually a reason to finish it faster and/or at all to get rid of it.   3. the points "Ambition" and "Always sticking to the plan" are contradictionary. Once he said he was constantly hopping to a new idea/puzzle and then suddenly he always sticked to a plan?   Also: he said that watching LOTR inspired him to make this game. The premiere was on 19th december 2001. So even if he watched the premiere and started working on it right away it, there were only 12 days in 2001 and in all it were 12 years and 5 months. (also: "a game with story. a game as epic as destruction carnival" - destruction carnival is an arena shooter with zero story).   However disguising advertisment as "educational video" is a pretty smart move.
  8. What do you think of the agile method?

    When I worked at a project with my colleagues back at school we did "agile programming" without knowing it. We basically tried out new things all the time, implemented every new idea, set up weekly meetings and couldn't really decide who is in charge. Now that this procedure actually became a thing people want to encourage and implement worries me.   I worked in an environment that tried to apply agile. So what we got was a huge pile of code with lots of remains of former approaches that (understandingly) nobody dares to touch because it might break something. After every new change some other feature didn't work anymore so we worked a lot on making work what's already there with those new requirement (which came in all the time). Literally nobody in the company knew exactly what this stuff does and there was no documentation or even sane naming of code-components (of course if a feature gets re-branded on a weekly basis it reflects in code and nodody remembers or can make sense of changes of each iteration).   However (not software or even tech-savvy-) management didn't care because they asked for a feature and got it in a short period of time. They didn't know nor understand that this made parts of the codebase unmanagable and that feature x and y didn't work anymore since nobody tests thoroughly (how could they? Deadlines are ridiculously short and once it's "done", there's the next requirement). And if it comes up: oh well, guess I just found another bug. We actually had a lot of inside jokes that came up just by looking closely to all of these functions and that ridiculous amount of unnecessary or even unpurposeful loops.   Deadlines were always set and treated as important yet almost every deadline was exceeded and this became mutually accepted.   So does this mean that agile is bad? Even though it was bad in this case I wouldn't necessarily say it's bad. It worked very well back in the school project. Why? Because back then it was used as a kind of prototyping just to so see what we can do. There was one fixed deadline and once we got closer to the deadline we stopped implementing those crazy ideas and began documenting. However in that company it became a vicious never-ending circle of bad code.
  9. I would try to avoid "permissions" that are loosely verbalized. Depending on where you live there is an automatic copyright on everything people make so by default others cannot do much with it. Also depending on where you live loosely verbalized permissions can be treated as invalid if they don't meet judicial requirements like being specific enough. The combination of those two things could theoretically lead you to problems in case of a lawsuit. Better use things that are published under one of those open licenses since they are usually made with a lawyer.   This is not a likely scenario (why would someone sue someone if they don't mind?) but better safe than sorry.
  10. I know I sound like an ass but for a game that's been made for 13 years I'd expect something else than Henry's House with upgraded graphics and sound.
  11. How to stay motivated in learning?

    As you figured out correctly, C++ is not a good language for a beginner. I'd suggest starting with C first. C++ is a superset of C and has many implementations and exceptions that just confuse you (you need some experience to know when to apply what and how). Also having a solid understanding of C is a very rewarding skill that many programmers nowadays lack.    As for pointers: it's enough to know what they do and how to pass them around at the moment. I also had troubles understanding them until I had to implement certain things that required them or were much smarter solved using them. Don't bother too much, you will appreciate and understand them soon enough on the go.
  12. Best Way to Learn Assets Design at First Attempt

    It might be useful for finding out what assets you want to make but it's actually important for making good art at all. If you ever took a drawing lesson, you will be taught to think about the man you want to draw as a series of shapes. You don't start from drawing a fleshwound inflicted from a laser gun and work outwards. If you make e.g. a grass texture, make it with 3 shades of green first and see if it looks right. Implement it and see if it fits when another sprite walks on it. That way you will know how much contrast it needs (if contrast on grass tiles is too high, characters somehow blend in with it and are less striking or it can look higher/wilder or lower than intented just by using different colors for shades).   The outwards-to-inwards rule can be applied to everything visual art related.
  13. Best Way to Learn Assets Design at First Attempt

    There's one very important rule for making visual game assets: work from outwards to inwards. Don't make one asset "perfectly" before moving to the next one but leave it in "outer shape"-state before making the next one. If you are for example making an animated sprite and add details and shading on every frame right away it will be very tedious to alter movements or outfit changes. Instead get the whole set done with basic color, add details once you're satisfied with the movement (of course you can finish one frame as a reference like "I want them all to look like this").   This also applies to models/textures etc. What makes a "style" of a game are many assets that _combined_ deliver some kind of experience. Take out your magnifier out once you have a bunch of raw assets and enough to get into the flow of your game. You can create a masterpiece of a model/sprite - if it doesn't fit the overall gaming experience it sucks.   This increases both speed and quality.
  14. For those looking for a "major" DRM free example

      It doesn't seem to make much of a difference if you bought/got the game via the steam platform in the first place. But nowadays they sell boxed games in stores that basically just contain a steam installer and some splashscreens but no game. Just taking the game to a LAN environment, installing it to several PCs and having some fun doesn't seem to be appealing to the audience anymore.
  15. For those looking for a "major" DRM free example

      This is not what I wrote. I wrote that you don't have the option to run it legit without using steam.