Interface changes that would be nice...
1. The ability to make interface elements have a transparent background.
At the moment this can't be done or easily imitated. If I use a background in an interface with a texture I cannot directly display text on that background without the element the text is in (a grid for example) putting up a solid colour around the text.
2. The ability to disable scroll bars.
Some times they appear when they shouldn't (and cannot be scrolled because there is nothing to scroll) and it is annoying when you only have two lines in a grid, but a scroll bar appears and decides you actually have 4 lines but two are empty and can be scrolled down anyway.
As for ABSOLUTE POWER... BYOND should support it. Modern computers are off the way of multicore processors, which BYOND has no support for. Argue about it all you want, but it would sure be nice to have (and be even nicer if I could make use of the other 3/4ths of my computer in BYOND).
I doubt this will happen, but having some basic control over those processors used would also be nice. I could they for example have one processor dedicated to processor intensive things (maybe map generation) and another to running the game. That way a game could do a lot of things that would normally not be possible because it would create way to much lag, without it effecting the actual game at all.
ID:260585
 Jul 12 2008, 11:31 am
|
|
|
Jul 12 2008, 12:48 pm
|
|
Devourer Of Souls
 |
I would absolutely love to see #1 and #2.
|
Heh, what you said in 1 and 2 may have some merit, but how would you go about using effectively the resources available in a multi core system? are you saying you're prepared to handle cycles, threads and all the other jargon that comes with this added power? Don't ask for something thats over your head. From what I have seen from your posting style, I doubt you have the capacity to use what it is you're asking for, if you feel that what ever it is you are trying to accomplish is too cpu intensive for byond, you're (A) doing it wrong, or (B) doing it wrong.
Dante | |
The Magic Man wrote:
Interface changes that would be nice... Much of this relates to limitations in Windows. Having the ability to more easily make certain controls transparent is on the List, and it's something we've experimented with to some extent. 2. The ability to disable scroll bars. These cases are bugs. The scrollbars in info and grid controls are, alas, imperfect. A lot of work has been done to make them work right but occasionally weird situations still pop up. As for ABSOLUTE POWER... BYOND should support it. Modern computers are off the way of multicore processors, which BYOND has no support for. Argue about it all you want, but it would sure be nice to have (and be even nicer if I could make use of the other 3/4ths of my computer in BYOND). BYOND is single-threaded on the backend. That part's really not going to change. What might be possible, however, might be threading things like icon operations. If we could find some way to split those among multiple threads, that'd be great. It's definitely worth considering for those cases. This kind of thing would be limited though since it only affects certain operations, and I'm not certain it's technically feasible anyway. If there's some way to instruct the processor to split up certain operations among multiple threads to use the most of the processor, I'm all for it, but the challenges are legion. At best there would be certain places where the effect would be just like "pipelining", effectively speeding up operations slightly. Lummox JR | |
Not really, there is a lot of ways BYOND can become way to laggy to reasonably host a playable game.
Just try and use rgb(), on it's own it's not to laggy (but noticable). Now have several people using it regularly (maybe to display damage numbers). It creates massive amounts of lag and is almost guaranteed to cause anyones CPU usage to shoot up to 100. Another example is AIs. Sure you can disable ones not being used. But what happens if a lot of them are being used? Even with the most efficient AI you could never get more than 1000 running at a time without it generating to much lag, you'd be lucky to get half, or even a quater of that. Which isn't a lot really. Or the example I want to use it for. Randomly generating content. Enter a dungeon and have it's floors randomly generated (one at a time). Only it causes CPU usage to shoot upto 100 for a few seconds everytime it generates a floor. Now imagine this once or twice every minute. Makes for a fun game if you ask me, and there isn't a lot that can be done about it, because in BYOND things like generating large, random maps are cp intensive and no one can do much about that. Anyway. If I am doing these wrong then prove it to me. Make use of rgb() in a way that doesn't cause massive CPU useage. Make a decent AI (one that will wander randomly until it finds a player, then follow and attack a player once it sees them) that can be used 2000 times simultaneously without lag. Make a random dungeon generator that can generate dungeon floors in less than 1 second. Also, I have tried this and on a large scale it is just not feasable to use. But make system to imitate atmospheres. Things such as pressure, wind and composition all have to be accounted for (things such as the flow of gasses, fire that cannot exist without oxgen and so on all have t be accounted for). Now try and make a system like that which will run on a map sized 100x100 without it using more than 5% CPU (anymore would steal away from parts of a game that are more important and need CPU more). Ok, go. If I am doing these things wrong then show me them done right. | |
The Magic Man wrote:
Not really, there is a lot of ways BYOND can become way to laggy to reasonably host a playable game. Yes, if the game wasn't made or designed right, or is otherwise pushing its luck. But you'll find that is the case with any program, anywhere. Also, about hosting games, that is a whole different thing which your suggestion will do nothing about - it depends primarily on your internet connection speed, not your processor. Just try and use rgb(), on it's own it's not to laggy (but noticable). Now have several people using it regularly (maybe to display damage numbers). It creates massive amounts of lag and If this operation takes considerable CPU time and is done regularly, the correct approach of design would be to simply cache rgb() results so you don't needlessly call it all the time. IIRC, rgb() isn't an unusual, magic proc, it returns a value of documented type (I think it's a text string, which means you don't even need to call the proc once, you can have the string hardcoded), and it can be kept in a variable and cached. Example: Instead of calling rgb() 10 times a second (often you'd have a player attacking 10 times a second, eh?), call it once for your whole game, and store the result in a global variable, which you can then reuse without calling rgb() ever again for that purpose. You can get more complex than that with a more systematical approach to caching, such as unloading stuff that is seldom used after a few minutes when it is unused and seems it won't be again etc, but that is not required. is almost guaranteed to cause anyones CPU usage to shoot up to 100. Somehow, I kind of doubt this. Another example is AIs. Sure you can disable ones not being used. But what happens if a lot of them are being used? Depends on how many you mean by 'a lot', but this can stem from inefficiently-made AI and incorrectly designed one, like you've said, it shouldn't be active if it isn't necessary that it's active - if you think any commercial RPG with thousands of NPCs has more than a couple <small>(not exactly a couple of course, but it's not that I can come up with exact numbers)</small> of their AIs active at one given time, you're wrong. It's simply how it should be done - if it's not used, then don't do it. You don't even NEED to, because doing so is kind of useless. Even with the most efficient AI you could never get more than 1000 running at a time without it generating to much lag, you'd be lucky to get half, or even a quater of that. Which isn't a lot really. I highly doubt you know what you're saying, as first thing you'd need to have validated the AI you've been testing with is as efficient as it can get with multiple experienced programmers first in order for your statement to be true. But there's NO reason whatsoever to have 1000 NPCs active, really, or even 500, considering a single BYOND server isn't even capable of housing enough players to appreciate all of those. Or the example I want to use it for. Randomly generating content. You could port it over to a DLL, that's why that kind of functionality was added. Also, different design could possibly make it better, such as generating the dungeon beforehand (but as a slower, background action, not one that hogs the CPU) or maybe even some method on-the-fly. Anyway. If I am doing these wrong then prove it to me. On principle, we can't, since we don't even know how you're doing them. Make use of rgb() in a way that doesn't cause massive CPU useage. Cache the result and eliminate subsequent, similar calls. See above. Make a decent AI that can be used 2000 times simultaneously without lag. This is infeasible and again, it isn't needed either. Also, BYOND is admittedly not a powerhouse, it's slower than lower languages by nature, so do not expect it to be capable of the same things other games (that are made in C, for instance) are, such as MMORPGs, although even in those unneeded AI is probably deactivated, of course. Make a random dungeon generator that can generate dungeon floors in less than 1 second. See above for improvements about lag created from trying to generate dungeons on-demand. Also, I have tried this and on a large scale it is just not feasable to use. But make system to imitate atmospheres. Actually, I think that's possible to do feasibly to an extent, except the fact you're going way overboard. One reason is that players are playing games to do things they can't do in reality, to "escape" it in a way, and there is not much reason for implementing the whole universe into your game. Realistic games are cool, but like with basically everything in life, too much of something is bad. Also, about quad-core processors: to be honest, it is known most applications do not make full use of them. As such, they are only recommended for people using the lesser array of application types that do use them, such as video editing programs. This is going to be a little mean, but since this IS known, if you didn't do your research before buying your processor, well, sucks to be you? Very often quad-core processors do not result in a big performance boost even in commercial, 3D games (if any) - especially not one bigger than the boost you'd gain by buying a double-core instead that has a higher clock speed. EDIT: Fixed mistake. | |
Firstly, a quadcore processor is more useful than you seem to think. Sure, a lot of programs do not make use of them, and in effect it is just like having a single processor. But that in it's self is an advantage, because only one of the 4 processors is used, the computer still has 3 others which can all be used for other things.
If you have one processor and something makes intensive use of it your whole computer lags. If you have multiple processors and the same thing makes the same use of a processor, your computer does not lag because it has other processors to make use of. Also, multicore processors are becoming a standard supported feature in newer PC games. I wouldn't be suprized if soon they were supported by all newly released games. Anyway. For AI, on my computer right now I can have about 5000 mobs running a basic proc tht does nothing but step_rand once per second. Even if I made a simply AI (wanders randomly until finds a player, then chases player) I am willing to bet that number would be drastically lower. Now imagine a half decent AI that does other things, tha number would drop even more. Bet you cannot make a decent AI that can be run 1000 times simultaneously. Before you say you wont need to. How about some sort of zombie outbreak game? What fun is it if you only have 10 zombies? I tried making an AI for such a game (it would find a player from a list of people playing, and then use a very basic path finding function to find it's way to that player then attack that player, destroying any obstacles in it's path), I might not be the best programmer ever, but I got the advise and help of people who were, people who make the best BYOND users look like amateurs (and help from some of the "best" people on BYOND). Regardless of methods provided I couldn't get such an AI to run more than 1000 times without it lagging so much the game was unplayable. Now you try. As for random map generation. Sure you could have the process run slowly in the background. But that still causes lag, now imagine that is happening a lot of times. Now you don't have an unplayable game for a few seconds ever now and then, you have a game that contantly lags. Also, this method might not be feasable all the time. Unless you program your game to be psychic you have no idea what sort of dungeon needs generating or when until it needs generating. As for the use of DLLs... If you are going to go to the effort of using DLLs to make all the functions you need for a game then why even bother using BYOND exactly? And for the atmosphere and games not realistic. Give it a break, it has been said a million times before and it has always been said in the wrong way. Realism in a game is only not fun if it is not done right, if it is done right it can add a whole lot to the game. If a game needs a level of realism (in this case it did, it was along the lines of those random player is murderer, find them game, but in a futuristic setting where things like gas, the atmosphere and atmospheric pressure could be used to kill people combined with a level editor the system needed to be applied to the whole map just incase) then just give it that level, it's not like games can't have realism (and most do actually). Anyway, argue about this all you want. I said it in the original post. It would be sure as hell nice to have multicore support in BYOND, regardless of what counter arguments you try to give. You might enjoy squeezing every last drop of power out of your Tandy TRS-80 or whatever 30 year old computer you seem to have (and apparently the majority of BYONDs long time members feel the same). But a lot of people in the world can afford and have computers that are less than 5 years old, and would like to make use of them! | |
The Magic Man wrote:
If you have one processor and something makes intensive use of it your whole computer lags. If you have multiple processors and the same thing makes the same use of a processor, your computer does not lag because it has other processors to make use of. You seem to have a pretty too-wide or incorrect definition of the word 'lag' throughout your posts. Anyway, either way, like I already said, if performance boosts in gaming is what you're after, then CPU-wise, it is a much better idea to spend the extra money a quad-core costs on a 2-core instead that has a higher clock speed, which results in better performance. Anyway. For AI, on my computer right now I can have about 5000 mobs running a basic proc tht does nothing but step_rand once per second. You're being WAY too hungry without actually thinking. If you keep thinking that way, there'd be no end to it. Eg even if BYOND magically increases that number to 8000, you're going to say "oh no that still sucks and is way too little, I need 15,000". Your want is unfounded. You are just playing with numbers without considering them. Even if I made a simply AI (wanders randomly until finds a player, then chases player) I am willing to bet that number would be drastically lower. You don't need, and shouldn't, have it that high in the first place. How about some sort of zombie outbreak game? What fun is it if you only have 10 zombies? Oh yes, but it is very fun to have 5000 zombies, and have the players practically swimming in them and unable to even move, oh yes. -_- Seriously. You are missing the point by a mile. Sure, total 10 zombies in a big map isn't enough. However, 50 is already quite suitable. 100 is around the needed amount for a zombie-infested game, 200 is too much and 1000 is way too freaking overboard. As for random map generation. Sure you could have the process run slowly in the background. But that still causes lag, [...] Now you don't have an unplayable game for a few seconds ever now and then, you have a game that contantly lags. You are utterly wrong. Having it run in the background means it runs in a low priority, which by definition CAN'T lag and is the whole point... Unless you program your game to be psychic you have no idea what sort of dungeon needs generating or when until it needs generating. Wasn't the kind of duengon... RANDOM? Also, the specific design naturally varies according to the game. But it is definitely generally doable. As for the use of DLLs... If you are going to go to the effort of using DLLs to make all the functions you need for a game then why even bother using BYOND exactly? Plenty, plenty of reasons which I will barely begin to cover. Maybe because you are only programming a very little part of your game in a non-DM language, only one function, and the rest is in the more convenient, easy, feature-ful DM that already has tons of things built in, such as a map system, movement system, multiplayer, the list goes on. Realism in a game is only not fun if it is not done right, if it is done right it can add a whole lot to the game. If a game needs a level of realism (in this case it did, it was along the lines of those random player is murderer, find them game, but in a futuristic setting where things like gas, the atmosphere and atmospheric pressure could be used to kill people combined with a level editor the system needed to be applied to the whole map just incase) then just give it that level, it's not like games can't have realism (and most do actually). You are free to create a topic about this in Design Philosophy for further discussion. Truth is, however, your expectations from BYOND and BYOND games are unrealistic themselves, and overboard. Implementing things such as fire requiring and draining oxygen to continue is one thing, which is simple, easy to do and not processor intensive. But implementing the laws of the universe, atmospheres, physics, particles, matter compositions, etc and trying to very closely imitate the universe (which we don't even adequately understand yet!) is pretty overboard. Same for wanting a gigantic 'population' in your game. It would be sure as hell nice to have multicore support in BYOND, regardless of what counter arguments you try to give. Why, I never argued against it being nice. I was replying to your other points. The only related thing I said was that BYOND is not very unusual from not fully making use of multicore processors, many game platforms do not. You might enjoy squeezing every last drop of power out of your Tandy TRS-80 or whatever 30 year old computer you seem to have [...] This part is quite pointless and a sad attempt to pick on me for discussing your suggestion with you. I have a new computer, but that has nothing to do with what I discussed, it does not really relate to anybody's computer specifications. | |
okay, Magic Man, since you obviously don't feel like there is anything wrong with your argument, then why not start programming? BYOND Features is probably around so developers can nag the BYOND suite developers for trendy new functions, or suggest improvements for existing functions, but I'm sure that all the new features that have been added as a result of someone's nagging has been because that person wasn't alone, and/or provided substantial evidence such a feature would actually be useful. Since you are (as of now in this thread) the only person interested in overcomplicating your development experience, you have to develop a program that could not run in BYOND without the extra aid of a multi core execution system.
Your arguments are invalid, as of right now, you do not need anything that can handle up to 5000 mobs at a single time performing AI, thats just plain redundant, do you plan on creating a game where there are 50 NPCs for every player? Its obvious you need to read up on Lummox's Dream Tutor articles. Furthermore its obvious you do not understand the nature of what it is you 'think' you want. You may say 'show me a way to call rgb() 50 times a 1/10 of a second without generating freeze-ups (you'd say lag instead,because you're stupid) when in actuality anyone with half a brain would use a lookup table as rgb() generates a cacheable text string. so theres no need to call it more than you need to. In my humble opinion your argument exists only in your head, because its obvious one does not exist in this thread. Get lost. | |
Right now a dual core might run at like... 2% better than a quad core (if you are lucky it might be 5%). But like I said, a lot of new PC games are actually starting to support multicore processors (your dual core isn't better than my quad core, my quad core just has very little support and isn't made use of, yet). Once support for multicores is more common I'm going to be polishing my e-peen while telling you how much money you wasted buying a dual-core and then a quad-core (or more) later on down the line. Might as well just spend a few extra bucks now and buy a quad core instead of saving a few bucks on a dual core only to have to spend even more on a quad core a year or two down the line.
As for the zombie AI problem. Depends on the map size. But on a 100x100 map (which ia fairly common) after testing 100 zombies is not enough. I was using 300 zombies and it didn't seem like enough on some maps (just so you know, in a zombie invasion the whole point is to be swamped by zombies so much you cannot move. Zombies individually aren't a problem, they just have power in numbers, overwhelming numbers, unless you're using super zombies that can run and punch through walls, but I'm not talking about those sorts of zombie here). Also, AIs can be used in a large amount even in a small game. I uploaded a source code to BYOND not long ago to an incomplete game. It has exactly 1 town and 1 randomly generated dungeon. The town had 3 maps, each with an average of maybe 25 NPCs (all used AIs). The dungeon had 50 floors, each floor had more monsters on it than the last. Floor one had between 3-6, floor 50 between 22 and 36. Lets use a theoretical situation. The game has 10 players on it, a low number, each on a different map. AIs not used are disabled, AIs being used is 25 for each town map (75) plus 30 for each other player. That is about 285 AIs that need to be running. These AIs were also not simple and could do some relatively complex things (by the average BYOND games standards they were probably some of the better AIs you'd see, by far). Though it is only theoretical that is a low number, but needs a lot of AIs running. Imagine if the number was double (about 450 AIs max) or even triple (about 570 AIs max). Though it'd never happen lets imagine 53 players were in the game, that means possibly every single AI in the game could be in use, and the game probably wouldn't be playable. Have you ever seriously tried to make something like a RPG before? Each map might only have a few AIs running on it, but with a few players those small numbers can quickly shoot up into the hundreds, and CPU useage on even the most efficient AIs shoots up in a similar way. As for the random dungeon, sure it is random. But that doesn't mean it is random to the point of having no sort of theme or structure. In my example I have dungeons that are generated usually with a theme. An ants nest uses a unique method of generating levels and obviously has a lot of ant-like monsters. Whereas a forest dungeon uses a totally different method of generating maps and has different monsters. Now, which of those should I have generated in the background? What do you do when you have 20 different dungeons like this each with between 10-50 floors? (They are also randomly regenerated when empty) Do I have them all run in the background and not cause lag? Oh wait, enjoy your "pregenerated" dungeon with no lag... It will be finished generating in 2 hours, guess you'll have to find something to do until then! Also, having a processor dedicated to doing this would achieve the same results, but a lot quicker. As for the use of DLLs. Honestly, if I could make them I wouldn't be using BYOND, and I doubt many people would. Then again, I doubt most people on BYOND could make DLLs anyway. As for the atmosphere system I worked on. It didn't need to imitate the universe. It needed to imitate the volumes and flows of gasses as well as pressure (it probably didn't do it accurately at all). And any effects those would have. I gave up on it because it just wasn't possible to do on the scale (a 100x100 map) I needed without it lagging way to much. | |
You lack the correct logic to be coding. Don't let the programming control you. You are supposed to control it.
| |
The Magic Man wrote:
Not really, there is a lot of ways BYOND can become way to laggy to reasonably host a playable game. rgb() itself shouldn't cause any slowdown at all--all that proc does on its own is convert three numbers to an HTML-formatted color like "#FF5500". Using said color in various icon operations, however, can be slow. In BYOND 3.0, icons were limited to 256 colors (including one transparent color), but the use of palettes made colorizing operations very fast. Now of course BYOND doesn't use palettes in its icons, so changing an icon's colors takes more time. However since icon operations are a known bottleneck in speed, it's something you can plan around. Create an icon of the color you'll need and cache it--that's just one simple option. Another example is AIs. Sure you can disable ones not being used. But what happens if a lot of them are being used? It is a lot really. It's very rare for even the most advanced console games to be handling AI for that many units at once. If you really need that many AIs to be active at one time, though, you can always do little tricks to eke out more speed, like radically simplifying the decision loop for units that aren't in much danger of interacting with the player in the short term. That kind of thing can scale, too, so AIs farthest from the action can be a little dumber while AIs in the mid range can be just sort of average. Most of the time, though, it makes sense to put units to sleep that aren't really in action. Or the example I want to use it for. Randomly generating content. That may or may not be avoidable depending on your generation algorithm, but based on your other comments in this thread it seems you have little experience with optimization. Optimizing your code can go a long, long way. Remember, arcade games of the '80s did incredible things with hardware far less sophisticated than anything in a modern cell phone. They managed that through intensive optimization, not just in speed but also in code size. You should really run the profile tool while generating maps, running AI, etc. so you can see where some of the slowdowns are. Now imagine this once or twice every minute. Makes for a fun game if you ask me, and there isn't a lot that can be done about it, because in BYOND things like generating large, random maps are cp intensive and no one can do much about that. The programmer can do much about it, though much also depends on the complexity of the algorithm. In the worst case you can always split up your dungeon generation and sleep(1) at certain milestones, making the generator take longer overall but avoiding any issues like slowng down the game for all players. Darke Dungeon makes players wait when going to a new dungeon level so this wouldn't be unexpected. Anyway. If I am doing these wrong then prove it to me. world << rgb(255, 170, 85) Make a decent AI (one that will wander randomly until it finds a player, then follow and attack a player once it sees them) that can be used 2000 times simultaneously without lag. That's not a realistic goal. Anywhere a player might be, there should really only be maybe 20-50 AIs at most active in their vicinity, and certainly nowhere near as many on screen. As the player moves into new areas, some monsters/NPCs can be put to sleep or offloaded and new ones wakened. To preserve the illusion that monsters are wandering around randomly from everywhere, a relatively simple manager could look for shortages in monsters in a given region and spawn more, bias monsters that are farther afield toward moving toward a player (but still mostly moving randomly), etc. You can also get more bang for your buck out of AIs by making them smarter. Make them react to noises the player makes. Make some explore the map by choosing random destinations within the player's region, foraging for food or what have you. You'd be surprised how effective this is. The thing is though, you can't really run 2000 AIs at once. It could never work well. Make a random dungeon generator that can generate dungeon floors in less than 1 second. There are lots of ways to do that, but the type of algorithm makes a difference in its final execution speed. Also, I have tried this and on a large scale it is just not feasable to use. But make system to imitate atmospheres. Things such as pressure, wind and composition all have to be accounted for (things such as the flow of gasses, fire that cannot exist without oxgen and so on all have t be accounted for). Now try and make a system like that which will run on a map sized 100x100 without it using more than 5% CPU (anymore would steal away from parts of a game that are more important and need CPU more). Simulating all of that could never be done without a lot of brute-force calculation, so obviously BYOND will have a bit more trouble with it, being an interpreted language. It is, however, possible to fudge that with a system that just deals with interconnected regions. If an entire room counts as one region and it only has X points of entry/exit, you effectively have a much simpler graph and hence a much smaller set of calculations. This can be further optimized by not calculating any rooms where there is no pressure differential, ignoring differentials below a certain threshold, etc. Always simplify whenever you can. Ok, go. If I am doing these things wrong then show me them done right. Optimization depends a great deal on your end goal and your expectations for gameplay, so it's not something someone can just show you. Obviously I can't tell you how to optimize your dungeon generator without seeing it. Also some of the ways you might optimize through simplification (like using fewer "alive" AIs at a time, breaking up an atmosphere system into regions) are not necessarily trivial to design, even though they are vastly superior than brute-forcing the problem. It requires creative thinking, and you may have to be willing to cut corners on some things, knowing that your goal is a playable game and not a perfect physics simulation. When I talk about cutting corners I don't mean in ways that would make quality suffer. But in the end it really doesn't matter if a unit the player won't be able to see anytime in the next 30 seconds is operating at 100% intelligence or even active at all--you can always shut those down or even leave just a few active. When calculating for an economy and store prices, you don't have to have 200 NPCs going out and finding loot to sell as long as you can estimate that since your last visit, maybe 23 NPCs sold second-hand shortswords while 8 bought them and the price has gone down as a result. It's not important that something be happening right now if you can't see it, as long as when you visit an area the game can make up some history with a back-of-the-envelope calculation. Your dungeon generator might be able to flesh out a rough outline for a dungeon in mere moments, detail just a small portion of it, then detail the rest as the player visits. Level-of-detail calculations are used constantly behind the scenes in games that render 3D environments, and the same kind of logic is used for AI and other elements of those games. Lummox JR | |
The Magic Man wrote:
As for the use of DLLs. Honestly, if I could make them I wouldn't be using BYOND, and I doubt many people would. Then again, I doubt most people on BYOND could make DLLs anyway. There are a number of programming languages (such as Pascal) which are fairly simple to pick up and can be used to create libraries. I was going to write a full web server add-on for BYOND as a DLL but found creating windows a bit tricky (although it was still perfectly possible to create the server, it made monitoring the server a bit difficult). I also started an interface for the Irrlicht 3d engine and it was fairly simple to do. The main challenge in things like this is transferring information between the BYOND host system and the DLL, since only strings are directly permissable. | |
The Magic Man wrote:
As for the zombie AI problem. Depends on the map size. But on a 100x100 map (which ia fairly common) after testing 100 zombies is not enough. I was using 300 zombies and it didn't seem like enough on some maps (just so you know, in a zombie invasion the whole point is to be swamped by zombies so much you cannot move. Zombies individually aren't a problem, they just have power in numbers, overwhelming numbers, unless you're using super zombies that can run and punch through walls, but I'm not talking about those sorts of zombie here). I'm sorry but if you're going to have that many zombies in that small of an area 30% of the tiles would have one. Then you don't need a sophisticated AI so yes a well optimized one could be created even up to 1 per tile because they'd be able to be very very simplistic Also, AIs can be used in a large amount even in a small game. I uploaded a source code to BYOND not long ago to an incomplete game. This situation here's what you do. One optimize your blasted ai algorithms. If you don't know how to do this get help, and yes possibly from outside of beyond. Second lets say you've optimized all you can and tried to optimize other places to help alieviate the "lag" and it's still there, did you ever wonder why the ability to move a player between worlds was there???? I mean seriously. Have you ever seriously tried to make something like a RPG before? Each map might only have a few AIs running on it, but with a few players those small numbers can quickly shoot up into the hundreds, and CPU useage on even the most efficient AIs shoots up in a similar way. Ok I have no clue why in the bloody hell you would generate that many floors in one go even with different themes. Even if each person had a unique dungeon if you did one floor at a time ::cough:: pass a parameter ::cough:: then you would be creating one of those everytime everybody went to a new floor simultaneously. Now if you start storing those maps / levels. You can reuse the maps for different players. Wait there's more process reduction. Shall I keep going or have you developed some creativity yet?? Also, having a processor dedicated to doing this would achieve the same results, but a lot quicker. Game even the most modern ones do not take over a specific processor that is up to the operating system the games create threads, processes, and other low level items but the operating system chooses the processor. Mainly because each multiprocessor cpu even a dual core has a different signature that you would have to program into the games architecture much like it used to be for graphic cards. Nobody and I mean nobody is at that point yet. Yes there's some 3rd party libraries being developed that are working on it but do you really want to know when they'll likely be released?? As for the use of DLLs. Honestly, if I could make them I wouldn't be using BYOND, and I doubt many people would. Then again, I doubt most people on BYOND could make DLLs anyway. I can make them and can teach somebody to in an hour face to face. People use beyond because of the speed of development and the community more than anything else. There are lots of other game development platforms out there even full blown 3d ones for a decent pricetag. Having the ability to extend the system is a godsend if you run into something it can't handle. And if you don't know how to make one here's a simple answer to get you started. Google it. As for the atmosphere system I worked on. It didn't need to imitate the universe. It needed to imitate the volumes and flows of gasses as well as pressure (it probably didn't do it accurately at all). And any effects those would have. I gave up on it because it just wasn't possible to do on the scale (a 100x100 map) I needed without it lagging way to much. Somebody already gave you a partial solution to this. Use areas then check those. Doubt the outside world would have a huge impact on this other than a steady pressure. Second dumb it down don't recreate it like it would happen in the real world. Yes make it pseudo realistic as realism "CAN" be good but don't overdue it or it will 1.Be abused in some way 2.Start getting annoying as everything always works exactly how you expect it to While this might seem to be a little harsh that's not the point. Yes multiple threads / processes could be "useful" at times but the level of complication it would add to a programmer to enable it by default is overwhelming if it was a default thing. If you really need it learn how to create DLLs as you can get them to run in their own thread, but remember you have to deal with asynchronous issues then. Like what happens if you don't have what you need when you need it. But please don't ask for something you don't understand yet. Learn about it first, learn what it really entails. | |
Your math is... A lot wrong just so you know. A 100x100 map has 10,000 tiles, 300 is 3% of those tiles, not 30%. Doesn't seem like such a big amount now, does it?
As for the AI, it might not be the best ever, but I optimized it the best I could without losing any of it's functionality. http://www.byond.com/members/TheMagicMan/files/RPGsr.rar If you or anyone thinks they can do better while maintaining all of the same functions then go ahead and try, until then shut up about "lol optimizations!!". Also, redirecting players to a different world would only work now that I have a multicore processor, provided each world is uses a different core that is. But again, I'd rather have multicore support and everyone on the same world! As for the dungeon generation. I wasn't generating them all in one go. I was generating them one at a time, as they were needed. Hence there being possible a lot of small spikes of lag. I also stated that I did not store or save map levels, because when the dungeon was empty it was entirey generated from new when someone else entered it. Next time, read my post before you try to make yourself look smart! I can make a DLL as well if you want to get technical, and I can teach someone to make one in less than a minute. Hell, most IDEs now-a-days come with a built in function to to make them. Sure, they don't do anything, but it is still a DLL. But I was talking about a DLL that has some function, such as random map generation. I doubt it would be too hard to learn a real programming language, but I am too lazy and have a full time job (with mandatory overtime, which can sometimes be 50-60 hours of work a week). I don't have the free time to make games in BYOND, let alone some other, more complex language. | |
I do use the debug options tht come with BYOND to try and optimize things.
With the zombie AI I made I used it a lot, while asking for help from BYOND members. Though they like throwing around the words optimization a lot none of them seemed to be of much help at all. I also did exactly what you said, zombie AIs that were far away were dumbed down. They would simply pick a point closer to a player (but not so far away that BYONDs inbuilt functions couldn't work out how to move there) and then move there. Get to that point and repeat the process. Once they got close to a player only then did they start acting a little smarter and trying to chase after players and so on. Despite everything I tried I could only get it to run 300 times and CPU usage would jump around, but was between 5 and 20%. I also did break the random map generation process down. First a layout would be generated, then it would work out all possible tiles where something could be placed and keep a list of them. Then it would place items and then monster spawning points by picking locations from that list. I'm not really sure if or how it could have been broken down any more than that though. | |
The Magic Man wrote:
I do use the debug options tht come with BYOND to try and optimize things. Bear in mind optimization is far easier in your own code than someone else's, because only you fully understand your goals and what design choices you're willing to make. I also did exactly what you said, zombie AIs that were far away were dumbed down. They would simply pick a point closer to a player (but not so far away that BYONDs inbuilt functions couldn't work out how to move there) and then move there. Get to that point and repeat the process. Once they got close to a player only then did they start acting a little smarter and trying to chase after players and so on. If you have 2000 zombies scattered throughout a virtual city or what have you, dumbing them down isn't quite enough; that should be your second or third tier of AI but not the lowest. Break down your area into small regions, and only keep the player's current region and maybe the nearest neighboring ones active. Within the active regions, use the dumbed-down AI for zombies that are more than, say, 1.5 screens away from the player, and smarter AI within that range. Outside the active regions, turn the zombies off totally--you can still have zombies move around from region to region periodically by just keeping a count of zombies per area and having a manager proc periodically adjust those counts; this can also be used to bring new zombies into your active regions, by making them appear on the border and work their way inward. I also did break the random map generation process down. What you just described isn't actually any kind of breaking down into different levels of detail. The layout generation is the first place you need to start thinking about LOD, and placing items/monsters is merely a later step you'd have to do anyway. LOD involves reducing something complex like a finished map into a simpler structure, and complexifying the simple parts as you go along. Designing around that idea can also speed up construction in general. As an example, take Rogue. In Rogue and in many Roguelikes, the map is made up of a series of rooms connected by hallways. At a simple level this can be represented by a graph of nodes (rooms, T junctions, and dead ends) and edges (corridors), and this can be simplified further by considering only rooms as nodes. In Rogue there will never be more than 9 rooms per level. The particular size and placement of each room is another level of detail. New monsters are generated periodically, but never in the same room as the player. When items, traps, and initial monsters are generated, it's done on a simple per-room basis instead of treating all tiles equally. Some things will resist LOD calculations, such as giant mazes, although I wouldn't call the task utterly impossible there. For dungeon layout a la Rogue, you can often generate a room graph first and then actually plan out the corridors. For city environments, because everything is laid out in blocks you already have some LOD working in your favor. For outdoor areas like forests and grasslands, generating the map on the fly is cake. Without knowing how your generator works I couldn't say more, but it seems unlikely that in a zombie game, you'd be forced to do things the long way. Lummox JR | |
Yeah the first one I'll give you.
The second I might just give a shot to shut you up The point of multiple worlds is to break up the servers into different machines not put them all on the same machine so that they'll end up using the same amount of resources As for saving the maps generated I said saving them could help reduce the lag. And I didn't say generating 50 maps at a time I said generating 20 - 50 levels at a time would be bad. By storing levels and reusing them even a set number of times, it could reduce the amount of processing time significantly. Let's say you use a level for 2 unique players that'll cut your map creation time in about half. Notice it's about as you'd have to check to make sure it would be viable to reuse the map and still make the person feel like they were getting a unique map. In a game appearance is everything. Don't talk to me about time, I have 2 jobs working 40 hours a week for both of them, well ok so ones self employed but add on top of that I have 2 kids. If you really want to do it set back 15 - 20 mins and start slow. And notice how you're still skirting the major point of the sub-threads. Nobody is bashing on you about the first 2 requests. The multi-core support is unreasonable, unwarranted, and unneccessary. Byond is cross-platform, and single threaded. It would be possible for multiple threads but multiple cores would be a programmers nightmare on both sides. Just imagine the rammifications to debugging an app alone.. Unlike you I still remember when multithreading first came out. Most developers still refuse to touch them just because of the "potential headaches". Like I said know what you're really asking for before you ask for it. Just opened the source and all I can say is my god man, you really gotta work on your programming basics, not language features just basic understanding of how programs "should" br written in most circumstances. I was gonna take a look and see what I could find but I can't even find my way through this mess easily. Not to mention it won't compile... Helpings one thing coding something for you is quite another. Fix the existing bugs, comment the code enough so a quick glance will tell what the flock is supposed to be going on instead of having to dig through the code to figure it out. Do those and I'll give it another look, til then all I can say is wow, and I thought PHP programmers made some bad stuff...... | |
StolenSoul wrote:
Nobody is bashing on you about the first 2 requests. The multi-core support is unreasonable, unwarranted, and unneccessary. Byond is cross-platform, and single threaded. Nah, it's actually not a dumb or unfounded suggestion. It'd be good. It's simply way too much trouble to add. It would be possible for multiple threads but multiple cores would be a programmers nightmare on both sides. Just imagine [...] BYOND worlds themselves, or more specifically the DM language don't have to become multi threaded. It'd be nice to just have the slower internal functions multi threaded so they're not such a pesky bottleneck. Just opened the source and [...] Indeed, contrary to what he claims, I can see there is lots of room for optimization in his code, and I didn't even go to the trouble of reading all of it. | |
Kaioken wrote:
StolenSoul wrote: Multi-threaded is reasonable, there's only a handful of systems that run multi-core support, and if you'll take a look at those there's a reason. They have the team to support it. And even most of those only run on 1 OS. It's overkill. Not saying multiple threads would be bad. It would be possible for multiple threads but multiple cores would be a programmers nightmare on both sides. Just imagine [...] The way he was wording what he wanted he would want to be able to pass one of his functions off to another core. Unless beyond was to suddenly become a lot better staffed... and I mean a lot better staffed to handle the bugs that would inevitably erupt when you gave multi-core capabilities it's not even slightly realistic. Thus why I said, multi-threaded would be possible. Even adding a hook to spawn a process into a new thread wouldn't be "that bad". As long as it was off by default. But fully going into multi-core support... not even the big boys are going that route yet. | |