Jump to content
  • Advertisement


  • Content count

  • Joined

  • Last visited

  • Days Won


frob last won the day on August 15

frob had the most liked content!

Community Reputation

45410 Excellent

About frob

  • Rank
    Moderator - Mobile & Console Development

Personal Information

Recent Profile Visitors

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

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  • 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!