Jump to content
  • Advertisement

frob

Moderator
  • Content count

    11318
  • Joined

  • Last visited

  • Days Won

    8

Everything posted by frob

  1. Because it isn't accurate by default. You can make it more accurate (one article of many) but it looks worse. Font rendering is a large, complex, nuanced field. In the effort to make glyphs appear in a visually pleasing way, we generally sacrifice accuracy in computing details about how the text appears on screen. You can go back to the bad old days of fixed width fonts if you want. But modern fonts with a huge range of glyphs, including fonts with composed glyphs, advanced kerning, and glyphs that render outside what might be considered the regular text box, all of these make mathematics regarding fonts into incredibly complex systems. Case in point: I̗̘̦͝n͇͇͙v̮̫ok̲̫̙͈i̖͙̭̹̠̞n̡̻̮̣̺g̲͈͙̭͙̬͎ ̰t͔̦h̞̲e̢̤ ͍̬̲͖f̴̘͕̣è͖ẹ̥̩l͖͔͚i͓͚̦͠n͖͍̗͓̳̮g͍ ̨o͚̪͡f̘̣̬ ̖̘͖̟͙̮c҉͔̫͖͓͇͖ͅh̵̤̣͚͔á̗̼͕ͅo̼̣̥s̱͈̺̖̦̻͢.̛̖̞̠̫̰ Fonts are fun.
  2. frob

    How much longer can Trump/Trumpism last?

    Yet in those statements you seem to be generalizing just as much as the people you're accusing of generalization. You write that you're a democrat and that you've never killed a baby. As a platform, the democratic party currently declares that every woman should have access to abortion, and that the party will seek to oppose all laws and policies that impede a woman's access to abortion. If you use the same generalization that leads you to say "Russia is a giant gangster ran state", then by similar reasoning if you're a democrat you want babies to die. That brings back why so much of partisan politics is so stupid. When it reaches the point of parties all the details are so generalized as to become straw-man arguments. The generalization becomes easy to knock down. Even though both parties agree on 90%, maybe even 95% of the same stuff, both parties focus on the extremes and hyperbole to demonize each other. Party politics by their nature are diluted to the point of making debate and discussion nearly meaningless.
  3. frob

    Architecture of and engine editor

    For some game mods the preferred approach is through dynamically linked libraries. They work extremely well as a plugin approach since you can create a bunch of well-defined functions, and individual functions can be skipped (or have a do-nothing stub) when not implemented or redirected to loaded libraries if present. If you're using a Reflection-supporting language those hookups can be handled through those mechanisms if you prefer. Unity spent a lot of time developing their system, but effectively it works like a plugin above. It calls a compiler and builds your C# code into a library, then it scans the compiled library to hook up all the known functions. They hook up the functions directly the way a plugin library does, which is also leveraged for performance reasons. That's one of the reasons why all the functions are free-standing rather than virtual: if the functions for Start(), Update(), OnDisable(), OnEnable(), etc, were all virtual they would incur a cost for every call since the virtual functions need to be called, but by hooking them up only if they exist using a plugin-style architecture they avoid the overhead of calling empty stubs. Effectively there are two, the engine and the editor. There is more to it because they've spent over a decade making it more advanced, but we can gloss over that. Just like your main program, the editor is also a plugin for the engine system. (Caveats that it is an extreme simplification.) There is the core engine that's got the graphics, audio, physics, networking, math, I/O, and assorted other libraries. The core engine also handles a plugin architecture that allows you to load, unload, and run executable modules dynamically. They've also got the editor plugin module which gives you your menus, your object inspector, debug logs, code to launch build tools, to run and visualize profiling and performance data, etc. It can be started with either the editor as the main plugin module, or it can be started with your game as the main plugin module. Startup Option One: If you start it as the editor, the engine starts and then loads the Editor plugin; the editor plugin has the object inspectors, the title bars and menus, and all the rest of the Editor experience. The editor is what you would normally consider the game. When you use editor commands to compile and run the game in the editor, it launches the compiler as needed, then dynamically loads your game plugin and starts running it. Your game plugin is called by the editor plugin which is hosted by the engine. Startup Option Two: If you start it as your game, the engine starts and then loads your game plugin; instead of loading the engine plugin it goes directly to your game instead. You get access to all the UnityEngine functions because they're part of the engine. However, the Editor plugin is not loaded you don't get any of the UnityEditor functions; you don't get access to the editor visualizers, the editor events, the editor build and test tools, all because the editor plugin isn't loaded and doesn't ship with the game.
  4. Often referred to as the "Robin Hood defense". It is taking from the rich and giving to the poor without taking a cut. The Robin Hood defense doesn't hold up in court. It's easy to be generous with other people's resources. But if it isn't yours and the person who owns it objects, you're the one who will be on the hook. If it isn't yours don't touch it without permission.
  5. frob

    First Timer

    What roadblock did you hit? What is preventing you from moving forward? There are plenty of free and open source MUD and MUSH engines to work with if you want to leverage one of those. Or you can write your own, the concepts are not particularly difficult and it serves as the core of nearly all online games these days.
  6. Difficulty is always relative. Relative to making the game as a whole, the AI system is fairly small. Tuning the AI system is a big effort because crafting the balance between fair and fun is hard. I don't know about the official Civilization series code, but FreeCiv is open source so you can peek at their AI system. Generally the technique is to create a list of what actions are available, then rank them based on how much each one is wanted. How much they're wanted for civ is based on the government type or AI player's settings as well as immediate needs. The functions calculate the utility of the action, generally called utility functions. The code computes whatever has the highest utility among the options, and whatever is wanted most is what is selected. As an example, when choosing what to build a city may scan what's going on. There may be no immediate risks and the society in general has chosen to expand. The city may choose that building Warrior ranks has a score of 457, Spearman has score 358; growth is important so the points allocated to Scout has score 580, Granary has a score of 874, and Settler has a score of 943. So city chooses to produce a settler. The hard part of these systems isn't building the choices or the decision tree, but fine-tuning the values and their computation.
  7. What I think we're all saying is that having one state machine is what blocks extensibility. Having a collection of state machines that do the work ends up being easier as projects grow. Large behaviors are composed of many smaller state machines. The example was harvesting: Runs the Move To state machine to get to where harvesting takes place, then the harvest loop, then the move to state machine again, then the depositing loop. Even inside those sub-machines another sub-machine could be useful. When moving to a location when you are blocked, a sub-machine could trigger behavior to wait, or to replace the current action. In most systems I've worked with the state machines were able to replace themselves; the easiest example is where a target moved and the Move To action could replace itself with a new Move To action, or could replace itself with a Wait action followed by a new Move To action. Having one giant state machine can work when systems are small, but they don't grow very well.
  8. Yes, it is very suitable. Describing it sounds more complex than it really is. Here is an article with a few variations, the last example with animals running around is closest to what you describe. Several of the games I've worked on included variations of nested state machines mixed with some degree of utility functions. Hopefully they don't scare you off with descriptions. The individual state machines can be self contained and composed neatly. One state machine goes through all the actions it needs to complete its goal. Actions are made available as part of a pool of actions associated with the entity, and behaviors are chained together through state machines both by nesting and by utility functions. You're talking about a large-scale game with many unit types, this type of system tends to grow rapidly and is best suited for teams of programmers and artists/animators. In your example you've got attack, patrol along a route, move, take off, and more. Each one of those can be broken down into smaller bits. You probably will have several move actions: walk, run, search, crawl, fly, etc. Those can be encapsulated by a bigger command like MoveTo(), that would accept a target to move to along with a preferred moving style. Infantry may have available actions of walk, run, search, and crawl. Tanks may have a "walk" that moves slowly but retains the ability to fire, and "run" that moves quickly but cannot fire. Aircraft may only have fly, which may require transitions for landing and launching. MoveTo() would look at the unit's available actions and choose an appropriate movement to get somewhere. If moving somewhere requires moving along waypoints it could run one move action to the first point, then another move action to another point, then another move action to another point. MoveTo() could also be smart about distances, if a unit has a short distance to travel it could choose the walk action, if it has a long distance to travel it could the run action. Some units may have complex forms of movement, such as tanks or aircraft that can accurately fire while moving. Now you can compose that MoveTo() into bigger behaviors. Patrolling means running MoveTo() with a particular set of parameters, plus on every update also search for enemies. Attacking can check for distance, and if they're too far away they can call MoveTo(). After that you can compose behaviors out of a longer series of actions. "Collect resource" behavior means the action of identifying a nearby resource, moving to it, harvesting the resource, traveling back to the storage location, and depositing the resource. Occasionally you'll want units to look for other actions to do. Generally you don't want this to be continuous so the work load is distributed over time. A patrolling soldier may re-evaluate if it should do something else every time it completes a walk cycle. A unit playing the unit's idle could wait until a full animation has completed before re-evaluating. Having a "keep doing this behavior" is an important behavior for chaining. When the unit is done harvesting a resource it might repeat the behavior. But it is important that actors are constantly re-evaluating what they are currently doing, and they generally need a way to stop doing whatever they are doing. For example, units that are harvesting resources or that are patrolling should have the ability to stop and re-evaluate their actions when they're attacked. When re-evaluating the system can make a short list of all available actions. Exactly how you do that will depend on the game, maybe attaching actions to game objects like enemy actors or to invisible spawn points, maybe having free actions that search for proximity around characters, or maybe through some other way that works for your game. Use a utility function to see how much the character wants to do something. Actions like idle have very low desire, actions like "defend myself" are very high desire. When you want units to behave nearly autonomously you want many options with high levels of desire. In life simulators like The Sims the actors should have a long list of potentially interesting activities to choose from. In military simulations where characters do very little unless commanded, the action should usually be "keep doing whatever I was doing before". As these types of games grow, they typically start out with a small number of behaviors and a rapidly-growing number of actions. Already mentioned there will be several actions for moving between places. Aircraft will have different move actions than tanks, which will have different move actions than infantry. Moving while carrying resources may be different than moving while unloaded. As the number of actions increases you gain the ability to build more complex behaviors out of them. As mentioned, harvesting resources involves at least four actions in a chain. Building a structure may involve several steps as well.
  9. frob

    Monetization Problem

    Sounds like something to bring up with their support groups. The thing that immediately jumps out is how you show ads "5 times", they've got rules about how rapidly you can show ads and they will invalidate clicks they think are suspicious in some way. Maybe those rules apply, but they'd be the only ones who know.
  10. frob

    Skill points in tactical rpg?

    Is there something particularly different from what others are doing, something that wasn't called out well above? If so, I'm not seeing it. That looks like the standard level-up process that's been around since the 1970s. Gain some base stats, gain some individual skills or stat points you can choose, possibly gain a party skill you can choose. It's been that way since D&D was released, possibly before in earlier games.
  11. There is nothing wrong with doing stuff on your own, and some games do it. However, as noted above, it has become fairly rare due to the other players in the industry. Existing engines give an enormous set of existing tools and workflows. The tools have been thoroughly debugged and work reasonably well for many developers around the globe. Even if you don't go with a major engine, you should still consider minor engines and other tools for the benefits they give. As Hodgman just wrote, if you're doing it for a hobby because you love the craft or because you want to learn about those parts of the process then it's great. As a business decision it is hard to justify: you've got a large pool of free and low-cost tools and engines but you're choosing to re-invent the wheel for some reason.
  12. Implementation details are important. There are many ways to do it, but they depend on what you need in the end. You might be able to create the buttons dynamically in code, storing each one in a collection as you create it. Maybe they're cloned as prefabs or maybe you build them dynamically (such as pie slices in a circle), track them as you create them. You might leverage parenting. All the buttons parented directly under a specific object get collected at runtime. GetComponentsInChildren() and similar functions can help you find all the sub-objects with UI Button components. Another option is to have each UI button have a callback in your own MonoBehaviour attached to each object. You'll need to set the target object and function for each one you create. Another option is to have a collection in another object that you manually maintain, dragging links from each UI button into the inspector. Your use of a Singleton and tags can work but should be cleaned up. Singletons tend to be problematic on their own, I don't want to start a religious war on them, just search the Internet on the problems with Singletons. Rather than using FindGameObjectsWithTag() that searches the entire game world for objects, you are probably better off searching children only. That is more effort and isn't built in. Once you have links to all of them in one convenient place, the collection can be passed around to other places as needed.
  13. frob

    Array arithmetic

    This is possibly a tangent but we're not in For Beginners, so going for it. Yes, it can be a way to judge it. Over the years I've had a few people who did gauge code review quality over time across the team. I've known co-workers who intentionally introduce subtle changes in to the review that aren't in the actual code just to see who finds the errors. On a few occasions they've been introduced on purpose by leadership as a science project for data about the code reviews. Sometimes they're revealed in good ways, other times revealed in annoying ways, and sometimes they're never revealed at all. It is a good thing for statistics in quality control. If you introduce m known defects and n of them are caught, you can estimate that you're getting a ratio of n/m of that type of defect generally. If 80% of those little bugs are caught in code reviews, you can estimate that code reviews catch about 80% of the accidental issues. In that case your code reviews are effective. But if only 20% are caught, you can assume a similar rate for accidental issues and know you the team needs to increase their scrutiny. It is annoying when you know people introduce them on purpose, both because you know some developers have a bit of a "gotcha" mentality with them and because people will shy away from someone who is intentionally tripping them up. But it can work out as a good thing. Regarding someone who did it on purpose, he was clear he is trying to get better code reviews. He would always introduce at least one item into code reviews expressly to get caught. Everyone on the team knew he was looking for as many issues as you could spot so the code would be better, not because he wanted to be spiteful. Still was annoying because the reviews took more time, but we all knew the code was better for it.
  14. It has already been moved. The gamedev.net site has many discussion forums. You originally posted in the forum regarding design and game mechanics. It was moved to the forum for network programming.
  15. frob

    Starting a browser game.

    Use your favorite search engine and type in "javascript tutorial". The tutorials by the Web Consortium (W3Schools) and Mozilla are fairly popular, but there are many excellent resources out there.
  16. Crossword-generation is language agnostic, you're creating a 2D array with characters in cells. With a single search I found a bunch of valid-looking projects crossword generators on GitHub, including Java and C++ which could work for your purpose. It looks like some are general purpose that find intersections of characters, others more advanced, but fundamentally they're still building a grid of letters. Displaying it as UI elements is straightforward because again it is a grid of characters, and most UI libraries handle displaying characters without too much difficulty. Building dense crossword puzzles requires a large dictionary and various rules/heuristics to help generate it. For instance, placing a few large words in key places in order to create boxes of smaller letters. Human crossword designers often partition the puzzle into 3x3 or 4x4 zones where each zone uses 4-6 letter words, and build the interconnects between the zones first. After they're in place, filling in zones of letters reduces to a search problem relying on a large dictionary of words. Even so, there is an art to the dense crossword puzzles. Building on a theme and narrative to create an interesting puzzle is a difficult task.
  17. frob

    Array arithmetic

    People can also do this to mess with other developers. Constructs like 0[ptr] or 0[myArray] can catch your attention, but when you remember that under the hood array access is effectively *(a+b) it doesn't matter which order the two values are placed. The language allows many quirky things like this. But if I ran across 0[this] in a code review, they'd be getting some feedback.
  18. There is even more than those in the language standard's introduction. In the C++ the details run on for five pages with all kinds of details. There are similar descriptions in other language standards. The language standard is defined in the abstract. Actual compilers can make changes as needed as long as they don't change observable behavior. It is also sometimes called the "as if" rule: it can change anything it wants as long as ultimately it looks as if the C++ instructions were run exactly in the order they were given. Many choices are left up to the actual implementation. These include sizes and alignment of things, how values are passed and processed, and how certain tasks and processing are ordered. As @Alberth describes this allows for most language optimizations and language extensions (which are permitted in C++). Processing steps can be merged, tasks can be split, and unnecessary actions can be removed entirely as long as the observable behavior is the same. What you described, and what @Oberon_Command explained, is one of those pieces of non-observable behavior. In the C++ code you create a variable and it eventually goes out of scope. There is no observable difference to the C++ code if the space is allocated a little bit earlier. There is also no observable difference to the C++ code if the space is allocated somewhere else. While it happens to be allocated on the stack in your case, there is nothing preventing a compiler from allocating it somewhere else, like a location in scratch memory or keeping the value in CPU registers. The allocation and release could be done earlier in the program, even at program startup long before execution hits those lines. Those implementation details aren't observable to the abstract language. In heavily optimized builds the compiler does an enormous amount of work to speed up the program, and it does all of it while preserving observable behavior. As a few examples: The compiler can move things up outside of loops; it can combine loops to run in parallel; it can combine data or split out data in certain types of processing; it can remove "dead code" it believes has no observable effects such as writing a value and then immediately overwriting the value; it can pre-compute values at compile time so they aren't computed at runtime; it can replace your math operations with different math operations that run faster on the hardware, like replacing multiplication by a constant with a shift and an addition; it can replace calls to library functions with intrinsic functions, like replacing a call to sin() with an equivalent instruction; it can inline functions so the parameters and return codes are never processed; there are
  19. I doubt that. MMO has a meaning, although in the past decade the term is brandished idly, like many other words (e.g. "terrorist") used different from their established meanings. The term MMO refers to a major inflection point. Supporting a double-digit number of concurrent players isn't difficult. Experienced developers using simple tools can support a few hundred concurrent players easily. But soon you'll hit an inflection point, it no longer becomes easy and cannot be handled by an individual or a small group of people. Supporting several thousand concurrent gets harder. You can't do the work on one machine or a single program, you must spread the work across multiple machines and multiple programs. The work requires multiple teams to distribute the work. Usually this has an inflection point of around 100,000 concurrent users. Then it hits another inflection point, you cannot add new functionality without extreme difficulty. Then you move to MMO, where data must be coordinated across many sites globally, across a large number of systems, across a large number of teams. Your topics are good and over time you'll need to become familiar with each, but you're best relying on others to do the work. None of those are beginner-friendly. Not MMO specific. The common term today is a Central Authentication Service (CAS) system, but the logic dates back to the 1960s at least. In simplest terms, the user logs in and the back-end provides them with a token. The token gets passed around as needed between systems. When the user makes a request associated to their account, the token is validated and requests are allowed or denied based on permission. As for sending "the whole data", generally minimize network traffic and processing. Don't send something if you don't need it. If the client requests a set of data, send that data if they have access. If the client needs avatar names, classes, stats, provide a way to request it. There are decades of computer science research on the topic of authentication, security, and proof-keeping. It is a broad field of study. The topic gets complex quickly. It is generally best to use an existing library rather than write your own. With an existing library you don't need to become expert, you can rely on other experts who dedicate their lives to the field. Pick something that fits the scale of what you need, a system designed for enterprise security (with a team of people managing user accounts) is a bad fit for a staff of 20 developers, and something that works for a staff of 20 is probably a bad fit for someone working on their own. Depends entirely on the system, it should be done when needed and not done when not needed. Large systems have priorities and caches. Transitory data can be accumulated and stored periodically; your position on the world map is live data that needs to be maintained but doesn't need to be persisted to disk until you hit a save point or transition between zones. If the data is lost for some reason it isn't a problem. Some information needs to be updated more frequently, items collected on the field need to be saved more often but don't need to be written to disk instantly. Some transactions must be complete and finalized before the player can move on, such as players trading objects between each other or cash-based transactions. Sometimes things that are normally at one layer will fall into a higher priority; nobody will mind if a crash causes you to lose common loot collected on the field, but when you defeat the boss and collect the unique item you don't want that data lost due to a crash or data corruption. Small systems store data in memory and write to disk or an established database library at times they feel are appropriate. Concurrent processing, distributed storage, and cache consistency are part of another broad field of computer science with decades of CS history. The topic dates back to the earliest computer systems that needed to maintain and reconcile data between business offices. Like above with authentication, it is generally best to use existing libraries. Pick something that fits the scale of what you actually need. A distributed transaction system capable of millions of transactions per second scaling across multiple sites globally is a bad fit for something that will run on a single machine. Keep data in memory that should be kept in memory. Save to disk or save to SQL databases when that's appropriate, but not when it isn't.
  20. frob

    Menu UI - Partial Pausing the Game

    Don't pause the world. In general a pause system stops all animations. It will stop no matter if the characters are idle, or if a character is running, crawling, swinging a sword, jumping through the air, blocking a blow, or doing anything else. In that scenario you can't continue to play animations, not even idle animations, because they could interfere with other things that are going on. You can't have two characters locked in a battle to the death frozen in time while another is breathing and idling while changing outfits. All animations must stop in that situation, or the flow can't interrupt gameplay. If your inventory screen is outside the main gameplay environment there is no need to pause the world. The character is still visible and animations are running, the difference is that the character isn't being controlled directly by the player. Do all your menus and UI stuff, and have a character in a world that responds to events coming from the UI. You might have the UI trigger animations to show weapon swings when a different weapon is equipped or other animations, but it is the menus controlling the character, not the human.
  21. When thinking in systems, there is generally a coupling up/down, and sometimes a coupling between peers. For up/down, a container knows about the things it contains, and sometimes the things being contained also know about what contains them. For peers, usually this is done by injection, which is a fancy name for referencing another object, such as registering a physics component to use, an audio component to use, a networking component to use, etc. For the physics and rendering issue, you may have stumbled on a common confusion there. The objects have a position and orientation, that is true. Physics and graphics both need those to values. But physics is a different system that needs physics models, and rendering are a different system that needs graphics models. It is relatively rare that both models are the same, physics models are often cubes, spheres, capsules, and simple shapes, graphics models are highly shaped, textured, shaded, and otherwise processed. Neither render data nor physics data is shared, only the position and orientation are shared by virtue of containers. They have an up/down relationship with the object that contains them. Position and orientation are generally part of the game object container along with any number of other components, neither one is coupled. In most systems the game objects contain the position and orientation information. The game object may contain zero or more rendering components; many game objects render nothing at all, some game objects have multiple visible parts. The game object may contain zero or more physics components; very few things have collision specifically on themselves, instead generally relying on navigation meshes and large collision meshes. Physics systems should not have any reason to touch a rendering system, neither the rendering system have a need to touch the physics system. They're independent.
  22. frob

    Writting.

    Closed as cross post. See the other thread.
  23. frob

    Begginer at writting for video games.

    Some games need it, others don't. If you're building Chess, Checkers, Go, or similar games there is no need for writing at all. If you're working on a thematic story-filled world like Dragon Age or Final Fantasy or Half-Life then the studio needs skilled writers. There are few regular job openings for writers in games. Often the work is done by designers and interested people in the studio. When companies employ professional writers they typically bring in experienced writers as consultants. Studios tell the consultant all about the game, let them play it, and they work together to build the dialogue and story. For translating from one language to another, game studios generally use localization contractors. There are many companies out there providing skilled translation services. For your questions: 1. Is writing needed? Sometimes. 2. Should I write game-centric stories? Do it if you want. Writing isn't enough, you need feedback from skilled writers who can critique and correct your issues. 4. Should I make my own languages? Do it if you want. It is almost never used in games, but you should develop skills if they interest you. 3. How do I get the job? You become highly skilled first, then you find the job by talking with people in the industry and requesting the job. Know that the job is extremely rare and competition is fierce. Big games have the money to hire big-name authors. Smaller games don't have the money to hire anyone. 5. Translation services are different from writing services. I don't know about your skills in Spanish, French, and Russian so you may work for them. Your English skills need work. Focused only on your post there are many spelling errors ("begginners", "writting", "developping"), grammar errors, and editing errors (numbering 1,2,4,3,5) that would exclude you immediately if I were considering hiring you. You will need to improve your skills if you're planning on writing in English.
  24. frob

    Tile map bad performance

    The best answer is to get a profiler. That's the tool for this job. Far too many times people guess at what might be causing performance issues, and they guess wrong. At a glance I'm concerned about the number of drawImage calls. Details matter -- which is why you need the profiler -- but individual draw calls often have significant overhead. One of the most common performance demands is to move all graphics items over to the video card and to limit the number of draw calls. That guess is quite likely wrong, or at least not your only major bottleneck.
  25. What have you tried already? What didn't work about it?
  • Advertisement
×

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!