Popular Content

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

  1. 8 points
    Nope. If you are a good software developer or a good artist, you can go a long way without really caring about games. Knowing more about games will help, certainly. And you can't get away without knowing about games technology. And I'd certainly argue that it's important for designers to have a broader understanding of the field. But they are only one part of the development process. You don't. You have to choose. It's a sad fact, but there are just not enough hours in the day. If you want to spend 8hours a day or more on MMO raids or whatever then that is a fun hobby to have, but throw in a day job as well and you simply do not have enough time to teach yourself enough to get good at making games. Play fewer games, play shorter game sessions, and prioritise what is important to you.
  2. 8 points
    Take the following post as coming in semi-moderator capacity; I hope there is something useful in it, but this is not going to be the start of a lengthy debate over something that we have been over time and time again. First, this is not the place to complain about what other people are interested in or not. The forum is called "game design and theory", and you're welcome to discuss those topics. It's also not the place for blatant hyperbole - you say "not a single person has said a single word too me about any of it" and yet there are over 70 comments on your blog. Most likely you are just not willing to hear what people have said to you. What I don't think you appreciate is that you have spent thousands of words talking around your concept, but hardly any time talking about what it actually is. Not 'what it means for games', not 'how important it is', not 'how everything could change if this existed'. You keep asserting that it's important, but you have not proven or demonstrated it in any way. You don't need a degree from Devry. You don't need to write 500 pages about it. You just need to communicate your idea clearly in such a way that you can demonstrate that it will do what you need it to do. Stop talking down to people and saying they are "so far behind actual simulation design" - learn to communicate better. You don't build interest by repeatedly insisting that people should be interested and insulting them when this doesn't change. When a startup wants to get interest from investors, they will create very short and very effective descriptions of what exactly their product or service is, and how it will deliver benefits to users/players/the market/whatever. It should be possible to communicate all the benefits in about 10 pages of Powerpoint at most, and about one sentence at best. They don't expect people to read 500 pages of blogs and neither should you. Alternatively, you can do what most other game designers with a 'big' idea do; make a prototype yourself. If the idea is as good as you say it is, the prototype will prove that, and you'll get interest and funding. If it's not, you won't.
  3. 7 points
    >>What do I have to do to finally be seen as at least the equal of someone with almost no experience, and even less knowledge? Build a portfolio, apply for jobs and go to interviews, like all the rest of the people do. Btw, I again remind you that, when you were talking about your sports mod and how good you are at designing those kind of games, I offered you my services as a programmer in order to make a prototype together(I was interested in making a sports game myself back then). Sure, we weren't going to make an AAA sports game, but we would have an awesome(if your word was true) playable prototype that we both could showcase. You declined, because your grand designs can only be made with multi-million teams and anything else is beneath you. So I went on my way, worked on my indie game, now have a job at EA DICE. Not as a designer, as a programmer, but I work with designers every day, making the tools they use to make AAA multi-million games. See, you *could* have a connection there today, but you don't accept anything less than people bowing down to you and handing you 100 million. So there's that too.
  4. 7 points
    I advise you to not aim to learn "everything" (in Unreal or other technologies), as it can be a futile endeavor and lead to frustration because of the huge ammount of content. Instead, aim to learn what you need to build your ideas (and most of the time it's much less than "everything"). Unreal has a steep learning curve, so it's good to break the learning in manageable chunks. Anyway, Unreal site has a ton of learning resources, so it's a good starting point. They also have a Youtube channel, so check it out and see if it helps. Other than that, you could check online courses such as this on Udemy . I'm doing it, and liking so far.
  5. 6 points
    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.
  6. 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!
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 5 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
  12. 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.)
  13. 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.
  14. 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.
  15. 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).
  16. 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.
  17. 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.
  18. 5 points
  19. 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.
  20. 5 points
    It has to be the same mutex. Otherwise they're not interacting in any way to prevent the other thread from accessing the queue. The point of a mutex is that it is shared, like the thing it is protecting, different threads must acquire it before proceeding to use the protected resource, and only one thread can hold it at once. The other threads will block if they try to access the mutex, until the mutex is freed up by whichever thread acquired it. This means only one thread can access the resource at once - which is the intended behaviour. There are some esoteric situations where people use multiple mutexes for various functionality but that is not the usual situation.
  21. 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.
  22. 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.
  23. 4 points
    Greetings and Salutations. I can't think of anything that justifies the risk to add at this stage, So end of day seven for me. I spent the day mostly adding polish, Which includes: Laser pointers for the turrets, No ammo sound, Low health sound, Changed the colour on each alternative entry in the credits. I thought I solved the performance issue (which was some kinda base static light pass, Which I could find no info on ), It runs faster in the editor tho. The AI(FrogMen) is a bit iffy, They should shoot or melee you on sight. Yet they don't most of the time, But the work well when they do. There is a text field in the options menu you can use to execute any UE4 console command, I have included a file "CVars.txt" with some graphics related commands. You may want to drop the quality setting down to medium, I had to for the game to hit 60 FPS. This has been fun, I look forward to playing the other entries. I may even do a review of them. Dang, I forgot to credit @riuthamusfor his asset pack (Sorry @riuthamus). Link to my entry: Here Title: Invasion of Planet Frog And the picture: Thats all for now, Thanks for reading.
  24. 4 points
    Day 7! What a wonderful week! Today we tried to finish the game. We haven't implemented anything special, just bug fixes and gameplay enhancements. Here's the game: https://mega.nz/#!K40gGKyC!k-nuSvEdhKluAhznQvr3RFEC70ErwcXyjoxHF7QvNiU After I write this entry, I'll post the package on the site. Hope you enjoy! Thanks for reading and following the development of our game during this week!
  25. 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:
  26. 4 points
    Today I've implemented the chain-reaction part of the game. In the battles, if you defeat one of the aliens, then it will generate shockwaves that damage the aliens that were standing on the left and right. Even better, if a shockwave manages to defeat an alien it will create a stronger shockwave. And, you guessed it, this can happen one more time, creating the strongest shockwave. I intent this to be the only way to defeat certain enemies later in the game. I've also added an experience system to the game. So if you defeat enough aliens Harris will level-up and gain extra hitpoints and attack power. Although I'm not sure increasing the attack power this way is a good idea. It seems like you become overpowered really quickly this way. There are also objects in the game now that can be interacted with. Simply walk up to them and press V. Lastly the game-over screen now displays "GAME OVER" (surprising, I know) and asks if you want to continue. Tomorrow I plan to implement the boss for this game and change the level to roughly how it should look like in the end. That way I'll have something to submit already. Download link: http://www.mediafire.com/file/2mvbb3r0bcjkrcn/ThunderStruck_v0.0.4.zip Controls: Arrow keys for movement, V for confirm, C for cancel.
  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
    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...
  31. 4 points
    I'm happy to say that I've successfully added one of the two themes I chose to my game. The aliens! They are created at specific points in the map and run towards the player until they collide. At that point the screen will fade out (no battle swirl yet) and a battle will start. It's interesting to note that, just like Earthbound, other aliens can still continue to run towards the player while the screen is fading out. And if they make contact, then they too will be added to the battle. The battle itself isn't anything special yet though. It just displays the in-battle sprites of the aliens and you can attack by pressing the V button. Also the aliens won't attack back yet, which might be a bit disappointing. You can also change the selected alien by pressing left or right, but which alien is selected isn't displayed in any way yet. So that's not particularly useful. By the way I drew the in-battle sprite for the alien completely by myself. It won't win any awards, but I like to think it's pretty decent. Another thing to note is that I recently started using co-routines for animations in Python. Effectively they are just generators that use the yield-statement to give control back to the rest of the update-tick. They are quite effective in preventing the need for stateful member variables (fadeTimer, coolDown, etc.). I might write an article about it later if there doesn't exist any yet that already does a proper job at explaining them. Download link: http://www.mediafire.com/file/ciwguyrx82844l4/main_v0.0.2.zip (Reminder: press V to attack!)
  32. 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.
  33. 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
  34. 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.
  35. 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.
  36. 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.
  37. 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!
  38. 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.
  39. 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
  40. 4 points
    WARP uses CPU so floats should behave IEEE compliant. Don't rely on this for GPU. At least assume they can behave differently. Probably the debugger emulates the instructions on CPU, too. You can check for NaNs in HLSL though: if(isnan(whatever)) return float4(1.0, 0.0, 0.0, 1.0); // Red alert, this is not a drill Final note: Instrumenting your HLSL code can of course rearrange the instructions and give different results. And then hide the bug
  41. 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.
  42. 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.
  43. 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...
  44. 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.
  45. 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?
  46. 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.
  47. 4 points
    For an introduction to my reasons for migrating from Windows to Linux, see my previous blog post. Here I will try to stick to my experience as a Linux beginner, and hopefully inspire other developers to try it out. Installing Linux The first stage of course in migrating to Linux is to either install it on your PC, or try a 'live' version off e.g. a usb stick (or even try it on a virtual machine?). I can't say too much here, because I got my new PC with Linux Mint pre-installed, and there should be plenty of guides on google. I went for Mint because I had briefly tried Ubuntu a few years ago, and I liked the look of Mint and fancied a change. I knew it was based on Debian like Ubuntu so there should be lots of software. My first stage after unplugging my windows machine was just to take baby steps to familiarize myself with it, without running away in fright. After plugging in my network cable, I was away with Firefox browser. But after a few minutes I decided to install Chrome, as I am a fan and used that on windows (going with familiar!! safe space!!). This entailed installing software. Installing Software On windows, the process of installing software usually involves downloading an installer package from the internet and running it, and hoping it likes your machine windows version / hardware / dependencies. You can do this on Linux too (particularly for cutting edge versions of software), but there is also a far easier way to do it, via a 'package manager'. The package manager is actually the pre-cursor to all the various 'app stores' that have become popular on Android and iOS, but the idea is simple, you have a searchable database of lots of software you can install, usually simply with a click. It also has the magic advantage that it has a very good system for automatically working out the dependencies required by any software, and installing those for you too in the background, or for finding conflicts (if these do occur, when I have rarely had conflicts it has been because I've been trying to do something nonsensical!). I don't know whether it is my new machine, or linux, but the process of installation (and removal) is orders of magnitude faster than windows. It honestly only takes a couple of seconds for most of these installations. Anyway suffice to say I was very quickly running chrome, installing my favourite plugins, running my favourite websites. Accessing Windows Hard Disks The next stage was to get some of my data across from my old windows PC. This is where things get slightly interesting. Predictably enough, linux uses a different filesystem to windows, 'ext4' on my machine, whereas my windows external hard disk was formatted as NTFS. As is Microsoft's way (to discourage competitors, no doubt), NTFS is not public domain. The clever Linux devs have presumably reverse engineered much of NTFS, because you can mount and read from the NTFS disk. However, I am erring on the side of caution and not writing to NTFS for now, because from previous experience of exFAT on Android, it is possible that an incorrect write can bork the file system, and hence lose a LOT of work. My solution for now was to copy my working source code etc from the NTFS hard disk to my ext4 linux SSD. Longterm I intend to convert all my NTFS external hard drives to ext4. It would also presumably be useful if Windows could read from ext4 drives, but I don't know how easy this is as yet. Great! I had some data on my new machine. I tried some movies and they worked great in the in-built player, and VLC (which I installed). Image files loaded fine in the in-built viewer and in 'the gimp', which is sort of like the linux photoshop. I've used the gimp a little on windows, and am hoping it can do a lot of the photoshop duties. Blender For 3d models, I've been using blender on windows, and as luck would have it, this open source software is available and runs very nicely on linux. Was installed and loading my game models in no time. For development, this just left an IDE and compiler for c++ (my language of choice). Linux has a very handy standard compiler which is easy to install (g++ / gcc). This is where I might mention 'the terminal'. The Terminal Although the name windows has become synonymous with the windows GUI, it is important to realise that an operating system doesn't have to be irrevocably intertwined with a GUI system. In linux, the operating system can use several different GUIs, depending which flavour you prefer. Or none at all, if for example you are running a server. The way to talk to the operating system below the level of the GUI is a command line interface called 'the terminal'. There used to be one used commonly in windows too, the DOS prompt, but it is rarely used now. In contrast on Linux, the terminal is still very useful for a number of operations, unfortunately it can be a little scary for beginners but this is a little unjustified. To get the terminal up I just press Alt-T. You can list what is in your current directory by typing 'ls'. You can navigate up a directory with 'cd ..'. And you can navigate into a directory with 'cd MyFolder'. It will also auto-complete the folder / filename if you press tab. From the terminal you can do a lot of stuff you would also do from the graphical file manager (the excellent 'nemo' is built in to linux mint), such as copying, deleting, moving files. You can also manually tell it to install packages just like it would install from the package manager, with the command 'apt-get'. To install software, you need admin privileges (this is handy as it prevents malware from doing anything naughty without you typing in the admin password). To get admin you type 'sudo' before the command: sudo apt-get install build-essential This tells it to run as admin (sudo) to run apt-get, and install (or remove) the package called 'build-essential'. This contains the compiler and other building tools. IDE Unless you fancy yourself as a hardcore compile from the terminal from the getgo type of guy, you will also probably want to use an IDE for development. As I use C++, there are several to choose from, such as Eclipse, Code::Blocks, KDevelop, Code Lite etc. I went for QT creator, as I have used it on windows (again, familiarity!! baby steps!!). Once QT creator was installed, it was fairly easy to tell it to create a hello world app and test it, it worked great! This is where things got slightly more interesting. My current project is an Android game. I had been maintaining both a PC build on windows, and the Android build, with the platform specific stuff isolated into things like creating a windows, setting up OpenGL, input, and low level sound. OpenGL ES Where things got slightly confusing is that because I am developing for Android, I was using OpenGL ES 2.0, rather than the desktop version of OpenGL. On windows I had been using the ARM Mali OpenGL ES Emulator, which emulates OpenGL ES by outputting a bunch of normal OpenGL calls for each ES call. I was anticipating having to use something similar on linux, so I attempted to install the Mali emulator in Linux, however I had little joy. I was getting conflicts with existing OpenGL libraries used in SDL (which I intended to use for platform specific stuff). Finally after investigation I realised that my assumptions were wrong, and Linux actually directly supports OpenGL ES AS WELL as desktop OpenGL, through the open source Mesa drivers. I eventually got a 'hello world' OpenGL ES program working, and was convinced I now had the necessary libraries to start work. 64 Bit Conversion The next stumbling block was a biggie. For historical reasons, all my libraries and game code were 32 bit. I had been developing with the idea that a lot of Android devices were 32 bit, and I was hoping the 64 bit devices would run the 32 bit code (hadn't really tested this out lol). So I had been previously compiling a 32 bit windows version, and a 32 bit android version. And it soon became clear that my linux setup was compiling by default to 64 bit. No problem I thought, I should be able to cross compile. With some quick research I managed to get 32 versions of the libraries, however I had no joy with 32 bit version of OpenGL. It refused to install, and being a linux beginner I was stuck. I did some little research, but no simple path, and realised that maybe it was time to convert my code to 64 bit. Or rather, to have my code run in 32 bit and 64 bit. I had been (rather unjustifiably) dreading this, as I have a lot of library code written over quite a few years. As it happened, aside from some changes to my template library, the biggest problem was in the use of 'fixup' 32 pointers in flat binary files formats. I have been using this technique for a long time now as it greatly speeds file loading, and also helps prevent memory fragmentation. Fixup Pointers Essentially the idea with a 'fixup' pointer is you store into the file an 'offset' from a fixed point in the file to a resource, often the start, because there is no point in saving a real pointer to a file as it points to a (changeable) memory location. Then you can load the entire binary file as one big block, and on loading 'fixup' the offset pointer to a real pointer by adding e.g. the offset to the memory location of the start of the file in memory. This works great when the offsets are 32 bit and your pointers are 32 bit. But when you move to 64 bit, your offsets are fine (as long as the file is smaller than 4gb), but there is not enough room to store a 64 bit pointer. So you have a choice, you can either do some pointer arithmetic on the fly, or change your file formats to use 64 bit offsets / pointers. After a trial with the first method, I have eventually settled on going with 64 bit in the file, even if it uses a little more space. Of course the disadvantage is that it has meant I have needed to re-export all my assets. So at the same time as converting my libraries to 64 bit, the game code, I also needed to convert my exporters to 64 bit, and re-export all the assets (models, sprites, sound etc). This has been a frustrating big job, particularly because you are coding 'blind'. Normally when you program you will change a little bit, recompile, run and test. But with such a conversion, I had to convert *everything* before I could test any of it. Success! It has been demoralizing doing the conversion, I won't lie. But I have been so impressed with the operating system I was determined to make it work. And finally bit by bit I got the exporters working, re-exported, then the game, debugged. Got some crazy graphical errors, errors in the shaders that the OpenGL ES implementation didn't like (that's a whole other story!) but finally got it displaying the graphics, then did an SDL version of the sound this afternoon which is working great. One thing I will say is I should have been using SDL before, it is really simple and makes a whole lot of sense of taking out the eccentricity of setup code on different platforms (windows in particular is very messy). So to summarize I now have (nearly) everything working, compiling and running on linux. I still have to install android studio and try debugging an android hardware device through usb but I'm very hopeful that will work. Even if it doesn't it's not a show stopper as I can always use a second PC. I am gradually becoming more familiar with linux every day and even feeling I might get tempted to learn QT so I can do some nice 'native' looking apps.
  48. 4 points
    Below is my preliminary draft design for the AI system within Spellbound. I'm slowly migrating away from scripted expert systems towards a more dynamic and fluid AI system based on machine learning and neural networks. I may be crazy to attempt this, but I find this topic fascinating. I ended up having a mild existential crisis as a result of this. Let me know what you think or if I'm missing something. Artificial Intelligence: Objectives: Spellbound is going to be a large open world with many different types of characters, each with different motives and behaviors. We want this open world to feel alive, as if the characters within the world are inhabitants. If we went with pre-scripted behavioral patterns, the characters would be unable to learn and adapt to changes in their environment. It would also be very labor intensive to write specific AI routines for each character. Ideally, we just give every character a self-adapting brain and let them loose to figure out the rest for themselves. Core Premise: (very dense, take a minute to soak this in) Intelligence is not a fixed intrinsic property of creatures. Intelligence is an emergent property which results directly from the neural topology of a biological brain. True sentience can be created if the neural topology of an intelligent being is replicated with data structures and the correct intelligence model. If intelligence is an emergent property, and emergent properties are simple rule sets working together, then creating intelligence is a matter of discovering the simple rule sets. Design: Each character has its own individual Artificial Neural Network (ANN). This is a weighted graph which uses reinforcement learning. Throughout the character's lifespan, the graph will become more weighted towards rewarding actions and away from displeasurable ones. Any time an action causes a displeasure to go away or brings a pleasure, that neural pathway will be reinforced. If a neural pathway has not been used in a long time, we reduce its weight. Over time, the creature will learn. A SIMPLE ANN is just a single cluster of connected neurons. Each neuron is a “node” which is connected to nearby neurons. Each neuron receives inputs and generates outputs. The neural outputs always fire and activate a connected neuron. When a neuron receives enough inputs, it itself fires and activates downstream neurons. So, a SIMPLE ANN receives input and generates outputs which are a reaction to the inputs. At the end of neural cycle, we have to give response feedback to the ANN. If the neural response was positive, we strengthen the neural pathway by increasing the neural connection weights. If the response was negative, we decrease the weights of the pathway. With enough trial runs, we will find the neural pathway for the given inputs which creates the most positive outcome. The SIMPLE ANN can be considered a single cluster. It can be abstracted into a single node for the purposes of creating a higher layer of connected node networks. When we have multiple source inputs feeding into our neural network cluster and each node is running its most optimal neural pathway depending on the input, we get complex unscripted behavior. A brain is just a very large collection of layered neural nodes connected to each other. We’ll call this our “Artificial Brain” (AB) Motivation, motivators (rule sets): -All creatures have a “desired state” they want to achieve and maintain. Think about food. When you have eaten and are full, your state is at an optimally desired state. When time passes, you become increasingly hungry. Being just a teensy bit hungry may not be enough to compel you to change your current behavior, but as time goes on and your hunger increases, your motivation to eat increases until it supersedes the motives for all other actions. We can create a few very simple rules to create complex, emergent behavior. Rule 1: Every creature has a desired state they are trying to achieve and maintain. Some desired states may be unachievable (ie, infinite wealth) Rule 2: States are changed by performing actions. Actions may change one or more states at once (one to many relationship). Rule 3: “Motive” is created by a delta between current state (CS) and desired state (DS). The greater the delta between CS and DS, the more powerful the motive is. (Is this a linear graph or an exponential graph?) Rule 4: “relief” is the sum of all deltas between CS and DS provided by an action. Rule 5: A creature can have multiple competing motives. The creature will choose the action which provides the greatest amount of relief. Rule 6: Some actions are a means to an end and can be chained together (action chains). If you’re hungry and the food is 50 feet away from you, you can’t just start eating. You first must move to the food to get within interaction radius, then eat it. Q: How do we create an action chain? Q: How do we know that the action chain will result in relief? A: We generally know what desired result we want, so we work backwards. What action causes desired result (DR)? Action G does (learned from experience). How do we perform Action G? We have to perform Action D, which causes Action G. How do we cause Action D? We perform Action A, which causes Action D. Therefore, G<-D<-A; So we should do A->D->G->DR. Back propagation may be the contemporary approach to changing graph weights, but it's backwards. Q: How does long term planning work? Q: What is a conceptual idea? How can it be represented? A: A conceptual idea is a set of nodes which is abstracted to become a single node? Motivators: (Why we do the things we do) Hunger Body Temperature Wealth Knowledge Power Social Validation Sex Love/Compassion Anger/Hatred Pain Relief Fear Virtues, Vices & Ethics Notice that all of these motivators are actually psychological motivators. That means they happen in the head of the agent rather than being a physical motivator. You can be physically hungry, but psychologically, you can ignore the pains of hunger. The psychological thresholds would be different per agent. Therefore, all of these motivators belong in the “brain” of the character rather than all being attributes of an agents physical body. Hunger and body temperature would be physical attributes, but they would also be “psychological tolerances”. Psychological Tolerances: {motivator} => 0 [------------|-----------o----|----] 100 A B C D E A - This is the lowest possible bound for the motivator. B - This is the lower threshold point for the motivator. If the current state falls below this value, the desired state begins to affect actions. C - This is the current state of the motivator. D - This is the upper threshold point for the motivator. If the current state exceeds this value, the desired state begins to affect actions. E - This is the highest bounds for the motivator. The A & E bounds values are fixed and universal. The B and D threshold values vary by creature. Where you place them can make huge differences in behavior. Psychological Profiles: We can assign a class of creatures a list of psychological tolerances and assign their current state to some preset values. The behavioral decisions and subsequent actions will be driven by the psychological profile based upon the actions which create the sum of most psychological relief. The psychological profile will be the inputs into an artificial neural network, and the outputs will be the range of actions which can be performed by the agent. Ideally, the psychological profile state will drive the ANN, which drives actions, which changes the state of the psychological profile, which creates a feedback loop of reinforcement learning. Final Result: We do not program scripted behaviors, we assign psychological profiles and lists of actions. Characters will have psychological states which drive their behavioral patterns. Simply by tweaking the psychological desires of a creature, we can create emergent behavior resembling intelligence. A zombie would always be hungry, feasting on flesh would provide temporary relief. A goblin would have a strong compulsion for wealth, so they'd be very motivated to perform actions which ultimately result in gold. Rather than spending lots of time writing expert systems styled AI, we create a machine learning type of AI. Challenges: I have never created a working artificial neural network type of AI. Experimental research and development: The following notes are crazy talk which may or may not be feasible. They may need more investigation to measure their merit as viable approaches to AI. Learning by Observation: Our intelligent character doesn’t necessarily have to perform an action themselves to learn about its consequences (reward vs regret). If they watch another character perform an action and receive a reward, the intelligent character creates a connection between an action and consequence. Exploration Learning: A very important component to getting an simple ANN to work most efficiently is to get the neurons to find and establish new connections with other neurons. If we have a neural connection topology which always results in a negative response, we’ll want to generate a new connection at random to a nearby neuron. Exploration Scheduling: When all other paths are terrible, the new path becomes better and we “try it out” because there’s nothing better. If the new pathway happens to result in a positive outcome, suddenly it gets much stronger. This is how our simple ANN discovers new unscripted behaviors. The danger is that we will have a sub-optimal behavior pattern which generates some results, but they’re not the best results. We’d use the same neural pathway over and over again because it is a well travelled path. Exploration Rewards: In order to encourage exploring different untravelled paths, we gradually increase the “novelty” reward value for taking that pathway. If traveling this pathway results in a large reward, the pathway is highly rewarded and may become the most travelled path. Dynamic Deep Learning: On occasion, we’ll also want to create new neurons at random and connect them to at least one other nearby downstream neuron. If a neuron is not connected to any other neurons, it becomes an “island” and must die. When we follow a neural pathway, we are looking at two costs: The connection weight and the path weight. We always choose the shortest path with the least weight. Rarely used pathways will have their weight decrease over a long period of time. If a path weight reaches zero, we break the connection and our brain “forgets” the neural connection. Evolutionary & Inherited Learning: It takes a lot of effort for a neural pathway to become developed. We will want to speed up the development. If a child is born to two parents, those parents will rapidly increase the neural pathways of the child by sharing their own pathways. This is one way to "teach". Thus, children will think very much like their parents do. Other characters will also share their knowledge with other characters. In order for knowledge to spread, it must be interesting enough to be spread. So, a character will generally share the most interesting knowledge they have. Network Training & Evolutionary Inheritance: An untrained ANN results in an uninteresting character. So, we have to have at least a trained base preset for a brain. This is consistent with biological brains because our brains have been pre-configured through evolutionary processes and come pre-wired with certain regions of the brain being universally responsible for processing certain input types. The training method will be rudimentary at first, to get something at least passable, and it can be done as a part of the development process. When we release the game to the public, the creatures are still going to be training. The creatures which had the most “success” will become a part of the next generation. These brain configurations can be stored on a central database somewhere in the cloud. When a player begins a new game, we download the most recent generation of brain configurations. Each newly instanced character may have a chance to have a random mutation. When the game completes, if there were any particular brains which were more successful than the current strain, we select it for “breeding” with other successful strains so that the next generation is an amalgamation of the most successful previous generations. We’ll probably begin to see some divergence and brain species over time? Predisposition towards Behavior Patterns via bias: Characters will also have slight predispositions which are assigned at birth. 50% of their predisposition is innate to their creature class. 25% is genetically passed down by parents. 25% is randomly chosen. A predisposition causes some pleasures and displeasures to be more or less intense. This will skew the weightings of a developing ANN a bit more heavily to favor particular actions. This is what will create a variety in interests between characters, and will ultimately lead to a variety in personalities. We can create very different behavior patterns in our AB’s by tweaking the amount of pleasure and displeasure various outputs generate for our creature. The brain of a goblin could derive much more pleasure from getting gold, so it will have strong neural pathways which result in getting gold. AI will be able to interact with interactable objects. An interactable object has a list of ways it can be interacted with. Interactable objects can be used to interact with other interactable objects. Characters are considered to be interactable objects. The AI has a sense of ownership for various objects. When it loses an object, it is a displeasurable feeling. When they gain an object, it is a pleasurable feeling. Stealing from an AI will cause it to be unhappy and it will learn about theft and begin trying to avoid it. Giving a gift to an AI makes it very happy. Trading one object for another will transfer ownership of objects. There is no "intrinsic value" to an object. The value of an object is based on how much the AI wants it compared to how much it wants the other object in question. Learning through Socialization: AI's will socialize with each other. This is the primary mechanism for knowledge transfer. They will generally tell each other about recent events or interests, choosing to talk about the most interesting events first. If an AI doesn't find a conversation very interesting, they will stop the conversation and leave (terminating condition). If a threat is nearby, the AI will be very interested in it and will share with nearby AI. If a player has hurt or killed a townsfolk, all of the nearby townsfolk will be very upset and may attack the player on sight. If enough players attack the townsfolk, the townsfolk AI will start to associate all players with negative feelings and may attack a player on sight even if they didn't do anything to aggravate the townsfolk AI.
  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
    So, I ended up doing the "skirts" method I spoke of in the last post. And in conjunction with the default Urho3D water shader (with a few small tweaks, and more to come to eliminate artifacts on the corners of the water blocks) it actually looks pretty decent. The water animates a noise texture that ripples the ground beneath. It also uses a reflection texture (which I have set to black at the moment) if desired. I might tweak the water shader further, but for now I'm happy with it. I've also got all the small issues sorted out from the change to multi-level water. It wasn't a large change, but I was surprised at how many different parts of the code worked from the assumption that water was determined by elevation < 9. I thought I had contained it better than that, but I did get all the various spellcasting, pathfinding and object spawning oddities worked out.