Jump to content
  • Advertisement

Kylotan

Moderator
  • Content count

    14308
  • Joined

  • Last visited

  • Days Won

    7

Kylotan last won the day on June 15

Kylotan had the most liked content!

Community Reputation

10329 Excellent

About Kylotan

  • Rank
    Moderator - Scripting Languages and Game Mods

Personal Information

Social

  • Steam
    kylotan

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. My first thought is that I read the first three paragraphs and I still have no idea what it is you actually want. You're rambling a bit, trying to be conversational, but it would probably help to be concise and succinct. If you had to describe the game you want to make in a single paragraph, can you do it? Or maybe even just 1 sentence? Section 5, "a Goal-oriented Behavior-approach seems rather fitting: Give the AI system some goal and some action and it figures out how to use them on its own" - sure, if you like. If the aim here is to have autonomous characters doing interesting things (and like I said, it's not clear to me what the aim is, given that half of your preamble seemed to be about cooperative play and grinding), then some sort of planning might work. You mention using Coroutines to calculate action scores over various frames, but I doubt that would be necessary or beneficial. Probably the opposite. Section 6: "While dominating a NPC, the AI system is supposed to record what you are doing, as long as the NPC is still happy (fed and rested). When released from domination, the NPC is supposed to recreate that behavior in a similar fashion without neglecting their needs." Okay, this is now straying into masters or PhD level territory. You might get away with it if you can simplify the model in which you work, and use some off-the-shelf tools to help you. It could be a machine learning classification task where it examines the data you provide it with and classify that as one of several pre-defined behaviour types. It could be a machine learning regression task where it examines the data and learns to score the needs or utility differently. The main problem is that machine learning expects to learn based on a lot of input data, spotting the bits that are common and the bits that are 'noise', allowing it to make better predictions when it sees future data. The situation where you control an NPC is unlikely to produce anywhere enough unique samples to be able to generalise effectively, so you'd probably need something simpler. This goes back to what we were saying in the previous thread, in that it's not about choosing 'An Architecture', but about joining the tools together to do what you want. Personally I see this as a very strong candidate for utility-based AI, which by no means excludes the ability for weights to change at runtime - although deciding how to weight things, and how to change those weights, based on which criteria, is the hard part of this project. There is no AI system in existence that can know "why the player did what he did". All you can do is look for patterns. That happens in a different part of the system to the system that chooses the next action to take. First up, the author of that book is the moderator of this forum, so it's probably best to let him speak for himself if he chooses rather than ascribe opinions to him! Secondly, it's not that machine learning is something to be "loathed" - far from it - it's just that it is a tool that solves specific problems, most of which are not the problems that game AI developers have. And even when they do have a problem that potentially resolves one suited to machine learning, like yours, it's not necessarily the case that they have the right situation or data in which to use such methods. Much machine learning needs to be done "offline", outside of the game or the program in which it gets used, typically because it takes a long time to learn and requires a large data set to operate. Finally, even when machine learning is appropriate and selected, far too many people jump to "deep learning / neural networks" when there are many simpler approaches which often work. The Imitation Learning link you provide leads to quite a complex set-up, which appears to be a neural network system running in Python/Tensorflow that communicates with Unity. So there's potentially a lot for you to have to understand there. They have a video showing that after 5 minutes of training, they can have a vehicle steering much like the player's vehicle. Great - but there are 2 big caveats here. Firstly, they had to set up the inputs and outputs adequately so that the system can learn an optimal mapping from the former to the latter. In the Unity ML system you have to decide on all the observations, what type of data they return, when to gather them, and so on. Gather too many things, especially if some of them are irrelevant, and learning will be slow. Gather too few relevant things, and learning won't happen at all. Secondly, the vehicle example is gathering useful data every frame, presumably the distance from and direction to obstacles, current speed, the player's current steering, etc. After 5 minutes that could be tens of thousands of useful data points. Compare that with your situation where a character action only changes every few seconds, if that. There's not much useful information there. You might be looking at needing to play for hours, or even days, before the AI could learn enough about the pattern to take over. Personally, I wouldn't use the Unity ML system for the situation you have in mind. I don't think it's impossible to do so, but I don't think it's well-suited. But is it possible to have some sort of AI that changes based on example? Sure. You just need to think it through and plan it out on paper before deciding how to approach it. For example, your Bob/apple/hunger/tired scenario is underspecified. You say "it would probably have been smarter for Bob to collect some more apples" - but why? He met both his needs. He was sleepy. Why is it better to pick apples when you're already sleeping, even though you're not hungry? Here, you're confusing a player's belief system with the ability of the computer to mimic a player, and these are totally separate. Ignoring the former, you might be able to get away with a very simple system where, if Bob The Player picks apples when he's tired, then it increases the importance of the Hunger drive and decreases the importance of the Tired drive. So when the AI takes over, the Eat tasks score higher utility than you might otherwise expect and the character should collect more apples. TL;DR - not entirely sure what you want to make, but you probably need to simplify it a bit, ditch the planning aspect, and probably settle for self-adjusting weights on utilities.
  2. https://en.wikipedia.org/wiki/Contributory_copyright_infringement " It is a means by which a person may be held liable for copyright infringement even though he or she did not directly engage in the infringing activity. [...] Contributory infringement is understood to be a form of infringement in which a person is not directly violating a copyright but, induces or authorises another person to directly infringe the copyright ". If you live in an area where this sort of law applies there is a good chance you could be held responsible if you created a system to allow people to broadcast mp3s to other people without the rightsholder's permission.
  3. Most 64bit systems have facilities to run 32-bit programs. Moving this topic to The Lounge as it's not a directly programming-related question.
  4. What do you really mean, when you say 'do they recognise it'? If you want to actually be a game tester, you have to meet the requirements to be a game tester. A desire to work with games is part of that, but only one part. You can't just walk into the role. If you want to actually be something else, like a programmer, artist, or designer, you have to meet the requirements for those roles. Already being in the industry as a tester may help. It may give you some experience that another candidate would lack. But you still have to meet the other criteria, i.e. whatever experience, knowledge, skills and education they want you to have.
  5. The .io games are not really 'fast twitching' games. The in-game 'characters' move in relatively slow and predictable ways and the game is very suited to rendering other players slightly 'in arrears' with interpolation to smooth them out. The amount of bandwidth needed is relatively low and the data is being sent regularly, so TCP is likely to be just fine unless everyone is playing over a wireless connection. UDP is still very important for super-fast games where latency truly matters, but these games don't fall into that category. They might perform better with UDP, but they don't require it.
  6. Tons of ways you can choose to approach this: subclasses of InteractionComponent can handle the Interact() call differently InteractionComponent could check for other components (e.g. DoorComponent, ChestComponent) InteractionComponent simply contains all the possible data for all the possible interactions (of which there are probably not that many, when you really think about it) If it's harder to do something the "pure" way, there's a good chance the pure way is not the best way. If your component contains no logic then the problem merely moves; this becomes the responsibility of the InteractionSystem. That would decide how to handle the individual situations in much the same way - it can look for other components which implement the individual options, or it could handle each individual option itself. None of this has anything to do with keyboard handling - the keyboard code should translate this keypress into an interaction message, which your system then handles. Or the input code calls whatever system decides that an interaction will take place, and that decides which components to call. By the time your interactables are getting notification that something is interacting, the input code should have been left far behind.
  7. I'm aware that I'm responding a bit late, but just to add a few thoughts: Perhaps one thing that isn't clear to an outsider (as you call yourself) is that in game development, and indeed much of software, 'architecture' is a floaty, fluffy, abstract thing. It's not like construction where 'architect' is a specific job responsible for most of the planning and then the building is constructed according to those plans. In much software, architecture is just the word you use to describe the structure that emerged from all the other collaborating and competing parts of the program. As such it's hard to speak on it with authority because it doesn't always exist as a discrete and distinct entity separate from the various features and concepts that it holds together. This is a good analogy, but not for the reason you think. When people go on holiday, they typically pack their stuff into the car they already own. They don't buy a new car for the purposes of the vacation. So it is with games. If I'm making a game in Unreal, I'm going to do all the AI in terms of their behaviour tree system because it's already there and I can extend it to do what I want. But in Unity I might make something different, and that in turn might depend on the needs of the game and what code already exists. Unity comes with a rudimentary navigation and path-following system so I will write the character code to use that, and behavioural code will naturally layer on top of it. But it's driven by the pre-existing components. Now, onto your abstract: I think part of the problem here is the underlying idea that these are 4 different, competing paradigms for AI, when in fact they overlap, being neither mutually exclusive nor sufficient in themselves. Some thoughts: Decision trees, [finite] state machines, and behaviour trees are fairly simple reactive systems - goal-oriented behaviour (usually 'Goal Oriented Action Planning' in games) is usually a planning system. These are hard to compare directly, especially since it's not uncommon to have a planning system to choose longer-term goals AND a reactive system to handle short-term aspects. Given that the 3 reactive approaches are, given a knowledgeable enough developer and sufficient time, broadly equivalent, the choice often comes down to what tools are already available in the system. As noted above, UE4 contains a behaviour tree system built in. I've heard of people actually using that system as a glorified finite state machine because that was what they were familiar with. But the thing there is that the first concern was the tools provided by the engine, and the second concern was the knowledge of the programmer - the type of game being worked on was not really considered relevant. A decision tree is so basic a concept that it exists in your AI system informally anyway. A Behaviour Tree's Selector node is, essentially, a 1-ply decision tree. Likewise, a finite state machine can be represented as a decision tree where the early decision nodes are all "If agent is in state <X>". Few people in game AI use a decision tree in a formal sense - it is, however, a useful didactic concept to explain how a set of conditions can be ordered and aggregated to produce a choice, and allows you to consider how you would choose to build on that. As Dave mentioned above, rather than there being a monolithic "AI system" you usually have different parts that cooperate. I like to think in terms of the Sense/Think/Act cycle, and while some approaches cover all three, most do not. For example, I might use influence maps to help with the sensing of good or safe locations, a search/planner like A* to decide which route to take to such a location, and then a set of steering behaviours to move the agent along the chosen route. These are the aspects which do actually vary based on the kind of game you're playing, because not every environment is suited to influence maps, or steering behaviours - but it is independent of the high level activity-selection that GOAP or behaviour trees would tend to handle.
  8. Kylotan

    What ways can I optimize a vector magnitude check?

    In Unity you can just use Vector3.sqrMagnitude - no need for the manual dot-ting. You probably also want to consider Vector3.clampMagnitude to keep your velocities from getting too high, as opposed to manually doing the comparison and modification yourself. Finally, since you're working with hundreds of objects and performing very similar operations on them, you should look into the new job system and entity component system that modern versions of Unity have. They're designed to make this specific type of thing a lot quicker.
  9. Kylotan

    Parse / Split a HUGE file?

    900 megabytes of data shouldn't stress a typical modern computer with several gigabytes of memory. So the issue is something else - either you turn that data into something bigger, or you're involving something bigger during the processing of it. There may well be bugs in your code that need fixing. Splitting the data may reduce the symptoms but really the issue is likely to be somewhere in your code.
  10. Kylotan

    Introduction and Career Questions

    It does, because you can't go to an employer and say "I have 4 years experience of game development" if you really mean "I did a 4 year course at university/college". It's not that your experience is not valuable - it is - it's just that you have to frame it differently. Academic projects are very different from commercial ones. But if you get your indie project shipped, that will reflect well on you. That's great, but being a designer is not just about documentation, it's also about the doing. Here's a list of things (from an older post of mine) that I have seen game designers doing in their day jobs in the industry, in no particular order: Broad character/vehicle/unit/species design 'Grey box' level concept design (artists replace the grey with real assets later) Level design by placing assets, or using a level editor tool Hook up animation assets to characters Write design documents for producers, artists, and programmers Choose input schemes and keybindings Implement character archetypes within an engine Create 'flavour' documentation or narrative to guide feature implementation Plan cutscenes Produce UI mockups for artists Consider UI/UX issues, accessibility and usability, plan a player's flow through the program, etc Perform competitor analysis on related products Create trivial game logic and events in Blueprints or Playmaker Write pitch documents for game ideas Prioritise features and sub-features to guide producers and programmers Plan and design game systems (movement, camera control, character progression, encounters, AI) Design and balance game systems (via formulae in spreadsheets, simple scripts, etc) Balance game systems via testing and measuring Write narrative, dialogue, flavour text, or prose, and enter it into the engine Evaluate and refine monetisation approaches Create scripted events Set up quest definitions with objectives, conditions, etc  How much of that have you covered? As with what we said earlier in the thread, nobody is expected to have done everything. But a lot of designers come into game development thinking that their role starts with the idea and stops with a design document, not realising they need to do a lot of work beyond that. We're generally happy to on these forums to give feedback on portfolios. If you post up links, people can offer their opinions. Those opinions will vary because everybody likes to see somewhat different things from their designers, but it should point you in the right direction.
  11. One big problem with teaching yourself game design is that few people really know what game design actually involves. If nothing else, a good syllabus (and, unfortunately, bad ones exist) will force you to gain some experience in all the relevant areas. Incidentally, since you mentioned video tutorials, I would say that these are a poor substitute for books. Videos are snappy and memorable but they rarely go into depth in the way that a good book does, and there is much less quality control involved in who gets to produce them. Be prepared to read.
  12. Kylotan

    Introduction and Career Questions

    I think it can be worthwhile joining a team, but you need to be aware that the vast majority of hobbyist teams - e.g. 19 out of 20 - do not finish their projects, and probably most of them don't even get the project into a shape worthy of showing to others. It's a nice thing to do to get practice of working in a team, but for your portfolio you will want to work on that yourself. As for the specifics of your portfolio, you can show it if you want feedback on it, but personally I would just advise having 2 separate portfolios, one for code and one for design, and making sure each one showcases a wide range of your best work in that area. If you want design jobs then I suggest you focus on the things you can show that don't require much or any coding, and vice versa.
  13. Kylotan

    Is this clone legal?

    You're allowed to copy game mechanics, just not to use or copy any assets, or to use any of the distinctive names from the original. So your upload will probably be fine.
  14. You don't need to pick one of these three routes - you can have all of the above, in the areas where it makes sense. It's not ideal to obsess over low level things like vtables or cache misses unless you know you have a system where that is going to matter. It's also not right to consider a message system to be some sort of 4th approach - that is just a way of handling communication between things. I don't think anybody serious is trying to create an entire system where absolutely everything is handled by messaging. It is however useful for communication between completely unrelated systems - but so is the observer pattern, or callbacks, or events, or lambdas, or whatever your language provides to keep coupling low. All programming is about trade-offs. Dwelling on it too much at the start is a good recipe for never getting anywhere. Start coding, and improve your code as you go along.
  15. Kylotan

    Introduction and Career Questions

    What you're missing here is that a game designer is not just "designing games" at the high level but is actually producing a whole bunch of content for the game. This doesn't require equivalent implementation skill - it just requires using and understanding the tools. The fact that you have some coding ability and thus the ability to implement some of your ideas directly is probably distracting from the fact that most designers do not have this, but they get hired anyway by demonstrating their skills in other contexts - as I mentioned in my first post, you can design levels, you can write mods, you can work in spreadsheets. You don't need to make the game in which these things are used. Finish projects. Either stick with one until it's done, or redefine the scope of a project so that, by definition, it is done. In each case: is the 'thing' no longer beyond your abilities? Then go back and finish it. is it forever beyond your abilities? Then you have the wrong attitude, because game dev is all about learning. is it not beyond your abilities but would take too long? Be realistic with the scope. Make smaller things. You shouldn't have 30 abandoned projects. A handful, maybe. But getting a job is about showing that you can get stuff done, that you can work with minimal supervision, that you can do your own research to overcome roadblocks, and that you don't give up when the going gets tough. You say you have a computer science background and how true that is will be a big factor in whether you can be hired for it. When I've interviewed graduates/juniors I was looking for good quality code samples, ideally in more than one language, which demonstrate that they understand good programming principles - abstraction, encapsulation, naming, commenting, etc. I personally don't care how good your game looks or plays - mostly I just want to see source code, and to be able to ask you about it, and about coding in general. And I want most of that code to be directly game-related. The chance of being hired for a job you're not capable of doing is basically nil. It's not something you need to worry about. Competition for entry level jobs is very high and the interview process is usually fairly rigorous. The main purpose of a job description is to attempt to ensure a good alignment between the skills of the applicant and the needs of the employer, and it has to do that without becoming a complex and overly long document. You just have to read it over and decide whether you're wasting your time or not, and read between the lines to guess what it implies. e.g. If a job description says "2 years UE4 experience" then they're most likely hiring for a UE4 game and want someone with explicit experience of that engine. You could apply if you only have 1 year UE4 experience. You could apply if you have 3 years of Unity experience but are confident enough with C++ to think you could make the switch (and this is what you'd put in your cover letter). Similarly, if there is a list of 5 required skills and you match 4 of them but the 5th one is a bit obscure, it's worth applying. Maybe they don't realise how obscure it is yet. Maybe the people with that 5th skill actually demand too much money and won't get hired. What you shouldn't do is see a list of 5 required skills, realise you have none of them, and apply anyway. If you're hopelessly unsuitable then your resumé goes straight into the trash and if you're unlucky someone remembers your name the next time you apply. Use your discretion. Almost nobody offers remote work to juniors, just so that you know. Very few even offer it to seniors.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!