Leaderboard


Popular Content

Showing content with the highest reputation since 07/23/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
    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.
  4. 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.
  5. 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.
  6. 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
  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
    Most likely GetOwner() is crashing or returning nullptr. Don't call functions like that in the constructor, because you have no idea what state the object hierarchy will be in. The correct place to initialise any non-trivial values in UE4 is BeginPlay(). (Or maybe InitializeComponent, or similar.)
  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
    Making your formatting consistent is good. Just understand that everyone is going to do things differently, so it doesn't actually matter what you choose to do, so long as you are disciplined about doing it the same way throughout your code. There is no such thing as a universal formatting standard for code. If you want to format your code to be consistent, which is again a good thing, you should use a formatting tool like clang-format or Visual Studio's Format Document command (found under Edit menu -> Advanced). There's no need to do it by hand.
  26. 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:
  27. 4 points
    I disagree with at least parts of the above replies. The PayScale source is talking about general software R&D, not what it means for games, and while dedicated positions are comparatively rare, part of the reason they are more common than you might think is because they aren’t just for the very large companies. That some companies have created their own fancy terms for it (“Advanced Technology Division” for Square Enix for example or “Core Tech” at Deep Silver Dambuster Studios) may add to the illusion that it is rarer than it is. Perhaps the best way to answer is to show actual R&D recruiting pages from companies, and for the ones where I actually worked I can give more details. tri-Ace (~130 employees) http://www.tri-ace.co.jp/en/recruit/category/programer.html#programer_02 tri-Ace has its own game engine called ASKA Engine. The R&D team works on the engine, which was built by them from scratch. Since the engine is fairly fully fledged now, current tasks are mostly related to maintenance and optimizations, but new features are still constantly being added, from various types of editors, network code, new graphics API support, tool-chain improvements, etc. The team is led by tri-Ace CEO/CTO Yoshiharu Gotanda, who is responsible for helping advance the state of real-time physically based rendering. A mathematical prodigy, he creates new rendering equations himself and gives presentations at Siggraph. http://research.tri-ace.com/ Interesting reads are his physically based Blinn-Phong, layered models, and his cheaper and more accurate Oren-Nayar approximation (http://research.tri-ace.com/Data/s2012_beyond_CourseNotes.pdf), and his film tonemapping (http://research.tri-ace.com/Data/course_note_film_simulation_for_videogames.pdf), among others. The engine is released to the game teams on its own time, and game teams are not allowed to know when it will be released. Schedules are usually not tied to any specific project, so you typically do not have crunch and long hours. But there may be critical bug patches that need to be made or critical feature support here-and-there. Square Enix (~3,924 employees) http://www.jp.square-enix.com/tech/index.html# While a majority of their R&D department was dedicated to the Luminous Studio game engine and Final Fantasy XV, members in this department are actually more free-floating between all the projects as needed. There are distinct teams within it dedicated to graphics, effects, sound, animation/physics, etc. But team members don’t only work on Luminous Studio. They are sometimes moved to other projects where they will have to apply their skills to a new code base. They cover the full R&D spectrum, meaning they accommodate people who consider themselves more academic and less of a programmer, people who prefer just to implement, and everything between. The academics create new techniques and publish new whitepapers, pure programmers take white papers and implement them (from any source, not just the internal academics). The schedule is a bit more hectic, but that doesn’t mean more crunch time than you would expect anywhere else. It mainly means shifting gears as your tasks change dramatically. Deep Silver Dambuster Studios Ltd. (~100 employees) I won’t discuss why they temporarily removed their “Core Technology” (what they call R&D) positions, but here is how it looked 1 year ago: Senior Programmer – Core Technology Deep Silver Dambuster Studios have an exciting opportunity within their highly talented and experienced Core Technology department for a Senior Programmer. You will be working on an established AAA title for Next Gen Consoles and PC platforms and your primary remit will be to help keep our Engine, Editor and Tools on the cutting edge. We’re looking for someone who understands the processes involved in making a first-class, AAA modern game, and wants to make a big difference to our development team’s workflow. Main Duties and Responsibilities: Work with the Core Technology team leads to maintain and optimise existing systems, develop new engine features and build tools that give greater efficiency to our development pipeline. As a senior member of the Core Technology team you will be expected to work closely with other team members, leading by example and helping to ensure that a high level of coding standards are achieved and maintained. The R&D efforts here go towards maintaining an engine—optimizing, fixing bugs, adding features that might be needed for a game, etc.—and its tool chain. As game technology continues to move forward, there is a never-ending slew of new graphics techniques to add, new texture formats to support, tools to create and view those textures, etc. Development here is more closely tied to the game team, but many specific tasks are not. Crunch doesn’t happen that often. I can’t give too many details on the next few because I have never worked there, but here are a few more I know exist. I let their recruiting pages describe their roles. Naughty Dog They call it ICE (Initiative for a Common Engine). https://www.naughtydog.com/greenhouse/job/590792?gh_jid=590792 https://www.naughtydog.com/greenhouse/job/590787?gh_jid=590787 Guerrilla Games They call it their “Tech Team”. Since they are part of Sony, I expect some overlap with ICE, but as it is its own studio they will have their own set of tasks, schedules, points of focus, and demands. https://www.guerrilla-games.com/join/senior-graphics-programmer 2K Games No special term for it (check for jobs with “engine”). SENIOR SOFTWARE ENGINEER - GAME ENGINE SENIOR ENGINE PROGRAMMER Blizzard Entertainment No special term for it (check for jobs with “engine”). LEAD SOFTWARE ENGINEER, ENGINE SENIOR SOFTWARE ENGINEER, ENGINE Double Fine Productions Now that you know what an R&D programmer for games mostly does, you can spot hidden R&D positions. Senior Programmer Note that I found 2K Games, Blizzard Entertainment, and Double Fine Productions just by using GameDev Map, clicking on my area, and checking just a few entries on the first page. https://gamedevmap.com/index.php?location=San Francisco Tiny studios tend not to have these positions, but medium, large, and X-large do. There just seems to be so few R&D positions out there because many studios either call them something fancy or do not have a term for them at all. But almost every company is either making its own engine or using a 3rd-party engine such as Unreal Engine 4, and in both cases there is a need for people to keep these updated, add feature support, optimize, and fix bugs. Also note that even the Japanese companies and Guerrilla Games in Amsterdam seek English-speaking people. R&D means reading research papers and going to Siggraph and other events, so regardless of the country R&D positions always request English skills. L. Spiro
  28. 4 points
    Dedicated R&D positions in the games industry are comparatively rare. You'll likely only see them at very, very large studios, if at all. Most development positions will involve some varying amount of R&D (usually during the early phases of a project) into varying subject matter. Most of the time, you'll see positions related to graphics and AI doing the most of it. Often this "R&D" won't be so much developing entirely new methods of accomplishing things (although sometimes it does), but researching how to adapt other people's entirely new methods of accomplishing things to the project at hand.
  29. 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.
  30. 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?)
  31. 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...
  32. 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.
  33. 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.
  34. 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
  35. 4 points
    Someone on my team had the genius idea of making our game multiplayer. I would hate that person if I wasn't on a one-man team. The basic idea of my game is it's a 2 player tower defense style game, where both teams have to build troops and defenses, and the first to kill the others home base wins. One side will be the alien invasionists, the other side will have castles. The attackers will have some kind of path-finding system, like clash of clans. It is my general strategy to get something playable on the first day, and work the rest of the week on polish. This time, sockets get in the way. Instead of the general client-server architecture, I need a symmetric system where both sides sent data to each other in the same way, and a third party can not join. At first, I tried using the python socketserver library. Both clients would start a server on startup, and prompt for a IP address. If you typed a address and pressed enter, the client would shut down the server and connect to the other server. The whole system was encapsulated and exposed only send, receive, and connect methods. The rest of the program did not care if it was client or server. There was one problem, however: Socketserver could not keep open connections. I could send messages from the client to the server anytime, but I could only send a message back as a reply. This was of course, unusable as no message might be passed for a few seconds, so a signal could come way late. I had found a answer earlier on stack overflow that used the sockets module directly as a server. At first, this seemed overly complicated, but having exhausted the earlier approach, and realized that using the same module for both client and server might save effort in the long run, I decided to go for that idea. I deleted all references to socketserver, and replaced them with copy-pasted code blocks from the answer, some of which I barely understood. The code I copied returned a new socket for every client. Since I need only one client, I decided to just delete the server and use this client object as soon as the connection was established. I then spent some hours figuring out why messages where being passed from one direction but not from the other, untill I suddently found that my recv() call was inside a if (self.mode==CLIENT) block. So much wasted time. Finally, I got both clients to sync state, as seen on the screenshot: Hopefully, tomorrow I will actually get some game mechanics done. Hopefully my system will not break outside a local computer. Hopefully, I can fix those ghastly castle sprites.
  36. 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.
  37. 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.
  38. 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!
  39. 4 points
    Pretty awesome that you released it, man. I wouldn't let a couple bad reviews get you down. Of course, it's easy enough to say that, but fear of exactly that kind of criticism is what has kept me from releasing stuff in the past. People can be dicks.
  40. 4 points
    Kavik, if you want people to take you seriously, don't tell them that they're stupid. Nobody will listen to you after you do that. They don't care about your decades of struggle. They don't care that you think you intellectually tower over them. They also don't care about the cosmic significance you think your idea has. If you can explain it, do so. If you can't, then work on your communication skills. Don't blame your audience for your own failings. Your writing has all the qualities of a classic crank. GEORGE HAMMOND claimed to have a SCIENTIFIC PROOF OF GOD. Gene Ray (Cubic) claimed to have proven he was above God, because he knew that, uh, something about there being four days at once in every day, because the Earth is a cube, or something, and that everyone else was stupid and evil. When other people read your writing, they don't think "boy this guy really seems to know what he's talking about", they think "Oh, another crank who thinks he's decoded all of the secrets of the universe." The #1 sign of a crank is that they say they're so smart nobody else can even understand how smart they are, and that their ideas are so good, nobody else is qualified to judge them. The truth is, a lot of a time nobody can understand a crank because the crank spouts of a bunch of hyperbolic jabber about how great they are, but never actually explains their idea in sufficient detail to tell whether or not it's worth anything. Your writing fits this pattern. They often use the excuse that their invention or discovery is so revolutionary, they won't publish it, for fear that THE ESTABLISHMENT will steal it from them. Your writing also fits this pattern. If you don't want your idea out there, why are you telling people about it? Cranks tend to make claims that are rejected out of hand because they're enormously overstated. If someone else told you their work was then you would probably ignore them because that sounds impossible. It seems very, very, very unlikely that you have actually arrived at the ultimate goal of simulation design. If you had, wouldn't you be out there making the best simulations anyone has ever seen? Clearly, you're not, if your best hope of finding funding is posting angry rants on game development websites. What response are you actually looking for? What would you consider a successful interaction? Someone simply giving you a million dollars to make your game, sight unseen? That will never happen, because people with "revolutionary" ideas are everywhere, and very few of them have the chops to realize those ideas. If you can, make something with your idea. Make it a phone app and put it on the Android app store. Make it a board game and put it on Kickstarter. If it actually works, people will come calling. If not, well, maybe your idea isn't as good as you think it is. Finally, "Rube" is a terrible name. It invites unflattering comparisons between the name of your product and your online persona. Edit: Claiming to be the inheritor of hundreds of years of knowledge, but you're the only one who actually understands it all, is another classic crank behavior. Again, if your idea is as good as you say it is, put out a proof-of-concept, just enough to demonstrate its superiority, or else everyone will conclude you talk a good game but have nothing to back it up. Second edit: Plenty of people have released free versions of games, then gotten funding to produce the real version. If you say your idea is so magical you can't show it to anyone for fear of being copied, then the natural conclusion is that it's not that good, but by never showing it to anyone, you avoid being found out as a fraud. https://en.wikipedia.org/wiki/History_of_perpetual_motion_machines
  41. 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!
  42. 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.
  43. 4 points
    Capitalism will never die, just change form. As long as humans can value something, there will always exist a need to have more of that value. So if AI did provide for humanity then we would find things worth more than basic necessities. For example when we entered the industrial age, the farmers didn't all just stop farming because food output increased a thousand fold. They didn't hangup there farm hats and just laze around all day, setting up some kind of slave system. People just expanded there view and moved on, the same thing should happen if AI do all the basics for us, we will just focus on the advanced an beyond.
  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
    Service locators are to singletons as singletons are to globals; one step improved, but still pretty bad. I mean, I've used service locators before when hacking something together quickly, but they have almost all the same problems that a singleton does: global access to an object leading to high coupling global instances of an object meaning more shared state poorly-defined object lifetimes (usually) superfluous code enforcing that you only ever have 1 object, when there may be times you can make use of multiples Basically, I try to take a step back when thinking about code like this. If I find myself thinking "lots of bits of the code need access to object X", I know that is not really true, and so I try to find one of several strategies for resolving that. e.g. if object X is basically a resource provider (e.g. TextureManager), can we just extract what we need at initialisation time, and pass those objects in directly, instead of querying for them later? if object X is basically an event sink (e.g. SoundPlayer), or an event source (e.g. InputManager) can I just connect to it via generic events/signals/delegates/std::functions/whatever, performing the connections once and then never needing to refer to the object again? if object X is some sort of helper object which doesn't maintain any state, can I make the methods into free functions that can be composed arbitrarily (C, C++, Python, Javascript)? Or can I change the object into a static class (e.g. in C#) for similar effect? if object X is a combination of the above things, or is just accessed everywhere because it performs a lot of different roles, can I split it into separate objects X, Y, Z, each of which might be easier to handle?
  48. 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.
  49. 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.
  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.