There are ways around these limits, especially in RPGs where most of the objects you're talking about aren't even being interacted with. Specifically, you need to unload things that aren't used or seen by players. Ever notice how most non-BYOND games have loading times? Those games would be impossible to run if they had everything loaded into memory at once as most BYOND games do. Even with your problem in [link], you could add/remove overlays from the trees as they get within a certain distance from a player. It costs some CPU time naturally, but you save memory and get to have your game look as you want it.

I'm not disagreeing with your suggestion; of course BYOND could benefit from increased limits. But I think you're giving up and thinking that you need a new feature for something you can already do - you just have to put some more work into it for a large game, as they do in the world outside BYOND.

Doubt it would have even taken 2 years to do something like this, and it's not like other things couldn't have been done at the same time.

Also, this isn't an odd complaint. It is a serious complaint and a serious limitation with BYOND. The sort of limitation that can put people off using BYOND and stop potential new users of BYOND from using it (and using something else).

I am also not trying to make a WoW clone. I am trying to make a small RPG, sure it is something that will be bigger than most BYOND RPGs, but that is because they are all half assed attempts at games.
But BYOND doesn't like making this possible to do!

I'd rather more work be put into the gameplay than the enemy variety and graphics. Most games suck because they have horrible or uninteresting gameplay, and there are countless examples from times past and present. Just on BYOND, the first lousy game I can think of off the top of my head happens to be an RPG -- Mystic Journey. There are a total of four quests, two of which you're never even alluded to by the game itself and only discover because other players tell you about it, the battle system stinks (any game that requires mashing one button stinks), the equipment system stinks, the flimsy story is completely uninteresting, it seems almost no work was done after the initial "tutorial", the players of any server form a clique with the host who's pretending to be female and has somehow gained moderation verbs to spawn infinite rare items for their friends who constantly annoy the piss out of you, the list goes on and on and I haven't even gotten to the crappy RPGMaker graphics yet.

Anyways, my point obscured is that I can excuse the worst graphics in exchange for good gameplay. I remember a tiny RPG made by splattergnome, I believe, who utilized nothing more than text mode graphics, and I loved it. I'm still waiting for a full version, and would rather play it than any of the crappy level-grinding I find everywhere else.

The Magic Man wrote:

Doubt it would have even taken 2 years to do something like this, and it's not like other things couldn't have been done at the same time.

Allow me to interject some realistic numbers from someone who has experience working with BYOND's source. I get this all the time: "It can't be that hard to implement ____!" Not only can it be hard, but it can be time-consuming. Currently two programmers are maintaining 7+ major components of BYOND: The pager, Dream Seeker, Dream Daemon, Dream Maker, the website, the hub, and the database. There are also other, lesser components. So when I say a project is time-consuming, understand that time won't be spent on improving anything else (including bug fixes).

A huge part of the limit expansion project involves changing around a lot of datatypes that were originally hardcoded as 2-byte unsigned integers, and making sure functions have the right argument/return types. To a large extent I did this already, as a side project a few years ago, and yet more remains to be done. It took a while, and that's just looking at the function calls.

The datum expansion was a related project, for which the above groundwork was thankfully already done. It took quite a while to research and execute, and ended up introducing a couple of minor bugs for the next couple of versions. Datums were the easiest item to change, mind you, because they are handled totally internally and they don't end up encoded in BYOND's bytecode like, say, strings.

Increasing the string limit would involve doing much the same thing, but also diving deep into the compiler and the interpreter to be sure that either the 64K limit is maintained for compilation only, or a more complex version check is put into place so the interpreter can read a 4-byte code. Many parts of the compiler and the interpreter are still a black box. Significant research time would be involved, time which can't be spent on other things, and I expect implementation would cause at least as many short-term problems as the datum limit expansion did. I estimate this project would take 2-3 weeks at a minimum.

Objs, mobs, overlays, etc. have limits encoded into the very message format itself. Many, many messages received by the client would need to be redone to allow for variable 2-byte or 4-byte form depending on the server version, while the server messages would need to be redone to use the 4-byte code. This would also introduce a server/client incompatibility in that older clients could no longer connect to new servers. Project estimate: 2-3 months, plus another month for closed testing, with a high likelihood of several new bugs making it into the public version. This would mostly mean a freeze on bug fixes and other features for the website and software for that time.

I am also not trying to make a WoW clone. I am trying to make a small RPG, sure it is something that will be bigger than most BYOND RPGs, but that is because they are all half assed attempts at games.
But BYOND doesn't like making this possible to do!

Having accomplished some limit-stretching projects on BYOND and having seen many others, I can say with some authority that this is a flawed assessment. There are few things I've found to be outright impossible in BYOND that would be required for a good-sized, even massive RPG. Poor resource allocation is likely to make the project's goals harder to achieve, but that's true in literally any programming language, especially when it comes to games. In general there aren't a lot of ways to bump up against BYOND's limits if you have a good design.

And believe me, I say this as someone who's seen a great many systems fail because of things they couldn't do. Whenever I try out a game design platform, programming language, CAD program, what have you, I seem to be an expert in quickly finding the limitations of the system. Yet I've been an active part of the BYOND community for almost 7 years now. Most of the issues I regarded as somewhat (not entirely) limiting were resolved in the round of betas from builds 307 through 324. And lest it be forgotten, a lot of the time in the last 2 years that was not spent on increasing obj/mob limits went into removing one of BYOND's biggest can'ts of all: It couldn't be used to make a game with any interface other than the stodgy 3.0-era Dream Seeker window.

Lummox JR

The Magic Man wrote:

You can't fit an elephant inside of a suitcase regardless of what "clever design" you try and use. You have to settle with having only a part of that elephant in the suitcase.
Which is basically the problem with BYOND.

Not really, neither is your analogy any similar to the situation. Anyway, no matter how many times you repeat your (unchanging, mind you) argument, it's not really going to be any different, and it remains that BYOND has more than enough potential for awesome, large RPG games and the limits aren't such an issue as you make them out to be, especially not to programmers that spend time rethinking and considering their design instead of complaining about the program they're using.
For your tree problems, you've not given really any info about what you actually want with them, or what secret passages and areas are, but you can easily have tons of tree objects, multitile or whatnot, if you simply make them turf objects, which virtually have a much larger limit than objs and mobs, and are meant to be used for these kinds of things.

Doesn't having multiple map file increase the limit?

The Magic Man wrote:

You can't fit an elephant inside of a suitcase regardless of what "clever design" you try and use. You have to settle with having only a part of that elephant in the suitcase.
Which is basically the problem with BYOND.

The elephant is your core problem, though. WoW wouldn't exist if it was an elephant. Like any large game, it loads and unloads parts of its map as needed, and offloads items from memory that aren't in use. If you're just putting all kinds of stuff onto static maps and expecting you can use all of those maps at once at runtime, then yeah, you're gonna have some issues. If you allow for maps to be swapped in and out, handle AI with a reasonable sleep cycle, and follow other good practices, those limits just aren't an issue.

All I wanted to do was make game with maps the way I make them (good looking, full of detail). But I can't, because each extra bit of detail brings BYOND closer towards one of it's limits, no amount of "clever design" changes that, only using less detail does. But not even being able to make a game you are making look the way you want it to... It's not really good if you ask me :[! Especially when the only thing stopping you is the program you're using to make the game with.

As has been demonstrated many times on this thread, the program is not your "only" limitation. One of the limitations is the ability to imagintatively design around limits.

It's not like this is even anything major. But a 200x200 map has 40,000 possible tiles for detail, and normally I would squeeze in as much as possible, with the use of large sprites (which translates into the use of either overlays, underlays or objects) that can be 20,000+ details on a map of this size.

Handling overlays in some other way that allows you to load and unload them as needed was already suggested by someone else on this thread. Yes, it does complicate the mapping process a bit, but considering how much you're trying to squeeze out of the engine, you ought to be squeezing more creatively. It also sounds like if you're going to complain about limits, you've focused on entirely the wrong ones: The ability to use a larger icon size without cutting up into components would probably be more useful to you. So too would be something like I mentioned, an ability to seamlessly connect smaller maps.

3 Maps like this later and I have reached BYONDs limits, and I don't even have a game yet, just 3 nice looking maps!
Yet in any other program I could quiet easily use 10,000 maps like this and the only problem would be file size.

Even the act of deciding which resources are in view to display tends to be a crucial issue for many games and game engines. File size would be far from your only problem, especially when you're not taking any of the steps that would help manage memory issues.

Funnily enough, people seem to think I am trying to make something totally epic and massive, but all I want to make is more than 3 chuffing maps without using everything BYOND has got (when I make a forest just so you know, it is more than a handful of trees loosely scattered about, it can be on a 200x200 map several thousand trees packed in a random yet "cleverly designed" way which allows for secret areas and hidden passages).

Then your best approach is going to be some kind of meta-engine that will handle those overlays for you so you don't need a zillion of them packed onto the map. I'm in total agreement that it'd be nice if BYOND made that much easier to do, although I think just being able to "de-seam" maps would be enough to solve your problem. But I guarantee you the solution at your end is easier than solving it at the engine end.

Anyway, the major problem here above these limits is that... BYOND needs to become more modernized. This is 2008, not 1998 and people want to make games that show this.
This is where people jump in saying "Only 2 people work on BYOND blahblahblah", but other people don't care about those excuses, and when things like http://www.vbgore.com/Main_Page start surpassing BYOND (in a lot of ways it already has) why are people even going to use BYOND when they can use something else that can do everything BYOND can and more?

Tom has mentioned the modernization problem before. The problem is, you have only compliants and no solutions. Indeed you're not even willing to entertain concepts that could help you design around the issues you're running into, because you'd rather complain about the engine. When it comes to the fact that the engine has only two developers who are working on way too much already and would have to suspend other work in order to meet your demands, you still have no solutions. I'm not giving you an excuse; I'm giving you reality. What you're asking for is not possible on a timescale that will satisfy you, and it will necessarily demand putting a halt on other activities while it's done. You haven't offered any suggestions as to how this could be approachable, or even what incremental improvements you can imagine that would make your development easier--because incremental gains, like improving just one of the limits first--are a lot more realistic.

Once some current stability issues and new-user experience concerns are addressed and we go back onto a feature cycle, I'd be happy to pick up one of these projects, something that would make your kind of game easier to do without having to jump through design hoops. However I don't make those decisions, and it may well be that some other issue demands more immediate attention. It will likely be, as I mentioned in objs and mobs, that some of the expansion project will turn out to be very tough. Still it's worth doing, which I've never disagreed with you about--it's just that it's a major overhaul, and you may be able to work with a lesser improvement. So give us some suggestions, a list of incremental gains that might each, individually, make your design dream easier to achieve.

Lummox JR

Lummox JR wrote:

The elephant is your core problem, though. WoW wouldn't exist if it was an elephant.

Indeed. Learning to think consciously about resource management is essential, and the current limits actually teach you to do that quite well. If you have a game where you're hitting the limits repeatedly, you're either doing something wrong or raising the limits will most likely simply cause your game to be unplayable due to lag.

Of course there are exceptions; but for the most part, that would be the case.

I still have the drawing board for a rather 'large scale' RPG lying around, which implements the following in order to try and keep a lagless, resource-low environment:

All maps are loaded in a seperate instance of DD, and players are shuttled around between worlds when they move between maps. This is similar to the way EverQuest 1 f.eks works with 'zones', except I can't quite selectively load textures in the same way. In addition to this, areas within a map which don't have nearby players are 'dormant', AI is disabled and in general everything is 'unloaded' until its needed.

Using this method of a cluster of DD instances, you could most likely bypass the limit you're speaking of. Write a library to send players between DD instances and perhaps write a login server as the 'entry point' into the game (since each DD instance will be running on its own, presumably random port within a range) which will simply check if the map the player is on is up. If it is, send the player to that DD instance. If not, load it up then do that.

If you want to take that one step further, set up several computers to host that each can run a fixed amount of DD instances so that you have more computing power available. And set up a MySQL DB to manage data you'd otherwise store in savefiles, since you'd probably have multiple DMBs wanting to access the same files and that won't be as easily managable. Using MySQL also lets you reduce the amount of lists you keep around, helping with one of the smaller limits in BYOND.