Popular Content

Showing content with the highest reputation since 07/21/17 in all areas

  1. 8 points
    Nope. If you are a good software developer or a good artist, you can go a long way without really caring about games. Knowing more about games will help, certainly. And you can't get away without knowing about games technology. And I'd certainly argue that it's important for designers to have a broader understanding of the field. But they are only one part of the development process. You don't. You have to choose. It's a sad fact, but there are just not enough hours in the day. If you want to spend 8hours a day or more on MMO raids or whatever then that is a fun hobby to have, but throw in a day job as well and you simply do not have enough time to teach yourself enough to get good at making games. Play fewer games, play shorter game sessions, and prioritise what is important to you.
  2. 8 points
    Take the following post as coming in semi-moderator capacity; I hope there is something useful in it, but this is not going to be the start of a lengthy debate over something that we have been over time and time again. First, this is not the place to complain about what other people are interested in or not. The forum is called "game design and theory", and you're welcome to discuss those topics. It's also not the place for blatant hyperbole - you say "not a single person has said a single word too me about any of it" and yet there are over 70 comments on your blog. Most likely you are just not willing to hear what people have said to you. What I don't think you appreciate is that you have spent thousands of words talking around your concept, but hardly any time talking about what it actually is. Not 'what it means for games', not 'how important it is', not 'how everything could change if this existed'. You keep asserting that it's important, but you have not proven or demonstrated it in any way. You don't need a degree from Devry. You don't need to write 500 pages about it. You just need to communicate your idea clearly in such a way that you can demonstrate that it will do what you need it to do. Stop talking down to people and saying they are "so far behind actual simulation design" - learn to communicate better. You don't build interest by repeatedly insisting that people should be interested and insulting them when this doesn't change. When a startup wants to get interest from investors, they will create very short and very effective descriptions of what exactly their product or service is, and how it will deliver benefits to users/players/the market/whatever. It should be possible to communicate all the benefits in about 10 pages of Powerpoint at most, and about one sentence at best. They don't expect people to read 500 pages of blogs and neither should you. Alternatively, you can do what most other game designers with a 'big' idea do; make a prototype yourself. If the idea is as good as you say it is, the prototype will prove that, and you'll get interest and funding. If it's not, you won't.
  3. 7 points
    >>What do I have to do to finally be seen as at least the equal of someone with almost no experience, and even less knowledge? Build a portfolio, apply for jobs and go to interviews, like all the rest of the people do. Btw, I again remind you that, when you were talking about your sports mod and how good you are at designing those kind of games, I offered you my services as a programmer in order to make a prototype together(I was interested in making a sports game myself back then). Sure, we weren't going to make an AAA sports game, but we would have an awesome(if your word was true) playable prototype that we both could showcase. You declined, because your grand designs can only be made with multi-million teams and anything else is beneath you. So I went on my way, worked on my indie game, now have a job at EA DICE. Not as a designer, as a programmer, but I work with designers every day, making the tools they use to make AAA multi-million games. See, you *could* have a connection there today, but you don't accept anything less than people bowing down to you and handing you 100 million. So there's that too.
  4. 7 points
    I advise you to not aim to learn "everything" (in Unreal or other technologies), as it can be a futile endeavor and lead to frustration because of the huge ammount of content. Instead, aim to learn what you need to build your ideas (and most of the time it's much less than "everything"). Unreal has a steep learning curve, so it's good to break the learning in manageable chunks. Anyway, Unreal site has a ton of learning resources, so it's a good starting point. They also have a Youtube channel, so check it out and see if it helps. Other than that, you could check online courses such as this on Udemy . I'm doing it, and liking so far.
  5. 6 points
    You're approaching this way too pragmatically and from the wrong direction. If you want to be a level designer, start designing levels. When you gain experience you might discover that in order to add this cool new feature to your levels you need some coding. Then learn coding. It is never the correct approach to mathematically define what you think they want to see. The correct approach is to make what you enjoy making and get a job based off the things you enjoyed creating. If you can't get hired based off what you enjoyed making then you are in the wrong field and you saved yourself from a life of hell. If you aren't motivated enough to create lots of things for a portfolio then you are in the wrong field and you saved yourself from a life of hell. This is just a more direct way of saying what jpetrie said. We can't give you direct answers because the only correct answer is whatever you want to do. How are we supposed to answer your last question? If you are interested in making beautiful levels, and functional levels, why do you need to be told which one to do? You're just going to do them both anyway because you enjoy doing them both, right? If you don't like one or the other, why should we tell you to do what you might not enjoy doing? Careers must always be based off doing what you love. If you want to make pretty backgrounds, do it and apply at companies that want pretty backgrounds (fighting games, racing games, RTS games, RPG's, etc.) If you want to make functional backgrounds, do it and apply at companies that want functional backgrounds (FPS games, 3D action games, RPG's, etc.) Or you can do both, whatever. It's entirely your choice. L. Spiro
  6. 6 points
    The component system outlined on the T-Machine blog is a mish-mash of hating object-oriented programming, love for relational databases, and then an attempt to wedge in cache-coherency - don't expect to follow those articles and get anything elegant out of them. If you want to worry about having contiguous data then the data access pattern cannot be waved away or ignored. Whether you benefit or suffer from interleaving different component types will depend entirely on how you intend to access them. Data locality is about read patterns, not semantics; know your read pattern, then you can decide. The names we assign to that data like 'position' or 'physics' are entirely arbitrary and the cache doesn't care. 30000 entities is going to stress any system if they are non-trivial, anyway. In my opinion, the real benefits from component-based approaches are in modularity and in providing a composition-based approach to implementing functionality. Much of the recent emphasis on being data-oriented and cache-coherent is missing the point and overcomplicating software for little real benefit. Note that the Randy Gaul article you linked stresses modularity first and only mentions cache coherence as an optimisation. That is exactly the method I would use; first implement components to suit my gameplay, then attempt to find ways to locate them in memory to reduce cache misses.
  7. 6 points
    Medieval Story has finally been released on Steam (wohooo!). Many late nights and evenings have been put into making Medieval Story. All graphics, sounds, maps, programming, scripting, GUI, music, AI, dialogue writing, modelling and what not has finally come together into this small game with about 8-15 hours of gameplay time. It feels quite bizarre thinking of all the hours that have been put into the game over the years and then reading reviews about it. Sadly some people seem to have had quite high expectations, pointing out infantile (?) dialogue, horrible controls and bad characters. I don’t know… Never fun to read criticism when it is sort of rude. If you consider buying the game I hope you enjoy it for what it is; a one man game project developed in spare time. http://store.steampowered.com/app/543740/Medieval_Story/ Thanks for reading!
  8. 6 points
    Ok, so I didn't really want to engage with this, as I feel it's likely to be a waste of time... My prediction is that you're just going to dismiss the following as us not having the frame of reference to understand your brilliance or something, but here goes... I played Armageddon Chess. I was curious when you published something that actually looked like a playable game, so I arranged to take it to our local gaming store, and a group of 7 of us made up 3 sets and gave it a few tries. All are avid tabletop and board game players. Four like video games as well, three almost never touch them. Two have actually tried SFB, although admittedly one wasn't a fan and only ever tried one introductory game. It's actually playable, and the rules weren't too badly described, although as we were making our sets before play and piecing it together as we go it was a bit cumbersome to figure out. Not one of us enjoyed it. You took the elegance of chess and added tedious combat rules and book keeping, and the we justc didn't find it fun. You shared a massive "design document" for Pirate Dawn" 10 years ago, and several people here actually tried to read it, but it was an unstructured and disorganosed typo-riddled mess; unfortunately you wouldn't accept that that was your problem, declaring that 'our industry just don't understand proper detailed design documents'. You actually have one video game design credit for Sinistar Unleashed. It wasn't received very well, and the reviews I can find almost universally claim that it was aesthetically beautiful but that the gameplay was terrible. Apparently you worked on a football mod that was popular, but noone remembers it, and in all my searching all I can find about it other than an old discussion here where you claim it was great (noone else remembered it then either) is two dead links You keep talking about being in the SFB staff, but according to your own earlier posts you didn't actually design the game, you were just an avid core player with a deep understanding of the rules who was asked to contribute to the strategy manual. That doesn't have no value, but nor is it particularly compelling design experience. Your writing is verbose, poorly structured, and seems to talk around a point you never actually make. It's filled with boasting about your design and old table top games and scorn for 'the industry' but startlingly devoid of actual meaning, although you claim that's because we just couldn't possibly have a frame of reference to understand it. So no, you simply haven't actually done anything to demonstrate your supposedly amazing skills.
  9. 6 points
    http://www.psa.es/sdg/sunpos.htm The function will take your time of day as well as location on earth (specified as a latitude/longitude coordinate pair), and give you the direction of the sun in spherical coordinates.
  10. 6 points
    I would not advise learning C++ in the context of Unreal. The way you write C++ for Unreal is different enough from the way one writes "pure" C++ that learning it first may warp your understanding of what is something you do in C++ versus something you do in Unreal; for example, Unreal has a garbage collector implementation and an invasive macro-and-preparsing-based reflection system. I'd recommend you focus your Unreal learning on Blueprints. If you want and feel capable of also learning C++ at the same time, spend some time working with it outside of Unreal, by writing some simple text-mode games in Visual Studio or whatever IDE you prefer. Guess-the-number games, Hangman or Blackjack are good basic games to try building in that fashion.
  11. 6 points
    Bytes are well documented. Do a Google/Wikipedia search for definitions before you ask, so that your questions can be more specific. A byte is an amount of storage 8 bits of data (at least in every situation you will ever encounter). Therefore it is broadly equivalent to the 'u8' type you're working with. All data transmitted or stored is essentially sending bytes back and forth. The computer programs at each end then decide how to interpret those bytes - for example, 1 byte on its own might be a 'u8', 4 bytes in a row might be considered an 'int', 8 bytes might be a 64 bit pointer, and so on. When understanding what is meant by "high byte first" you need to understand how numbers are encoded in binary. (Read this paragraph, then read this - https://en.wikipedia.org/wiki/Binary_number#Counting_in_binary) When we write a number in decimal, we write the 'high digit first', so 145 is one hundred, four tens, and five ones. A hundred is the 'high' amount, and the ones are the low amount. Binary doesn't use digits from 0 to 9 like decimal does - it uses digits from 0 to 1. (Binary digits are "bits".) This means that instead of each column signifying ones, tens, hundreds, thousands, etc, each column signifies ones, twos, fours, eights, sixteens, etc. Each byte has 8 'columns' of binary digits, i.e. 8 bits, and when we send the 'high byte' first, we're sending the byte with the largest column values first in the list. Because a byte is just 8 bits, it tells us nothing about what sort of information it is meant to carry. This is why 2 networked programs need to know what to expect - so if you're sending an int, you need to know to expect 4 bytes and what order they're going to arrive in. If you want to send a string, you need to know what format it takes - some systems send an int to mark the length followed by each byte in the text, and some systems send each byte in the text and a delimiter (i.e. what you call "a line break or something"). Both ways exist and are used. And a 'short' is usually a 16-bit value of 2 bytes. Scan this list - https://en.wikipedia.org/wiki/C_data_types - but be aware that type names can vary from language to language, and sometimes from platform to platform. e.g. an 'int' is usually 32 bits on a 32-bit operating system and 64 bits on a 64-bit operating system. I would warn you that if you're not yet familiar with 90% of this stuff then trying to do low level networking between 2 different languages is going to be very tricky. You might want to keep practising with just 1 language first.
  12. 5 points
    If you interpolate the RGB values of two complementary colours you will go through a neutral region of the RGB space. The middle of your gradient will be "grey". There are other ways of interpolating colours, like interpolating the parameters of your two colours while in the L*a*b* or HSL space. Use this tool for some previews: http://davidjohnstone.net/pages/lch-lab-colour-gradient-picker
  13. 5 points
    If Z-fighting is an issue, then yeah I'd definitely recommend doing this. Make sure you're using a 32_FLOAT depth format. Swap the near/far params of your projection matrix creation code (e.g. instead of Projection(fov, aspect, near, far), use Projection(fov, aspect, far, near)). Swap your depth comparison function (e.g. replace LESS_EQUAL with GREATER_EQUAL). If you have any shaders that read the depth buffer (e.g. deferred lighting reconstructing positions from depth), then fix the bugs that this has introduced to that code). [edit] Clear your depth buffer to 0.0f instead of 1.0f. [/edit] The link I posted earlier explains why this is magic. But quickly -- z-buffers store z/w, which is a hyperbolic curve that focuses most precision on values that are close to the near plane (something like 50% of your depth buffer values cover the range of (near, 2*near]!!), and floating point formats do a similar thing -- they're a logarithmic format that focuses most precision on values that are close to zero. If you simply use floating point format to store z/w, you make the problem twice as bad -- you've got two different encodings that both focus on making sure that values next to the near plane are perfect, and do a bad job of values next to the far plane... So if you invert one of the encodings (by mapping the far plane to zero), then you've now go two encodings that are fighting against each other -- the z/w hyperbolic curve is fighting to focus precision towards the near plane, and the floating point logarithmic curve is fighting to focus precision towards 0.0f (which we've mapped to the far plane). The result is that you end up with an almost linear distribution of values between near and far, and great precision at every distance.
  14. 5 points
    It is an expected behaviour, with VSM (and any other related techniques) you have to render both the occluders and the receivers into the shadow map. If you think about it, when you blur the VSM without the receivers in it (or even if you just sample that map with proper texture filtering), you blur between the occluder depths, and the maximum z value, meaning that the blurred values will strongly tend towards the max z. Tending towards max z also means that the blurred values will be "behind" the receiver pretty quickly, and that messes up the whole thing. (This explanation is exactly mathematically precise, but hopefully it's enough to illustrate the problem.)
  15. 5 points
    I said I was done, but since you're addressing me directly, I'll do you the courtesy of responding. "Rube doesn't qualify me as a game designer in your eyes". Correct. Because it's not a game, it's a long series of vague blog posts. There may be other things you've made which qualify you as a game designer, but I've not seen them. "40 years of experience doesn't either" Experience of what? And for what? 40 years of board game design experience, if you have it, is useful, but it wouldn't qualify you to come to my company and tell us what game to start making. That's not how the process works. It might qualify you to come in at mid-level providing you were able to show some capability with digital design tools, and a willingness to engage with our existing processes. "you'll hire a 22-year-old in a heartbeat". If they have relevant skills for the role we need, sure. They, too, would not be coming in to the company telling us what game to make. They'd probably be given a copy of the Unreal Engine and asked to start blocking out greybox levels for whatever game we're already working on, or asked to tweak vehicle handling parameters, or told to design some low-level kill-10-rat style quests. "I just want to make games." So make them. Unity. Unreal. GameMaker. Stencyl. Godot. There are tons of cheap or free tools out there and you can get started today. "What do I have to do to finally be seen as at least the equal of someone with almost no experience, and even less knowledge?" You have to do the same that anyone else would have to do - make something to prove your capabilities. Nobody hires on the basis of blog posts or repeated insistence. The burden of proof is on you. You also have to learn to communicate better and to be more of a team player. Nobody hires someone who comes to them and says, "your industry is full of idiots who don't understand that I am the top person in this field". Who'd want to work with someone that sounds so arrogant? If you truly are at the top of your field, you wouldn't need to state it; it would be obvious from your work.
  16. 5 points
    I didn't ask whether you had any private notes, I asked whether you had anything concrete that you were willing to share with others. I'm an engineer, I use tools to build things. If you don't give me a tool to use, then I can't use it... If I can't use it, why would I care about it? In your first post in this thread you ask why no one wants your magic technology. I answered that -- if you are keeping it a secret, then it's not possible for us to even begin to care. As for turns vs impulses, etc, we talked about this in one of your previous threads. Event-based simulation using timelines instead of turns was covered in my 1st year data structures class at University. The other part of your problem is that you don't know what everyone else has been doing for the past 70 years, so you're not qualified to tell us what we do and don't know. Maybe there's practical reasons why people choose to use one over the other? Big projects involve hundreds or thousands of trade-offs between different technology choices, often based on mundane practical reasons. The structures used by your secret magical tech may well have been considered by a lot of games over the years, may have been used, may have been discounted for practical reasons. You simply don't know. And you'll never know if you insist on just rambling about what some secret magical system does for you, instead of actually sitting down to do the work to tell us what it is. If you have nothing to share with us, then it doesn't matter what you have. To us, it doesn't exist. So for all practical purposes, your tech does not exist right now. Stop being lazy. Do the work required to make it exist to us, or you'll die alone without ever having left behind a legacy that anyone cares about.
  17. 5 points
    CS degrees have remarkably little to do with working as a software developer. Provided you have strong programming skills, and pick up the CS basics on your own (the various containers, algorithms, big-O complexity analysis), the CS degree is just a way to make sure your resume stays in the stack (rather than ending up in the shredder). Personal contacts, a strong portfolio... those should accomplish the same end (and possibly considerably more).
  18. 5 points
    C++ has the potential for better performance. You can try to write perfect code or you can write code that is good enough to get the job done. I would suggest the latter. My point is...choose whatever language you are comfortable with that will result in a finished product. I would submit that focusing on readability of code and a well thought out, well executed, and extensible design is more important than performance. About writing a GUI...nothing says you can't write the GUI in one language which is well suited to high level GUI stuff and the logic in a different language well suited to performance. In the example of a web application...you can write the back-end code (where speed matters) in C++, the web app code in Python and the GUI in JavaScript/XHTML markup.
  19. 5 points
    There's been a solution for this exact use case built into Windows since it was a 16-bit cooperatively scheduled layer on top of MS-DOS. The relevant starting point is the SetCapture API.
  20. 5 points
  21. 5 points
    This article will introduce you to basic art concepts to give you a head start in making your own 2D game art. This is not a Tutorial! This article is for those with some vague familiarity with 2D art for games, primarily people who are programming games but would like to create quality assets, or those just getting started with creating art for games. By 2D assets, I'm referring to 2-dimensional images used for games - anything from character sprites to large backdrops. This article focuses on giving a brief introduction to good old-fashioned art skills and the ways they can make your game better. It's meant to give you a brief introduction to some principles and ideas so you don't have to waste your time discovering them the hard way or develop any bad habits you will then have to break. I won't be covering things like file formats, raster art vs vector art or what software to use in this article. What I will be covering: Form and Shape Anatomy and Proportions Perspective Breaking Down Color Lighting and Shading Practice Makes Perfect If those bullet points don't grip your heart and tear at your soul, here's this handy before-and-after demonstrated what you will learn: An internet fact! Okay, that's actually what my programmer friend made and my, uh vast improvement, but I think it's a pretty good example of what happens when you apply a little artistic know-how to a design. We're all used to looking at 2D images in everyday life, but knowing what things look good isn't the same as understanding exactly why they look good. Any 2D image can be broken down into basic elements, and you can think about creating 2D art as combining those elements in a way that 1) Looks like what you meant it to be, and 2) Is not super ugly. For example, we all know what a square and a sphere look like, but how do they fit into the process of making an identifiable character? To answer that, we're going to start with our first section: Form and Shape Knowing that shapes matter, you can apply them to make environments seem more or less friendly, or match (or intentionally mismatch) characters and objects to those environments. Start designs with only very basic shapes- I'm talking about circles, squares, and rectangles. Try a character made of squares, or one made out of just triangles, and then see who looks more like the hero and who looks more like the villain. Keeping your initial design thoughts to shapes only also lets you generate a lot of ideas without getting carried away trying to figure out the detail right away (more on that later with the "Practice Makes Perfect" section). Generally, sharp edges imply artificiality or evil while curves and roundness imply organic and good. Traditionally it's thought of as a spectrum, with roundness on one end with jaggedness on the other, with squares somewhere in the middle. For a great example, think about the landscape of Mordor in the Lord of the Rings films, versus the rolling hills of the Shire. A round, friendly looking character wandering through an angular environment seems more unsettling than the same character in a predominantly round environment. In the same vein, you can easily make stylistic choices to influence how a player thinks of an area. Let's take a look at another particularly good example... Let's break down two characters that have a lot, but also pretty much nothing in common: Godzilla and Barney the Dinosaur. What kinds of shapes make one look like a fearless killing machine and the other look like a friendly hugging, uh... machine? Also, Godzilla has three fingers.(Barney image source, Godzilla image source.) Think about it, both characters are T-rex-like monsters designed around the fact that a guy had to fit inside... but they're on the opposite sides of the appeal spectrum. Why? It has a lot to do with one having smooth curves while the other is more angular with parts that are downright sharp (there are other reasons, which we'll get into later). At a fundamental level, this has to do with our general comfortableness with round organic shapes versus our discomfort with sharp angularity. It's no coincidence that "bad guys" tend to have spikes coming out of every conceivable surface (Bowser in Super Mario Bros being the archetype), while "good guys" like Mario himself, tend to be, well, soft around the edges. When Sonic the Hedgehog was conceived as a cooler, more mature version of Mario, it's no coincidence he designed to be significantly sleeker and spikier than Mario. Let's take a look at Barney and Godzilla again, this time in silhouette: Evilness of a character is correlated with how painful the action figure is to step on. Silhouettes are very closely tied to the shape of an object and are a great way to break down the shape of a character. Apart from any connotations of the shapes used, if a character does not have a distinct silhouette compared to other characters, it's not a very good design. Some artists even go so far as to start with the silhouette and move inward to flesh out their subject. Reducing an object to just the silhouette can also be a great double check after it's already started to make sure it's looking right. In summary, when thinking up designs for your games, make sure you account for shape and form and connotations those shapes often have to get a design that conveys what you want it to. Also, keep in mind that things are largely recognized by shape, so objects in your game should have distinct shapes in order for the player to identify them easily. Spikey the Sea Urchin as a protagonist, outside ironic appreciation, probably wouldn't have a lot of appeal among Facebook gamers. TL;DR: Everything is made of shapes and forms, and different kinds have different subconscious connotations. Anatomy and Proportions Figure drawing is often considered to be the most difficult field of drawing since people are structurally complicated masses of interconnected cartilage, muscles, bone, and skin. I'm not going to go into super detail since I don't personally have a ton of experience, but there are hundreds of books and websites dedicated to figure drawing. The essential idea is that there are certain rules and relationships in terms of length, size, and position of anatomical features, which is important because anatomical errors stick out. The more stylized a figure, like Mickey Mouse, the less important strict adherence to anatomy becomes, but it's a good idea to study realistic figures since by knowing the rules, you'll be able to bend them better. You can think of human proportions as essentially shortcuts to get close to ideal anatomy by comparing the size of different parts of the body to each other. There are specific proportions to measure pretty much every part of the human figure, but the usual starting point is the head. Humans in real-life are around 7.5 heads tall, though often this is rounded to 8 to make a slightly more idealized figure: There are many, many examples of available of this kind of diagram. Google is your friend! Changing the size of the head of a character compared to his/her/its body can have a pretty big impact on how that character feels. Big heads are more child-like, and so are more associated with friendly characters, while small headed characters feel more adult or even grandiose. Yet again, Godzilla and Barney help us out: Godzilla might seem more mature, but Barney is waaaaaay creepier like this. TL;DR: For people to look right, they have to follow certain rules regarding proportions, and messing with different proportions can change the "feel" of a character. Pages to get you started: Proportions Guide by FOERVRAENGD, idrawdigital Tutorial: Anatomy and Proportion Perspective Perspective is all about creating the illusion of depth on a 2D surface by altering the appearance of shapes and forms and is a pretty big subject so forgive me if I split it into sub-headings. Geometric Perspective Most 2D games simply avoid dealing with what I like to call "Geometric" perspective for the simple reason that implementing true-to-life perspective would be insanely time-consuming for creating 2D art for games. Games like to cheat their way out of that problem by adopting unrealistic viewpoints, such as assuming everything is seen perfectly form the side (like a 2D Platformer), or from an isometric viewpoint which is no less realistic although more subtle in its unreality. I want to go over it because it's probably the hardest overall principle to truly understand, and even a very basic understanding will get you vastly better results. The Vanishing Point forms the basis for most formal perspective and is based around the idea that parallel lines appear to converge onto a single point as they recede from the viewer. LOLwut you ask? Like this: This would be a more dramatic example if there was an oncoming train.Image from Wikimedia Commons Notice how the parallel lines (real and implied) converge? Maybe this will help: So I could have added more red lines, what of it? Red lines converge on the vanishing point. Got it. What you also see dividing the earth and sky is the Horizon Line, which happens on infinite (from the viewer's perspective) planes. Vanishing points and horizon lines at their core enforce a really a simple idea: Things that are far away appear smaller than things close up, and the closer side of an object will appear bigger than the farther side. The above example uses one vanishing point, but there are really as many vanishing points in a scene as there are sets of parallel lines, with each set having its own vanishing point. Sound complicated? It definitely is, which why scenes are generally simplified down to one-, two-, or three-point perspective. What normally happens with one-point and two-point perspective is that one or the more sets of parallel lines are assumed to stay parallel forever and never converge. Here's an example of a cube and a cuboid in one point perspective: That's right... pencil and paper, sucka. Note how the horizontal and vertical sets of edges are perfectly parallel. Now, here's two-point perspective: It's traditional when you're starting out with perspective to lightly draw the other side of the objects as well to get a better feel for the 3D-ness. Here, the set of edges that were previously perfectly horizontal now get their own vanishing point. The vertical edges stay perfectly parallel. Finally, here's three-point perspective: Three-point perspective pretty much entails epic-ness, at least in terms of height. Now all edges get their own vanishing point. Good for them, right? It should be noted that vanishing points deal parallel lines the best, but by drawing guide lines or even full boxes you can get a better idea of how to approximate depth for complicated shapes. One, Two, and Three-point perspectives are by far the most common and useful, but there's at least one artist who has used six-point perspective to create crazy spherical scenes. There's an important trick to drawing tubes or any circular object in proper perspective, since circles in perspective deform in special ways. Circles look like ellipses when they're viewed obliquely, the more oblique, the more squashed the ellipse: I cannot tell you how many people don't get this, so seriously and for real, circles turn into ellipses. A simple rule is that when you're looking up at a cylinder edge (like the roof of a round building), the curve bulges up. When you're looking down, like at the base of telephone pole, the circle bulges down. The line through the middle of this image is the horizon line: This would have been a perfect candidate for shading to add depth, but we'll get there. However, you should remember than many 2D games avoid geometric perspective problems by picking viewpoints (from the side, perfectly top-down) that minimize the need for it. Foreshortening A common perspective art concept in figure drawing is called foreshortening, which comes up often with how parts of the body appear in perspective. A fist held out at the viewer will not only appear bigger than it would be held at character's side, but it eclipses a huge part of the arm, too. I'm terrible at figure drawing so this won't be the most professional-looking example ever: Seriously, I suck. Often, artists eyeball foreshortening for characters simply because laying out all the vanishing points would take too long. But for your edification, here's forshortening with vanishing points and cylinders, which are often used as proxy forms for limbs: At least I can draw cylinders good...er, I mean "well". Keep in mind that characters, human characters especially, can be thought of as a series of simpler objects which are easier to comprehend. Sketching out characters as a series of tubes connected by joints before filling in the detail isn't uncommon. Page to get you started: idrawdigital Tutorial: Forshortening Tricks Overlap and Parallax Overlap is very simple: closer objects will overlap and mask farther objects. It's very important for 2D games since it's a very simple way to show the player their relationship to objects. Let's take a quick look at an extremely simple example: Also known as the weird hills in the background of every Super Mario game. From this set of lines you perceive the circular thing (a bush?) on the right is in front of the others, while the tallest one is behind. This effect is sometimes called the "T-rule" since the line of the object in front forms the top of a T compared to the object behind. It's simple, but pretty powerful. In this example, all the T's are updside-down: More like ASCII Code 193 rule, amirite? Parallax is another important perspective effect having to do with the relationships of overlapping objects. Parallax essentially is that objects that are far away appear to move less when the viewer moves, compared to closer objects. Parallax is great for 2D games because it's pretty easy to implement, and you have no doubt come across it. Wikipedia actually has a pretty decent article on using parallax in games, and I'd hate to waste your time regurgitating it. Atmospheric Perspective Since 2D games often intentionally violate regular perspective rules for the simple reason that it's easier to draw stuff for them, they have to rely on other means to get the idea of depth across. By making objects that are supposed to be far away from the viewer appear more washed out and less detailed, you can easily make the brighter, sharper looking things in the foreground appear more distinct. Here's an example from real life, in a picture I took while visiting the gloriously smoggy People's Republic of China: For real, it's pretty smoggy over there. You can also see the parallel line perspective effect, although in this case the main vanishing point would be off to the left of the frame. The game applications are pretty staggering. Almost every 2D platformer ever made uses atmospheric perspective. Take this screenshot from Super Mario World: Also, overlap and parallax! Booya! Super Mario World Image Source Notice that the farther in the background an object is, the more washed out it looks. In particular, looking at how dark the outlines are tell you how close they are to the plane of the player. This also folds directly into the idea of contrast. Contrast can tell the player what's important and what's not. Take a look at that Super Mario World screenshot again. Blue hills that are lightly shaded? Not important. Pipe with a white highlight fading to total black? Important. The only bright red thing on the screen? Super important. Remember, interactive parts of a game should always stand out from non-interactive parts unless there's a specific reason to obscure something from the player. Pages to get you started: ArtyFactory.com Linear and Aerial Perspective, perspective-book.com Tutorial Breaking Down Color Color is a tricky thing, and one of the more subjective parts of art in general. Some colors look better to some people than others, and color combinations and connotations do not transcend cultures. White might be the color of purity in the west, but in Japan white often stands for death. However, there are a few basic ideas regarding color that will help you out in understanding what's going on in your art. Let's start with thinking about what makes up a particular color. Hue, Saturation, Brightness There are many ways to break down color, but this one I think is the most helpful for beginning digital artists. Let's start by comparing two colors: Red vs Blue, get it? It seemed pretty clever at the time. Red and Blue. They aren't the same color? Pretty simple, right? Well there's actually a more precise term called Hue. The left square has a red hue and the right one has a blue hue. Other hues include green, orange, purple, and so on. While hue may seem just a redundant term for color, it's not because the amount of any given hue in a color can change: Red vs Less Red. So they are both red, but how are they different? The one on the right is just kinda... washed out. The term we're looking for is saturation. Saturation is basically the term for how colorful, um, a color is, or how much hue it contains. I like to think of saturation as a measure of how much gray there is in a color. No gray = saturated. Lots of gray = unsaturated. So in this case, the square on the left is a fully saturated while the one on the right is desaturated. Pure gray is simply a color with no saturation. Saturation is the most devious of color attributes for beginners to get the hang of in my opinion. Just be aware that saturation has a big impact on the "tone" of your art. Highly saturated colors tend to look more, well, friendly when used in large amounts, where desaturated colors are associated with grittier style. The last attribute is Brightness. It's much more straightforward - it's just how bright the color is (sometimes the term "value" is used instead, no biggy). Here's the same red as above, but with a darker version: Same red, but darker (not desaturated). The relationship between brightness and saturation takes a little getting used to, since they can appear to overlap: I like drawing spaceships and explosions, but I also secretly like magenta. Here's an example of how color can affect the tone of a game, with Castlevania: Lords of Shadow set against New Super Mario. Also note the lack of gibs and bloodsplatter you'd expect a Mario that size would generate stepping on a goomba. Image Source Nothing clever, just wanted to point out how well those bright status bars stand out from the background. Image Source You know what also relates back to color... Barney and Godzilla! Whooo! So anyway, think about the ways color makes them so different in terms of hue, brightness, and saturation, and what would happen if one or more of those attributes changed. What would happen if you left one attribute alone but traded them between the characters? Would a gray Barney still seem huggable? There is no escape from the Godzilla-Barney comparison! RGB in Brief Congratulations! You now understand HSB (Hue Saturation Brightness) color (sometimes the "B" is swapped out with the a "V" for value, but the meaning is the same). Pretty much any image software can use that definition along with Red, Green, and Blue (RGB), and Cyan, Magenta, Yellow, and Key /Black (CMYK). I think HSB is a much more straightforward way of understanding what's happing with colors, especially regarding how bright and how saturated a color is, which is what you need when you're working on shading. You will have to work with RGB color in different applications however, so let's review that briefly. RGB simply describes colors in terms of Red, Green, and Blue, since all colors can be described as a combination of those three, which has to do with how your eyes process color information. Take some time and monkey around with color values to see what both the HSB and RGB values change, and how they related to each other. Here's the standard RGB overlap diagram (notice what happens when the colors overlap): Also known as an additive color model, since colors are creating by adding light, rather than absorbing light (subtractive model) Also note how when all three are combined, it makes white. You can think of all the colors playing in a tug-of-war, so when they all have the same value, the hues cancel each other out and make gray. But the colors different combinations yield can be kind of confusing, so for working on artwork, I would lean towards HSB. The Color Wheel Now that we have defined what a color is, let's start looking at color combinations. Color theory is complicated and pretty subjective, so what follows isn't meant to be an ironclad explanation, but a guide of what to think about. The color wheel forms the basis of most color theory. It's basically an arrangement of hues by their perceived relationship, with Red, Yellow, and Blue at the thirds of the wheel (the so-called primary colors), with Green, Orange, and Purple (secondary colors) between them. Wheel of Color would be a really stupid game show. Hues are also commonly split into Warm and Cool categories, termed color temperature, with red-yellow colors being described as warm and blue colors being described as cool, as below: Spike Lee's film Do the Right Thing was oranger than normal to make it seem "hotter." I learned that in a film class, and it seemed relevant to bring up. I added a zone of iffiness, since those colors are kind of borderline but I've seen the yellow-green as cool and the magenta color as warm. The important thing to remember is that cooler colors are associated more with darker shades, so a cool shadow will be perceived as darker than a warmer one that is technically the same value (brightness). Other relationships between colors can be explained using the wheel, too. Analogous colors are simply hues next to each other on the color wheel, like green, yellow, and the colors between. Complementary colors are colors (hues) 180 degrees from each other that appear more vibrant when used together. You've probably seen them in action, even if you didn't know why; blue and orange has even become a trope. If you're using Firefox, look at the icon. Complementary colors strike again! When working on game art, think about associating colors with specific factions or enemies and environments or levels. Color-coding isn't mandatory, but you can use it as a way to bend player perception. Think of a set of colors for bad guys, but use unique shades of those colors for specific enemies, for example. But with using colors, don't be afraid to experiment and try lesser-used colors. Using any reasonably-advanced art program, like GIMP, it's actually easier to change color than any other attribute. It's one of the few things you can change after completion relatively easily. TL;DR: Colors can be divided and related to one another in different ways, and different combinations of colors can make their individual component colors look different, for better or worse. Page to get you started: Color Theory for Designers Lighting and Shading I'm going to be using lots of pixel art examples, but they basic concepts are just as applicable to any other type of 2D art. Light Sources The most common issue I see with beginning artists is that they don't understand lighting. Shading a drawing generally means to apply different shades to create the illusion of light in a drawing, just like perspective is the illusion of depth. And just like in perspective, you have to create some 2D stand-ins for mimicking real-world effects. There's really only one rule: Light has to come from somewhere. It doesn't just appear, which means that laying down colors in a drawing will always look wrong. What happens pretty often with beginners is that they try to "shade" their art, but don't understand lighting, which results in objects that look like this: Seriously, don't do this. Compared to the unshaded version: You might even be better of with this version than the one above. It's called pillow shading, and it can be easy to do without thinking about it. It can seem natural to just color from the outside in with darker shades... but it looks completely fake. In order for lighting to look right, it has to be directional, with light/dark shades being chosen depending on the whether or not a side of the subject faces the light source(s). A light source could be the sun, a lamp, a boiling hot lake of molten lava, etc, but doesn't have to be something that specific. For example, you can just assume almost all light is coming in at 45 degrees from infinity, and your subject will be shaded well enough for most applications. For animated sprites that are going to be used in a variety of environments, a little vagueness helps keep the sprite from looking too out of place on any background. Here's an example using a light source coming from the top left somewhere: This also requires you to think about if there's a part casting a shadow over another. Parts facing the light source are lighter and parts facing away are darker, couldn't be simpler, right? Of course, it's not always that simple... Flat vs Round Keep in mind that flat surfaces generally have almost the same shade across their entire surface, where curved surfaces will have a gradient of shades. Here's a neat real world example (with fighter jets!) of how this works: An F-117. I actually grew up with these flying over my house. Notice how all the panels have the same shade unless they're actually in the shadow of a different part of the airplane? Now, let's look at a more normal jet (an F-15): Whooo America! Except this one is actually Saudi Arabian - Gotcha! Relate back to the Shape and Form section. Which one of these bad boys would you cast as the good guy and which as the bad guy going on looks alone? Here, you can see an actual gradient transition between light and dark. Check out the left wing, it's an almost perfect gradient. Now let's go back to that pillow shaded mess from earlier: The light source for the cube and sphere aren't quite the same. What's different? Note the cube only really needs one value per side at this scale, while the sphere requires many more values to mimic the gradiated nature of shadows on curved surfaces. Bounced Light The kind of shading above is simplified since light can also bounce off surfaces and light up shadows. This often means that the part of the shadow that is farthest away from the main light source is actually lighter than the other parts of the shadow. This is most noticeable when an object is extremely close to a reflective surface, or is just plain big. This is the classical example of how this looks: Also note how the shadow it casts also gives you a better sense of depth. Here's a couple digital examples of the same thing. If these spheres were sitting on a blue surface, the reflected light on the cube would also be blue. The left is an example of bounced light located off the edge, which happens with highly reflective surfaces. The shinier the object, the more obvious and distinct this bounced light appears. Speaking of shininess, lighting and shading can not only reveal an object's form, but also its texture. Hue Shifting Hue shifting relates somewhat to bounced light, and comes up with pixel art a lot. It basically refers to how the hue of a shadow or highlight isn't necessarily just a darker or lighter version of the base color. The most common usage is for objects that are supposed to be in the sun. The direct sunlight tends to be a little yellow, but the blue sky reflects blue light into the shadows, so you have yellowish highlights and blue-ish shadows. This also relates back to warm colors and cool colors, with cool shadows and warm highlights. This idea becomes more important when you have multiple light sources (like underlighting from lava or whatever) that's a different color from other light sources. Remember, colored light affects the color of the object. But hue shifting can also be simply a stylistic choice, and by exaggerating the effect or substituting complementary colors you can get some pretty neat effects: Doing this too much will make your game look like it's trapped inside Instagram. Keep in mind that shadows can also appear to be less saturated, and that less-saturated colors can appear darker than they really are. There's not a total consensus on hue shifting in the art world, so find a way that you like, but keep in mind the more you shift, the more surreal your art will seem. Shading and Texture The texture of an object affects how light bounces off of it, so naturally changing how you shade something can also change what its texture looks like. There are specific terms for certain types of textures that will help you in thinking about different types of texture, too: Knowing this will let you buy paint without having to ask the forlorn-looking old guy working in the home improvement department for help. A Gloss surface is just a shiny surface, where the light bounces off a particular angle of the surface almost all in the same direction with very little scattering. What that means is the brightest part is very bright (since you're getting lots of light from that one place at once) and the darkest part is very dark (since the light is sticking together and going somewhere else). A good example of a gloss surface is the body of a freshly waxed car. A Flat texture is the opposite, where light scatters off the surface at many different angles. That means the brightness is more even, since no part of the object is directing all of its light in a particular direction. Old car tires are a pretty good example of a flat surface, as is modeling clay. A Matte surface is somewhere in-between. It reflects light in chunks, but scatters a lot too. A lot of plastic has a matte finish, like most keyboards. So when you're drawing, think about what kind of material that you're shading is supposed to be. Is it shiny metal, or flat cloth? You don't want your medieval characters wearing plastic-looking garb, and you probably don't want your sleek sci-fi armor to look silky soft. TL;DR: Light has to come from somewhere, or look like it does, for 2D images to look right. Page to get you started: Android Arts Tutorial by Niklas Jansson Practice Makes Perfect So now that all those concepts are laid out, what are you supposed to do? Well, start trying stuff out! Don't be afraid to jump right in. It really is true that anyone can draw. Sure, some people have a particular knack, but the biggest separator between a bad artist and a good one is how much they've practiced. You gotta do it a lot to get good at it. Practice, but practice smart. Game projects also provide a lot of opportunity for practice, so if you have a project in mind, start creating art for it if you haven't already (after reading this article all the way through, though). If you don't have one in mind, find one! Even the smallest game project has enough art that you'll get enough practical experience that by the next one you'll be noticeably better. And fortunately for non-artists, game art doesn't have to be Italian renaissance level quality to be functional. Three P's: Pencil, Paper, Practice The only way to get better at drawing is to practice, and the cheapest and easiest way is to do it with good ol' fashioned pencil and paper. It might be tempting to simply stick with digital-only for all steps in the design process since that's where your final product will be, but resist! Drawing by hand gets you more involved in the process and will help you avoid some of the more dangerous habits that relying on software tools will get you. Those tools can be great and it might seem easier at first to make sprites using the square tool, but trust me when I say that you would do ridiculous and ugly things that would be impossible to do with a pencil sketch. There will be plenty of time later to mercilessly exploit tools, tricks, and shortcuts when you're conscious of the basic principles. It might seem awkward at first if you've gotten used to doing things digitally only, but pencil and paper are the starting point for artists the world over for a reason. With that in mind, I recommend buying a sketchbook, some pencils (I like mechanical pencils, but it doesn't really matter at this level), and a separate eraser like a Magic Rub since you'll be erasing way more often than the #2 pencil designer gods intended. You don't absolutely need a sketchbook - the real key is that you need to practice, and to that end the margins of your class notebook or a sticky note at work aren't worlds apart. A sketchbook does let you keep all your work in one place, though, so you don't have to hunt down that one really sweet design for an enemy that you put on the corner of your homework or a memo at work. Sketching The key to pencil sketching is to think of all the lines as temporary suggestions rather than permanent representations. What? Don't get attached to your lines! Sketch over them, erase them, make new ones without regard for old ones. Of course, make all your lines fairly light when doing this. Start with the basic shape of your subject, and add detail incrementally. Most things can be approximated by basic forms, namely the sphere, the cylinder, and the box, which is especially useful for drawing objects in perspective. For example, don't draw a more or less finished head, then move to the chest, then arms, then legs, etc. because focusing on detail will make you lose sight of how those parts fit together. Start with a big rough sketch of everything together and add detail on top of that. Don't get attached to any lines in the beginning - don't be afraid to ignore lines and draw other lines on top until you get an overall shape that looks good, and don't be afraid to simply restart if things aren't going your way. This video illustrates this perfectly, as the artist builds the basic framework of the character, puts some rough shapes on top, the proceeds adding more and more detail - and erasing and re-doing parts that look bad. Here's a little image out of one of my old sketchbooks, complete with funky-looking man: Another figure - Don't look! Um, I guess he has a huge zit on his face? What was I thinking? Draft, Draft, Draft It might sound crazy at first, but you should sketch at least three versions of any character/object/setting before committing to a digital version to use in a game. Major studios often create literally dozens of concepts for a single character before even thinking about picking one. Even for background assets like trees or bushes that aren't interactive, sketching three versions to get one final asset is not an unusual ratio. Just like turning in the first draft of a term paper, making the first version the only and therefore final version is a huge risk and not one worth taking. By trying three different ways, you can also then take the best parts of each version and combine them to make a stronger final version. Here's a simple example of a couple cool space helmets, both of which are different than the final design below (and based on even rougher earlier sketches): Shout out to Anatomy and Proportions section since it's hard to make a helmet without knowing how skulls are shaped. The top part should really be casting a shadow on the visor... oh well. This might seem burdensome, so it's important to keep in mind that these sketches are rough, rough, rr-rrr-rooouuugh drafts. Don't spend time on them. In fact, the less the better many times, since the longer you dwell on a piece, the less flexible you become about revising it or making the next version different. Leave the detail out at first, just get the general idea down and move on. If you feel like it, you can then go back and add more detail to your first contender. Be prepared to draw, a lot, and be prepared to get a little frustrated sometimes. If your art looks iffy at best to you, congratulations, you are a human being. Your next drawings will probably be better, and the ones after that better still. Remember, getting frustrated is standard - if drawing was as easy as it looked, there wouldn't be this article. In fact, if you aren't getting at least a little frustrated drawing for a while, you either aren't pushing yourself or your contacts fell out and you've convinced yourself that blurry mess was totally your intention all along. TL;DR: Draft all your game art by sketching out several versions first with pencil and paper, without worrying about being perfect. Related Page: Sketching: The Visual Thinking Power Tool Conclusion Hopefully now that you are familiar with these concepts, you can go forth and create with the knowledge you need to not suck. I mean, be incredible! Seriously though, creating art isn't easy and it takes a lot of practice, but just having some idea of these concepts is fantastic. As I said in the introduction, most of the information here is in the context of creating 2D art for games, and doesn't necessarily reflect what you would get in an Art 101 class. Further Reading I've included links within the text, usually at the end of relevant sections, but if you're interested at all in any further information about game art, particularly character creation, I have to highly reccomend Chris Solarski's book Drawing Basics and Video Game Art. This article owes a lot to him and his book, and you can read some of his writing on Gamasutra.
  22. 4 points
  23. 4 points
    https://www.twitch.tv/videos/168126246 Link to the full review of all the submissions. I did go through them in order of games in the rar file.
  24. 4 points
    Hi. To be honest, but the game design for me has always been something unique and interesting. My path of game development first started with programming. After I began to draw, in order to be universal, but later, I discovered the game design and that was for me, on a pedestal favorite direction. Today I would like to touch on the types of players, why they play the games and pleasures of games. Be brief and clear. In our nature there are 4 types of players: explorers, killers, sociable and those who like committed to something. Crooks. This type of players are focused more on the quick passing game. It does not matter the study and details in the game. Killer. These guys love to destroy everything and kill everybody. Just put them in the tank, tell them where it is necessary to blow - trust me, they will not leave anything alive there. Sociable. They love socializing, but most of all they love online games where can someone make friends, work in team and to tell you the recipe for a delicious mother's cookies. Researchers. How do you think, what you like to do this group of players? I also think that they are exploring every path in the game where you can collect all achievements. Every time you create a game, ask yourself the question: "what kind of player I do my game? Is it possible to combine these types of players in my game, changed some part of it?" Incidentally, with regard to online games. Why do you think people play online games? First, they like competition, will compete to get to the top and gain respect. Secondly, people like to work in a team. Personally I play team games and more hours spent in team modes rather than in single. I love this mode. Thirdly, people play online games in order to meet and chat with friends, spend time with them online and meeting them to have constant, friendly contact. As you know, men play more games than girls. Their main game is the first 20 years. Action and aesthetics - their element. From 20 to 30 years, men are already playing something more calm and tactical, where you do not need a lot of push on the joystick, but need to think. And about men from 30-35 years to play in something calm, for example in genres "I'm search" and "Farm". But women, as a rule, begin actively playing with for 30 years. More women in the world, but I don't like the game. But often after 30 years of playing farm frenzy. Identify the main fun of the players: Fantasy. We love to feel part of another world, which could be anyone. Plot. Sometimes the plot can cause a pleasant sense of his sudden change of events, a dramatic denouement and linearity. Partnership. Teamwork is enjoyable. Discovery. The opening of the new - is the main game fun. Expression. Everyone loves to brag about. Obedience. Cool when you can control others. Feeling. When you realize that step the expected event, then the waiting becomes a pleasure. The gloating. When you killed your enemy, it's nice. Gifts. We love to receive gifts? Humor. No comment. Choice. To go left or right? I have a choice? Fulfilled goal. We love to reach goals and to feel pride because of this. Surprise. We love to be surprised. The Japanese are masters at it. Fear. We love to be frightened and to feel the shaking. This is an interesting kind of fun that we both and hate. A miracle. When we are strongly of something was surprised and experienced a wild delight from something. A tough win. That moment, when initially there was little chance to win, but you win. So when making a game, think of the fun highlights of your game and how much to add. My name is Flatingo and I love to make games. If you also like to make games, welcome to my YouTube channel. Good luck in your projects.
  25. 4 points
    There is a great book, "What Color Is Your Parachute?" that covers that in depth. I strongly recommend everyone reads it, it has been a best-seller for many decades so you can find many copies at your local library or used book store. Yes, you can do a job you don't enjoy. You can grow to love a job that you initially dislike. You don't need to be passionate about something to do it. For example, I spent some of my early years doing custodial work; I hate vacuuming and cleaning toilets. I also spent several summers earning money doing yard care even though I have severe allergies and needed to be heavily drugged to get through the days. However, I love software development and I can talk with people for hours about good practices, about algorithms and tradeoffs and software bugs. I also enjoy games and developing products that people enjoy. I also love several other fields, and I've turned them in to hobbies. Even though I love software development, there are still tasks I dislike. There are still software assignments I don't want to do, but I do them anyway because I'm a professional, just like I cleaned toilets and breathed pollen clouds while disliking the job. All jobs will have elements you dislike. In an ideal world you do stuff you love all day, every day. In the real world you can get occasional periods of bliss but most of the time you get boring real life. Sometimes you get difficult troubles, and in that case you can (and should) take any job you can honorably do. If that means doing a job you dislike that pays the bills, then for a time that may be a job you've got to do as you work to improve your situation. Anyway, go get a copy of "What Color Is Your Parachute?" which has several soul-searching exercises to help you figure out details of the things that you most enjoy in an effort to bring you closer to your own personal bliss, the things you enjoy most. I heard the quote years ago: "Life is to be enjoyed, not just endured." Endure when you must, but find joy wherever you can.
  26. 4 points
    Greetings and Salutations. I can't think of anything that justifies the risk to add at this stage, So end of day seven for me. I spent the day mostly adding polish, Which includes: Laser pointers for the turrets, No ammo sound, Low health sound, Changed the colour on each alternative entry in the credits. I thought I solved the performance issue (which was some kinda base static light pass, Which I could find no info on ), It runs faster in the editor tho. The AI(FrogMen) is a bit iffy, They should shoot or melee you on sight. Yet they don't most of the time, But the work well when they do. There is a text field in the options menu you can use to execute any UE4 console command, I have included a file "CVars.txt" with some graphics related commands. You may want to drop the quality setting down to medium, I had to for the game to hit 60 FPS. This has been fun, I look forward to playing the other entries. I may even do a review of them. Dang, I forgot to credit @riuthamusfor his asset pack (Sorry @riuthamus). Link to my entry: Here Title: Invasion of Planet Frog And the picture: Thats all for now, Thanks for reading.
  27. 4 points
    Day 7! What a wonderful week! Today we tried to finish the game. We haven't implemented anything special, just bug fixes and gameplay enhancements. Here's the game: https://mega.nz/#!K40gGKyC!k-nuSvEdhKluAhznQvr3RFEC70ErwcXyjoxHF7QvNiU After I write this entry, I'll post the package on the site. Hope you enjoy! Thanks for reading and following the development of our game during this week!
  28. 4 points
    Competition is over, judging thread: The competition has begun, this years themes are: Chain Reaction | Assassination | Alien Invasion | Castles You must choose 2 themes to receive full theme scores. This year their is no stipulation on gameplay or graphical, You are free to interpret the themes anyway you wish, but remember it should be fairly easy to know which theme you chose. To submit a game this year, you need to sign in to this site: https://neonlightgames.com/woa/Submit with your gd.net credentials. If there is an issue submitting to the site, then you can upload elsewhere and link to this thread and i will manually add it to the site. Remember you can submit a game even if you did not tell us you were participating! Remember to receive participation points you must either post updates in this thread, or drop a link to your blog updates in this thread!! you can also get points by commenting on other people's updates as well! This year, our resident artist and judge riuthamus has graciously created a number of art assets for the themes of this year's contest. they are free to take for this week, and are free to use afterwards, but will be only available as free to obtain for this week before they will be placed in the unity store, so if you are seeking some assets to use in your games, you can find them here: https://dl.dropboxusercontent.com/u/41065/WoA_modelPack_v1.zip (note: check back tomorrow as riu says it's not 100% finished.) some images of the pack: Lastly i'd like to once again recommend gd.net'scord chat can be found here: ttps://discord.gg/Njc96xM where we have a dedicated channel for WoA. Good luck to everyone! remember to post your updates in this thread! Administration Thread:
  29. 4 points
    Addressing a few points in no particular order: Pure design positions are indeed a role in the industry, although they're comparatively rare and generally require a proven skill set. Most people in these roles got their chance by making their own projects, by being given a chance on some low-risk project, or by having experience in tabletop game design. Steve Cole is a good example of someone who could qualify for such a position. There are actually entry level pure design roles as well, but they're significantly more limited in scope and don't match what you with to do - you would probably consider them more akin to a design assistant, working on small bits of a project as part of a more senior designer's team. The reason noone is really considering this as a viable option for you, is as I covered earlier in the topic: you simply do not have a verifiable track record of relevant experience. You may well have designed hundreds of games and be very good at it, but as far as you've made us aware you only have verifiable credits on two released products: as a contributor to the SFB Tactics Manual (along with 25 other people credited for design), a design credit for Sinistar Unleashed (which had very unpopular design), and perhaps if you're lucky and someone remembers it your IKNFL mod. You haven't claimed to have any relevant formal education. You may well be a fantastic designer with a wealth of experience, but you have nothing to prove it, so it's exceedingly unlikely a business would risk money on the chance that you'll be as good as or better than someone with verifiable qualifications - noting again that the sort of pure design role you're interested in is generally not entry level and isn't going to fresh-faced Devry graduates either. So, if pure design roles are a thing, why do people keep telling you to learn how to program? They're actually giving you different advice, not aimed at getting you in to a pure design role. For the reasons above, people have trouble believing you would be able to get into a pure design role, so they're offering you an alternative: learn to make things yourself so you don't have to be held back by the industry, or so that you can produce something suitably convincing to get into a position you want in the industry. Remember above how I said pure design roles generally only go to people with a proven track record? Sometimes those people get that proven track record by learning another discipline such as programming or art so they can work in other roles until they prove themselves. In short, the suggestions to learn programming do not actually contradict the suggestions that pure design roles exist. In sales, they say that it doesn't really matter what's true - it matters what is believable. You're essentially trying to sell yourself to us, and you're constantly making some pretty huge claims about your abilities and about what 'rube' can do. Maybe the things you're saying are really true, they're certainly not impossible. They're certainly not believable though. You tell us you're a founding father of our industry, but none of us have heard of you and you aren't credited on the published products to prove it. Maybe it's true. But it's not believable. You tell us rube is 'a functioning simulation of god', but you won't share anything but the smallest details (and you make us wade through the most amazing amounts of text to get those small glimpses), and you even claim the full potential of rube can't be realised with current day computing limitations. It may well be true. But it isn't believable. Stop trying to sell us your truth, and sell us what is believable - once we believe, maybe people will start to see your truth. It's not believable that you're a founding father of the industry with years decades of design experience on hundreds of games, because the games aren't there for us to look at, so instead show us something we can believe: polish up some smaller, simpler designs and just show us that you're a good designer. It's not believable that rube is 'a functioning simulation of god' (whatever that means), so stop talking about the unprovable possibilities that current computing can't even handle, and stop talking about things you aren't willing to share details of. Talk about something we can believe, and show us what these lesser forms of rube can actually do in an implemented design. Don't talk about the history, and don't talk about future possibilities: stick to what you can actually show us right now (or in 6 months or in a year if you need time to work) in full detail, so that we will have no choice but to believe. That is how you can get some actual interest in the other stuff. Star Fleet Battles is one of the most (if not the most) complex and detailed game rule sets in existence, and you keep discussing how other games (such as Master of Orion) pale in comparison. You keep saying this shows how much more skilled the designers such as Steve Cole are. I don't think anyone disputes the skill of Steve Cole and other table top designers. They're work is fantastic, and many of their games have a very loyal following and have made plenty of money, often for years. But you don't seem to allow for the fact that taste in games is subjective. You love how complex and amazingly detailed the rules of SFB are, but many people hate it for exactly the same reason. When a designer produces a simpler game, it doesn't necessarily mean they are less skillful, it just means they had a different objective in mind. Often, these designers have been very skillful in designing a less complex game that appeals to the great number of people who prefer simpler games. You've mentioned a few times that the industry has no respect for table top and board game designers. I'm sure there are some people who don't, but I can assure you this isn't some all-encompassing attitude shared by the whole industry. I don't think I've ever spoken to anyone about it who didn't have a huge respect for those designers. Many people in the industry play and love table top and board games. Many study them to learn. Many design them as prototypes, or as full products to develop their skills. Many table top designers have made successful transitions to our industry and are now well respected designers. You're having trouble finding anyone who respects you, because (at least in my experience of you) you're all outrageously rude talk with no demonstrable credits or released product to show that you're actually worthy of respect, but in general I'd say our industry has a huge respect for table top gaming. It isn't laughable to defend Devry graduates getting positions while you can't get one, because you aren't after the same entry level roles that they get, and they are more demonstrably qualified than you for the roles they are able to get. You may well be a great designer, but you can't really prove it right now, whereas a fresh graduate can be assumes to at least have a baseline level of skill in the field taught by their course. Noone wants to make the same assumption about you when all you're giving is your word that it's true. You say the Pirate Dawn design document was actually quite well organised. It wasn't. I'm one of the people who tried to read it, and at least when I looked it was a disorganised unapproachable mess riddled with typos. Maybe that's because 'the industry wanted you to add a bunch of stuff', but that doesn't change what you presented. It just was not. If you'd like to fix it up (or have already done so in the past 10 years) I'm sure some people would actually try to read it again, but there's no point just telling us we're wrong about it - multiple people tried to read it, and we all have the same assessment. For whatever reason, it was a mess. If you have the time to write 500 pages, you probably have the time to go back and fix it up as well. Don't excuse it or explain it, just fix it. Lastly, you seem to think this offensive, overly wordy cult-of-personality you have going on is helping you, and have even suggested a few times that you "have to put it on to get attention". It isn't helping you to get any valuable attention. It just makes you look like an insane rambling crank who doesn't know what he's talking about, to the point that a great many people think you're trolling. If you're genuinely pretending to have this abrasive personality, knock it off. It's not serving you well. You've got plenty of people reading your posts and engaging in conversation, so stop screwing around and do something useful with the attention. Stop driving away attention you've got with paragraphs of irrelevant or unbelievable nonsense. Put your money where your mouth is, and show us you can walk the walk and not just talk the talk. If you're a brilliant designer, show us some actual, playable, brilliant designs. Feedback on Armageddon Chess will be coming in a day or so, we were pleasantly surprised that you claim to actually want to hear it, so some of the others are getting their thoughts together for me to pass on too. Good luck, shut up, and for the love of all that is good and holy show us some actual games! Hope some of that helps in some way.
  30. 4 points
    Hi All, I'm taking part in the Week Of Awesome again. Third time. This year I don't have as much time available, a new job and newborn have left me with precious little vacation time left for the year and less personal time when I'm at home. With that said, I was in my day job today and will be tomorrow so I have only had time enough to think of an idea. The themes are interesting this year, I couldn't think of much for assassination but the castle theme and alien invasion is making me think Sci Fi/Fantasy crossover Tower Defence game. The genre is bursting at the seams but it should keep the scope small and well defined. With all of my jobs for the evening out of the way, I have only had enough time for pulling together a fresh project and the basics of my framework. So no pictures Hopefully I will make some progress tomorrow.
  31. 4 points
    Correct me if I'm wrong, but it's ambiguous because char* and char[] are the same type. Both of them are just pointers to the first character in an array of characters.
  32. 4 points
    Good code: does what it's meant to (i.e. meets the product specification) does what it claims to (i.e. has accurately descriptive names and comments) is easy to understand is easy to change and extend And really these are 4 overlapping aspects rather than 4 separate ones. With those thoughts in mind, here's how I would approach your code: ditch all the 'static' stuff. That implies there is, and can only ever be, one instance of those things. That is not "easy to change and extend". There's a lot of documentation about why singletons and globals are bad, and static variables are part of the same family. remove unused arguments like 'GameTime'. The presence of the argument implies that the function does something with the current time, but it does not. This makes it harder to understand. Make sure your comments match your code. A comment says "//Spawn Individual" but the code says "SpawnPolyGroup". Your code should do what it claims to, and here it doesn't. Add comments to your functions. You don't want to have to read the whole function to know what it does, and the function names are rarely descriptive enough. You want this code to be easy to understand months after you've written it. Rename SpawnPatterns to something more mathematical - there's nothing intrinsic to spawning in those functions, just mathematics. This means your code isn't really doing what it claims (you think you're getting spawn patterns, but actually you just get basic geometry) and it's harder to extend (because if you find yourself needing basic geometry in future, you have to remember that you have some hidden away inside a SpawnPatterns class). Be consistent. You have a timeDelta which ticks downwards, and a spawnTimer which ticks upwards. It's not immediately clear why they differ and it's certainly not necessary to have them counting in different directions. As such, it's error-prone (as you might change the code and forget which one counts up and which one counts down) and hard to understand (what do these 2 different timers mean?) and not so easy to extend (could you perhaps have a standard class for timers like this?)
  33. 4 points
    As you can see, now buildings built in one screen sync to the other. I have a system where it takes a few seconds to build something, and I send the completion time over TCP, then build another work in progress object on the other computer, set to complete at the exact same time. This way, even half a second lag will still not hurt the experience. (On the screenshot, you can see the raw data stream in the console.) I also have a system where the players choose what sides they will play on. The basic system is that the first player to click wins. If both players click the same team at the same time, the both programs will generate a random number and the highest number wins. I haven't been able to test this system, and it will probably not actually work. Aliens and Knights have different types of buildings. They will behave the exact same way as each other, but have different names and images. I am thinking I can get some humor from a rock wall being exactly as strong as a force field, or a laser gun doing equal damage as a bow and arrow. If I get as far as having flying enemies, the knights will have some kind of Davinci winged wooden contraption, with equal speed as the aliens flying saucer. My next step is to give each team a fort. The game ends when the fort is destroyed. When I have a fort, I will not have anything to guard me from actually building the AI for the attackers. I don't think making complicated path finding will be worth my time. When encountering a obstacle, the NPCs will determine if going around left or right is the fastest. If neither is possible, it will go straight on ahead. (As all obstacles are breakable). Shouldn't be to much trouble...
  34. 4 points
    I'm happy to say that I've successfully added one of the two themes I chose to my game. The aliens! They are created at specific points in the map and run towards the player until they collide. At that point the screen will fade out (no battle swirl yet) and a battle will start. It's interesting to note that, just like Earthbound, other aliens can still continue to run towards the player while the screen is fading out. And if they make contact, then they too will be added to the battle. The battle itself isn't anything special yet though. It just displays the in-battle sprites of the aliens and you can attack by pressing the V button. Also the aliens won't attack back yet, which might be a bit disappointing. You can also change the selected alien by pressing left or right, but which alien is selected isn't displayed in any way yet. So that's not particularly useful. By the way I drew the in-battle sprite for the alien completely by myself. It won't win any awards, but I like to think it's pretty decent. Another thing to note is that I recently started using co-routines for animations in Python. Effectively they are just generators that use the yield-statement to give control back to the rest of the update-tick. They are quite effective in preventing the need for stateful member variables (fadeTimer, coolDown, etc.). I might write an article about it later if there doesn't exist any yet that already does a proper job at explaining them. Download link: http://www.mediafire.com/file/ciwguyrx82844l4/main_v0.0.2.zip (Reminder: press V to attack!)
  35. 4 points
    A day has passed since the competition began (at least in my country)., and now I'm going to show you the progress our team made so far. Here's a little video with the current stage of the game: The game we are about to make is about saving a castle from an alien invasion. We want to make a little bit Angry Birds style with aliens landing on the earth. Today we were able just to do the basic mechanics of the game, but we hope that in the following days we'll have the gameplay of the game. The models in this video are just placeholder content. (Tomorrow some of the models will be ready) All right, that's about it, thank you for your attention.
  36. 4 points
    Talking about Devry graduates for a minute... they're not exceptionally skilled, and they aren't hired as team leads or genius designers. Many studios in fact prefer to hire people with traditional degrees and strong portfolios instead if candidates are available, as the education tends to be more well rounded. Devry graduates are expected to be entry level employees who will still require on-the-job training. But, Devry graduates will generally have a baseline of demonstrably useful skill in their chosen discipline: a hiring manager can trust that they have basic programming or asset creation skills, have worked on small-team projects, and have demonstrated that they can see something through to completion. They will have a portfolio demonstrating their basic skills. To compete with these people for a job, you first need to be applying for the same entry level jobs (not claiming you will revolutionise the industry). You will need similar demonstrably useful skills (you can't just say you have them, you need proof). You need a similar portfolio of work you have completed, where the interviewer can be reasonably sure of what your contribution is. Once you're on a par with those things you'll need to pass the interview: if a seemingly equally qualified candidate seems more likeable they will get the job before you. If you seem full of yourself you are less likely to get the job. If you can't communicate with others clearly you are less likely to get the job. Let's be honest: as you've presented yourself, it's perfectly normal and correct that a Devry graduate should get a job you miss out on - but those people aren't getting the jobs you seem to feel entitled to anyway, so there's not really any point repeatedly mentioning them.
  37. 4 points
    Strawberry Alert: Day 1 Today I have started working on the Week of Awesome V challenge. The working title for the project is Strawberry Alert. I generated it randomly and it is very unlikely to change due to time constraints. The Project The themes I want to try are Alien invasion and Castles. My intention is to create a side scroller where the hero must defend her castle from an alien invasion. With this project I want to explore whether functional reactive programming can be successfully used in games. I intend to capture the user input and time effects into streams, apply map-reduce to these streams to generate the game state, and finally render that game state to the screen. I will be happy if I can deliver something playable by the end of the week. Unfortunately, this week I'm back to work after vacation and I've got a few social commitments that I must honour, so I expect to be able to dedicate only about twelve hours more to the project. So far, I have managed to put together a parallax background and the walking animation for the hero sprite. The Art I am using a hero sprite and castle tiles created by Jetrel. I still need to find sprites for the alien enemies. The Tools I will target the browser and create my game using JavaScript. My weapons of choice are: pixi.js: a rendering library for WebGL and Canvas. cyclejs: a functional reactive framework. xstream: a stream library designed to work well with cyclejs. The Links The code is available on GitHub and, since it is a browser game, I will deploy my daily progress so that you guys can try it out. GitHub Game
  38. 4 points
    This year I didn't have any preparation post because I was busy getting Tiled maps to works with my engine. This is because I want to make an Earthbound-like RPG for the Week of Awesome. So you can imagine I'm quite happy with one of the themes being "alien invasion" since that's literally what happens in Earthbound. The other theme I've chosen is "chain reaction", which will apply to the gameplay although I won't say yet in what way. It's better to keep it a surprise. Also for this year I wanted to use existing art rather than having to make it myself. Originally I wanted to team up with an artist but since that didn't happen I had to look elsewhere. So it's a good thing I know about opengameart where I found this pixel-art pack in a style very close to that of Earthbound. I did have to tweak the textures here and there though. https://opengameart.org/content/isaiah658s-pixel-pack-1 The game I'm going to make will take place in the woods so I needed to place a lot of trees in the Tiled map. Unfortunately drawing multiple tress over each other proofed to rather difficult. Initially I just tried making multiple layers in Tiled with different depth values, but the problem is you have to keep creating layers if you have a lot of trees in a line from top to bottom. So that gets messy really quickly. The current solution I've come up with is to create a patch of forest in the tile sheet so that I have tilable pieces of forest that I can copy over the map. It's a lot better but very error prone, it's very easy to place a tile in a way that makes it look like part of a tree is missing. Maybe I'll find a better way though. As for the main character, he can only walk around a simpel map right now. Also the game doesn't have any name yet so the exe is just called "main". I'll come up with the actual game name later. Download link: http://www.mediafire.com/file/ciizr3ubrizid7d/main_v0.0.1.zip Tomorrow I hope to get started on the most important part of the game: the turn-based battles with the aliens.
  39. 4 points
    Yes. This is because Pygame is based on ancient technology that is embarrassingly out of date. Pygame is one of the only systems that expects to draw to the screen using old technology. Pygame uses SDL 1.2. SDL.1.2 uses DirectX 5, specifically DirectDraw for graphics. DirectX 5 is literally 20 years old, written for a time when a typical screen was 640x480 and graphics cards were esoteric add-on units.
  40. 4 points
    Hey! Never ever give up on that I haven't played the game but it seems polished and captivating by looking at the images on steam and your blog posts. Good job on coming this far already. This is not bullshit talk but a really honest opinion. Congratulations! A small detail: I would consider lowering the price on steam. I am not saying that it doesn't deserve the price (I can't tell how it should be valued at since I didn't play it) but people rarely trust "new games" so they are probably not willing to spend 13 dollars on them. I am not saying it is not a fair price but for now it might be high. If I were you I would lower the price by a little or even promote the game by offering it to some people (as competition prizes is a great idea too) and only then increase it. All the hours you spent were not wasted for real. Keep up the good work!
  41. 4 points
    WARP uses CPU so floats should behave IEEE compliant. Don't rely on this for GPU. At least assume they can behave differently. Probably the debugger emulates the instructions on CPU, too. You can check for NaNs in HLSL though: if(isnan(whatever)) return float4(1.0, 0.0, 0.0, 1.0); // Red alert, this is not a drill Final note: Instrumenting your HLSL code can of course rearrange the instructions and give different results. And then hide the bug
  42. 4 points
    So glad I asked the question, without your replies I would have wandered blindly into this unforgiving area of game dev. I'm going to stick around gamedev and learn some more about development before I dive into it. Thanks guys, I really appreciate the pointers!
  43. 4 points
    Work is how a lot of people value there lives, yet it isn't the only way. The idea of people not working is alien to us now, yet the same can be said about our lives. Think of explaining banks and money to your caveman ancestors. There should be something after money, yet even if we where shown what it was, chances are that we wouldn't be able to understand why people of that time value it.
  44. 4 points
    I've been developing on Microsoft Windows for a long time, since around 1992/93, when I got my first PC. Various other platforms before that, but I've pretty much stayed with it, not because it is a technical marvel (it's not), but based on the idea that it was the most popular OS so it should be easy to get programs running on other people's machines. Coupled with this (and no doubt because of this) there is also loads of good software for development, which had made it the 'default' choice for me. Don't get me wrong, I have certainly admired certain aspects of the various Apple OSes over the years (especially when they embraced BSD), but been put off by having to relearn the 'backwards' way of doing everything, and rightly or wrongly the suspicion of a 'control freak' walled garden approach, where you are not in control of the computer, Apple are. And don't get me started on my experiences of having to use iTunes to do something as simple as transfer a file over usb from a Mac to an i-something. And the obvious bias towards monetizing every aspect of the experience. In contrast I sometimes feel that Windows is *overly* open, exposing too much to developers, allowing them to too easily 'hijack' your PC and take over its resources for their own purposes at startup, as well as a series of insecure 'technologies' that seem more appropriate for malware authors than legit developers. It seems to be designed so that the OS will run slower and slower the more apps you install, until you give up and re-install windows. Along this line comes the other unpleasant thing I found with windows, that a lot of the software would rely on some other flavour of the month technology being installed as a dependency. Want to use a text editor? No, first you needed to spend half a day installing the latest huge bloated .NET runtime, to find it probably breaks some other app. And for something that is meant to be backward compatible, certain software companies (particularly Microsoft themself) seem to go above and beyond the call of duty in making their software incompatible with anything but the latest builds of the OS. And so we come to my personal last straw .. I spent some time last year evaluating different IDEs, and preparing projects, converting code etc, until I finally settled on using Visual Studio 2017, which was in the final release candidate stages at the time. The first version worked great until it expired. Then I tried the updater, which failed miserably at installing the next version, so I had to manually tweak things until it installed. Finally I came back from holiday 3 weeks ago to find that the 'final final' RC candidate had expired, and I was required to install the release version. Unfortunately I found the installer refused to work on my system. During the time between the RC and the release, they managed to screw up the installer (of all things??). So I was left unable to do any work until I had it resolved. I spent several days backing up my PC and trying to update it, but even with the windows updates no joy with the installer. I resigned myself that I had a choice of either buying a new hard disk and installing windows 10, or buying a new PC. Given I didn't want to risk losing my old work, I went for a new PC, even though my old one was perfectly adequate. £650 or so later I had ordered a fanless kaby lake system. During the order I had the choice of OS to put on it. I had originally planned to put Windows on it, but thought what the hell, I should have another play with Linux, as one of the options was Linux Mint, and I could be sure the hardware would all work, so it should be easy. While I waited a few days for the build, I did some research into Windows 10. Unfortunately I became more and more disillusioned the more I read. While I'm sure technically the OS has got better over the years, I've heard only disturbing things (from 'the register' etc) about the roadmap Microsoft is taking with Windows. One of the things I hate about Windows is the need for updates, and the way you are left to pray during the process that they don't break some other bit of software. So usually I turn automatic updates off, and carefully manually select any if they are really required. Not so with Windows 10! As (allegedly) the 'last' version of windows, it will now automatically update itself, forever, whether you like it or not. That's nice to know that if you are a business, you have the very real possibility of waking up one morning to find Microsoft have borked your work and there's absolutely nothing you can do about it. This is clearly a showstopper for many people, for instance having a meeting to show clients the next day and finding your PC has been remotely broken by some well meaning folks who I'm sure have your best interests at heart and not theirs. But it doesn't end there, no now the operating system is designed to take your personal info, searches, work etc etc and send it (without your permission) to Microsoft central command mothership. Simple, you turn it off, you would think, except that, apparently, it seems you can't turn it off. So you think you will block the MS servers in your firewall etc. No dice, as the OS apparently ignores these rules because slurping your private data is too important. And even if you think you've worked a way round this, you only have to leave the PC till the next morning, for the next AUTOMATIC update to circumvent your attempt to circumvent the data slurping. Honestly, there must be laws against this kind of thing. All this made me realise I had to seriously think about moving off windows as a development platform in the longterm, and that time may just be NOW! Several of my old dev colleagues had by now moved to other platforms, notably a lot have moved to Apple. I admit I have an irrational phobia of all Apple products, so the only choice for me was to investigate Linux. I only had some *very* basic grounding in unix (having done some pascal on unix machines at Uni), and having played with linux on my Asus EEE netbook many moons ago. So my experiences, in the next blog post, should be useful for anyone who is an absolute beginner like me. Suffice to say, it has been a very difficult slog learning the basics and converting my code, but I have *finally* got my libraries and game code working, and I am now a convert. The whole Linux experience seems light years ahead of windows. I may still end up having to install windows in a VirtualBox machine, but I haven't had a need as yet. Next blog post will be my migration experience...
  45. 4 points
    So you impose a cost to ALL code using bitwise shift because someone once wrote a bug? Most functions have rules about their use, such as not passing null values as parameters, or ensuring elements are within a legal range. This is no different. Shift operations have a mandatory range between zero and the number of bits of the type. Passing a negative shift distance is a bad parameter, exactly the same as if the programmer had passed an invalid object address or dereferenced a null pointer. Don't do that in the first place, then you don't need to write special code to handle the buggy code.
  46. 4 points
    Can you? Yes. Should you? It is a STRONGLY discouraged practice. Generally in programming you want to minimize the amount of coupling with other systems. You've got your collision system coupled with a texture system, which doesn't seem to make any sense to me. What does physics collision have to do with object texturing? You're suggesting increasing the coupling even more. Not only is the physics coupled to rendering, but now the object is coupled with the entire Application entity. Far better for systems to work independently, and there are many great patterns that work with this. One is forwarding commands to be handled by the appropriate level. Your collision system might pass an event or call a function on the object when the collision takes place, now the collision system knows nothing about textures; the object itself may not know about the details, but may have a component that is interested in the response so it calls the component's function on collision; the component already knows the texture and it also knows to change in response to a collision.
  47. 4 points
    If an object needs a reference to the TextureManager to do its job, then give the object a reference to the texture manager. You can pass it in when the object is created. Better still, have the object grab these textures ahead of time, so that when the collision happens, it already has them ready for the change, without needing access to the TextureManager.
  48. 4 points
    You could use them, or keep your sky dome and in the vertex shader do something like: //... some code posH = mul(inputPos, viewProjMtx); // this is your SV_Position output posH.z = posH.w; // when the divide by w occurs, this will make the depth 1.0 (far plane) //... whatever else You could also just use a full-screen triangle or quad and use the same "push it to the far plane" logic. Then in the pixel shader, color it based off the y component of a view ray (a ray from starting at the camera and extending out into the scene) - all depends on how fancy you want to get. If you stick with the dome, make sure you only transform it by the camera's position, and not rotation - otherwise the entire sky will spin as the camera spins.
  49. 4 points
    I'm locking this thread for now. Neither GDNet nor its moderators, administrators or members are qualified to offer advice or support with regard to mental health concerns and suicide. Ghonchi-- I urge you to seek counseling and support online or through whatever channels available in your area for your personal mental health risks. You can message me directly if you need help finding available treatment programs or online counseling services. GDNet can provide technical and creative support and input for game development, but as many other members may suffer from similar mental health issues, this thread may pose a threat to the well-being of the rest of the community. Concerning PC procurement, you can start a new thread provided you stay on subject.
  50. 4 points
    Welcome to GDNet’s For Beginners discussion forum! If you’re new to game development and are looking for some help navigating the many choices and challenges of the field, this is the place for you. If you’re a seasoned pro and are looking to pass on some of your wisdom to the next generation, this is a great place to do it. Additionally, please consider joining our Discord server to engage in real time with other game developers from our community. There are some simple ground rules the moderation team enforces in this forum, in addition to GDNet’s general community guidelines: For Beginners is a forum for all disciplines: programmers, artists, designers, composers, and everyone else. In other words, it’s not just programming questions that are acceptable here. Any questions from anyone who is just getting started in any aspect of game development are fair game. The primary exception to the above are questions dealing with career advice: how to break into the industry professionally, what choices to make regarding school choices, and so on. Those belong in our Career Development forum. This is place for beginners to ask questions and get answers. It’s not a place to post tutorials or articles, or links to tutorials or articles, that you think might be helpful to beginners. For that, you should use the Your Announcements forum. If you’re a beginner posting a question in this forum, please try to include as much information about your problem as you can. Be very specific. Include the exact text of any error messages you are getting. If you’re a programmer including code, include the exact code. You are much more likely to get a good answer quickly this way. If you are a grizzled veteran answering questions, please remember that even you were a neophyte once, and be particularly cognizant of the fact that the audience here may not have the years of experience you do. Try to be as precise, clear and forgiving in your responses as possible. Please avoid derailing topics into tangential discussions of technical minutiae and subtle pros and cons. Topics that drift too far afield of the original poster’s query may be reigned in. Please do not attempt to mark threads as “solved” or otherwise “closed” because you think the question has been answered. Sometimes there’s more than one side to a problem or solution, and we encourage discussion so long as it stays relevant to the original topic and to the experience level of the asker. “Solved” edits will be rolled back. Be nice, respect your fellow members, and remember that we can usually all learn something from somebody else.