Temple of The Roguelike Forums
Development => Programming => Topic started by: gorbeh on September 14, 2014, 09:34:13 AM
-
Hello!
Let me introduce myself first.
I am a (new) biotechnology student who is fascinated by ASCII graphics.Before roguelikes,I played alot of fantasy games,like the elder scrolls series and the gothic series,but as my age has increased,the interest of gaming altogether has faded.Except,of course,the interest in roguelikes.I have played DCSS,Poschengband,FAAngband,ADOM,and dwarf fortress.Two of them I managed to win.I loved the spell system and the beautiful balance of dungeon crawl,and the endless dungeons of the Angband variants.The seemingly endless monster unique list of poschengband was awesome too.Well,I could go on,but lets stick to the subject matter :-).
I had reached a point where I wanted to make a new Angband Variant,or a Frankenstein from the codes of Crawl and Angband together.I spent a couple of days learning C++,making good progress,but after some time I realized that no matter how fast I learn it,I can't reach a high enough proficiency level in Coding(In the time span I have) to realize my ideas.I started then to write down my ideas regarding a roguelike,both because as a means to not forget them,and also to show them in a roguelike website,with the hope of catching the attention of a coder who likes my ideas.
So,that was the introduction and explanation part :-).I hope you take time reading it.I wrote it in a format so as to adress the reader
Its too big to paste here
http://m.uploadedit.com/b039/1410686901357.txt
Please make sure you have time to read it,because it takes atleast 20 minutes,for a fast reader.
If you want to give it a shot,send me an email (abazariakram@gmx.com),or a private message.Have a nice day!
PS:It would be easier on the eye if you copied it into a txt file and activated word wrap,i forgot to do that @_@.
-
lol
-
Seconding mushrom patch's derision in more detail. Ideas are easy, the design and implementation are 99% or more of the work. You have a much better chance of powering through studying coding and doing it yourself than having a competent programmer make a game from your ideas.
-
I will give you a few ideas how to proceed in you project
1. Since you are probably a young game developer, you will learn a lot more if you start programming the game yourself. Without such experience, your design will always be weak and shallow. In general, unless it's a commercial project, be ready to do everything yourself.
2. C++ is an ok choice only if you already know this language well. Otherwise, I would suggest LOVE engine (https://love2d.org/) (LUA), or pygame (http://www.pygame.org/news.html) (Python). Especially, if you don't know much about programming.
3. > "animations should have a playtime of 2 or 1 milli seconds"
It would not work. Many screens update just 60 times per second, that is, they update once every 16 milliseconds. The human eye and brain are also not that quick either. Animating actions in turn-based games is actually rather tricky, if you think about it. Example. You are surrounded by 100 mobs (it's feasible, it's just a square 10 by 10), do you want to animate their actions one by one or do all the animations simultaneously? If you want to do them simultaneously, what if some mobs are faster than the other? You have to think about such details beforehand.
4. The idea of multi-screen cities is ok. But try to implement such city generation yourself to see what are the possible problems. Procedural generation of a city is significantly harder than making random caves with random monsters. This is why in the majority of roguelike games, the village maps are not random but predesigned. Of course, randomly generated cities is a great thing, but make sure that you can pull it off.
I did not read the rest of the document, it's too long.
-
Seconding mushrom patch's derision in more detail. Ideas are easy, the design and implementation are 99% or more of the work. You have a much better chance of powering through studying coding and doing it yourself than having a competent programmer make a game from your ideas.
Unless you're prepared to pay them, of course.
-
As a rule, programmers with the know-how to make a game usually have plenty of ideas of their own - more than they have time to work on. It sounds harsh but they're unlikely to volunteer to bring someone else's idea to life.
I'm not knocking the value of ideas - I'm an ideas person myself - but 99% of the graft is in actually programming the game (or writing the book, or painting the picture, or whatever, depending on the creative medium in question). That's where the act of creation takes place. It's where the problems arise, and by extension where all of the problem solving has to occur. Someone who is capable of doing that will prefer to exert on their own projects, not someone else's. I'm not trying to shoot you down, just trying to manage your expectations.
Realistically you have three options: 1) learn programming and make the game yourself; 2) pay someone to program for you; 3) rope in a friend who can program and is willing to help out (by this, I mean someone who already knows you and will help you from good will and friendship, not a stranger).
I know you said you tried learning programming and felt it was too slow, but someone you ask to program for you will already have put it in all of that time to learn, and you deciding it's too slow a process could easily come across as "I can't be bothered, I want you to do the work for me". No one wants that.
Additionally, as koiwai mentioned, the document is too long. If you're going to keep pitching your idea and hope that someone is so impressed by it that they really want to create it for you (long odds), you need to make it short and punchy. You know the phrase 'elevator pitch (http://en.wikipedia.org/wiki/Elevator_pitch)'? That.
-
If someone has designed a original rpg system (+content for it) and it looks like serious stuff then I'm ready. But in this case it doesn't seem to be so.
-
As a rule, programmers with the know-how to make a game usually have plenty of ideas of their own - more than they have time to work on.
There's always an exception to a rule. Me, for example. I love programming, but I'd prefer that someone else was doing majority of design in my game. Unfortunately, it is nearly impossible to find a good designer for an existing project.
-
it is nearly impossible to find a good designer for an existing project.
I think I'm a good game designer.
-
I think I'm a good game designer.
Everybody thinks he's a great designer. This doesn't make the search any easier. Just the opposite, I would say.
-
Everybody thinks he's a great designer.
I'm also experienced.
-
I'm also experienced.
There's no doubt about it. I remember, though, that you have been developing a game (or two) for quite many years without a playable release, so the game is probably not that great, either design-wise or code-wise, or both.
-
you have been developing a game (or two) for quite many years without a playable release, so the game is probably not that great, either design-wise or code-wise, or both.
How would you know?
-
If you want to code a game you need to learn to code.
If you want to write a spec for a coder to implement, you need to learn to write.
It is clear from your message that you have not done the first. It is clear from the text document that you linked, that you have not done the second.
I think most of the ideas presented in your document are irrelevant to game design and belong in a separate category, "interface choices." The little that *is* relevant to game design is unclear, or presented without discussion of its effect on players and game balance. All of it is unorganized and not laid out in any logical order or sections. And many places have references to things "elsewhere in the document" that you did not in fact put anywhere in the document.
The short version of the story is that if you do find the nearly-mythical "coder looking for a writer", what you have written here will convince them that they do NOT want to work with you.
Most coders while not working for pay don't care much about somebody else's ideas. So your odds of getting someone to work with you on creating a game are slim to start with. In order to convince people that it'll be worthwhile to collaborate with you, you need to have your ideas well thought out, well presented, and well organized. Because otherwise, it's really a whole lot easier to ignore your ideas than to find your idea for a particular thing buried somewhere in your document and figure out whether it's a good idea or not. Remember, the point for a coder in having someone else do the writing is that it's supposed to HELP. If extracting meaning from the writing is hard, it isn't helpful.
So if your file of ideas isn't at least as well organized as, say, this guide to rogue (http://www.gamefaqs.com/pc/580055-rogue/faqs/9646), then posting it is going to actively discourage people from working with you. But you even have more things you need to cover, because that's just a player guide. An implementer's guide must also explain why each thing is a better idea in terms of game design than the alternatives.
-
I appreciate the careful elaboration on my first response given by other posters.
I would like to comment slightly more seriously on one aspect of what the OP puts forth. While there's no way he's going to get anyone to do anything on a new project of his own, it's quite possible that he could find a development team of an existing angband variant or a crawl fork that would be sympathetic to his broad notion of combining the two somehow (although I think this is mostly a bad idea, maybe a pulpier, more linear angband-like game with crawl mechanics could work... or something).
Basically, if you don't know how to program and you don't have the requisite skills or leadership ability to start your own project, there may yet be a future for you in angband variant or crawl fork development. Start small by trying to get contributions accepted. Over time, you'll be able to insinuate more of your unique ideas into the project through discussion and persuasion, as opposed to raw coding. (You'll still have to code a lot yourself though.)
-
I think everybody else has already covered the 'give up trying to convince anybody to make your game for you' angle, so I'll add some advice on learning to do it yourself:
If you find C++ too difficult then don't use C++. It's a great language if you know what you're doing but it's absolutely the worst language to pick for somebody who (to be blunt) is too lazy to learn how to use it properly. The good news is there are plenty of other languages and game making tools which are a lot easier to get to grips with. Python is a pretty nice language for beginners and it does a lot of stuff for you that C++ doesn't - you'll definitely be able to learn it and use it a lot faster. If you really can't deal with that then there are other things like Gamemaker out there that you could try.
-
How would you know?
I don't. On the other side, you haven't provided anything to make anyone think that the game(s) you are working on is great.
-
I don't. On the other side, you haven't provided anything to make anyone think that the game(s) you are working on is great.
No wonder you have difficulties to find team members. Then again, so do I, because I'm even harder to people than you. But I'm also different, because it's really, really difficult to find people who are in the same level with me, you know.
-
I think everybody else has already covered the 'give up trying to convince anybody to make your game for you' angle, so I'll add some advice on learning to do it yourself:
If you find C++ too difficult then don't use C++. It's a great language if you know what you're doing but it's absolutely the worst language to pick for somebody who (to be blunt) is too lazy to learn how to use it properly. The good news is there are plenty of other languages and game making tools which are a lot easier to get to grips with. Python is a pretty nice language for beginners and it does a lot of stuff for you that C++ doesn't - you'll definitely be able to learn it and use it a lot faster. If you really can't deal with that then there are other things like Gamemaker out there that you could try.
I use Gamemaker. It's totally doable but you DO need to know how to code. Absolutely. It turns a TON of chores into easy mode though. Hell I've been using it so long I barely remember how to begin making a game in C or Pascal.
-
Also, to the OP. I have hundreds of pages of idea for games. I think your list seems like ideas to make Angband/Crawl better.
With effort you can tweak the heck out of Angband without being a dynamite coder.
-
I use Gamemaker. It's totally doable but you DO need to know how to code. Absolutely. It turns a TON of chores into easy mode though. Hell I've been using it so long I barely remember how to begin making a game in C or Pascal.
Gamemaker is really great and does make anything to do with 2d graphics a snap (you can't beat it for rotating sprites, creating easy particle emitters, making media a snap, etc), but it has some strange limitations. Arrays are pretty limited, and are just about the only data structure you have to work with. There are absolutely no advanced data structures of any kind (no objects or even types/structs, which is a major bummer). By extension of no objects, there are no pointers, meaning no (easily implemented) linked lists, queues, trees, etc. I've seen a few extensions people have coded for it, but they are pretty wonky.
That being said, if you ignore the drag and drop interface, GML is at least vaguely similar in structure to C++ and Java, so it's a good starting point if you are wanting to learn.
I've got a hybrid Star Control-roguelike game around 50% done in Gamemaker, and the ease of the things it does well outshines its limitations. If they would just add some better data structures, it would clearly be the way to go for any 2d project, roguelikes included.
-
Here are all of those data structures Brigand said aren't doable.
http://docs.yoyogames.com/source/dadiospice/002_reference/data%20structures/index.html
Maybe I just misunderstood what he was saying. But all of those things are in there.
-
I will recommend T-Engine as I tend to do. I knew NOTHING of programming when I started on Veins in June 2013, so a year and three months ago.
T-Engine is incredibly easy to pick up and you can pick apart ToME and other published modules to proceed.
-
Here are all of those data structures Brigand said aren't doable.
http://docs.yoyogames.com/source/dadiospice/002_reference/data%20structures/index.html
Maybe I just misunderstood what he was saying. But all of those things are in there.
sorry, I am pretty unclear in how I wrote that. You can always create these structures using arrays and filling them with indexes to the object; you just aren't able to create a user defined object with fields and methods (and pointers to other user defined objects) - which is why I put easily implemented in quotes. Only having arrays to work with is wonky.
But, It does appear that they are constantly adding new features to gml, so it may be in the future. Maybe they have recently added this, but the last version I bought did not have oop support.
-
Did you read that link? Gamemaker includes all the functions required to manipulate the following:
"stacks, queues, lists, maps, priority queues, and grids."
I never use them, I stick with arrays and use tons of heredity, but they are in there. Not just arrays.
Or are you saying that GM handles them poorly? Is that it? I wouldn't know...I do know other GM users that make use of them extensively. But maybe they are just used to the clunkiness.
There's another program coming along too, I've not used it, but it's a competitor to Gamemaker:
https://www.scirra.com/
Also, of course, T-Engine.
-
Did you read that link? Gamemaker includes all the functions required to manipulate the following:
"stacks, queues, lists, maps, priority queues, and grids."
I never use them, I stick with arrays and use tons of heredity, but they are in there. Not just arrays.
Or are you saying that GM handles them poorly? Is that it? I wouldn't know...I do know other GM users that make use of them extensively. But maybe they are just used to the clunkiness.
There's another program coming along too, I've not used it, but it's a competitor to Gamemaker:
https://www.scirra.com/
Also, of course, T-Engine.
I did read that link, but I must be explaining it poorly. I'll give you a simple example (that is probably already obvious to you):
Most OOP roguelikes have an 'actor' class, or something similar like that. Lets say you want to add a new monster to the list (or queue, or attack, or whatever) - it can be a new action on the stack, a new monster in the list, whatever, it doesn't matter: actor.next = new actor();
That's it. You can add a constructor that will instantiate the actor for you with default behaviors, and you can pass the monster type to direct the constructor at creation time (eg, monster.next=new actor("goblin");) If you want to delete a monster in the middle of the list, its as simple as
monster.next = monster.next.next;
or if its at the end of the list
monster.next = null;
and you're done - if the monster you remove no longer has an active reference, the garbage collector frees that memory (some languages make you do it yourself, but you can have a destructor to take care of the clean up - either way its a hell of a lot better way to do it than what follows). You can pass an object reference wherever you want, and each object can have whatever methods you want attached to them: (monster.take_damage(3);) You know all this - this is programming 101 stuff.
Contrast this with GML, and using arrays for everything. A monster then is referred to explicitly by an index into a bunch of arrays....a bunch of arrays that cannot be easily redimensioned, and have memory reserved whether they are used or not.
name[3]='goblin';
hps[3]=10;
defense[3]=4;
inventory[3,1]='sword';
inventory[3,2]='helmet'
..... etc....
You now either have to have a capped number of actors, or reserve memory for a lot of creatures you may not be using. You have to iterate through the list to find what you want each time (not a huge big O, but it adds up) God forbid you want to copy a creature...then you have to laboriously copy every single array at a specific index, and unless you keep a position variable, iterate through the array each time to find a free index. If you add a field later, you have to go through all your code and update in every single place. There's no cohesiveness to the code. You have to iterate through an entire array every pass to see if there is an active actor at that index UNLESS you compact the list of actors down and iterate through a set number each time - which requires copying arrays to remove gaps in the list every time a creature dies/leaves/whatever. And if you do that, it invalidates EVERY data structure you are using that references creatures by indexes unless you go clean them up every time too.
Yes you can do everything with GML's array based data structures that you can with OOP, but it would be a hell of a lot easier if they just allow you to make your own classes/objects, which is the entire point of what I'm saying. Trying to program a balanced binary tree using arrays? Holy crap, you could, but it would not be fun. 'Easily implemented' is the keyword. Even worse, GML also has arrays restricted to 2 indexes (2D)... full stop. As opposed to a simple list/queue/whatever of objects with pointers to other objects in the structures which you can do in 30 secs with no support coded needed.
At the end of the day, its half a dozen of 1, or six of the other. If you program in a conventional OOP language (Java, C++, etc), you get the massive flexibility of an object oriented language but you have to write or use a potentially hairy 2d library (though there are some good choices out there that make it easy); if you use GML, you get AWESOME 2d graphics capabilities at the cost of being forced to use arrays for everything. There's another thread going now that talks about a system with heavy object interaction that might be worth looking at that you just couldn't do with arrays (you can't attach a behavior to an array index like you can with a class.)
If they have added this to the latest GML, then I stand corrected, and redact all of what I have said, but as of the last version I bought, none of this existed. It is a work in progress, and they have some really new nifty features each time I log in, but I haven't bought all the expensive available modules - I bought the first level package that unlocks all the standard features, but none of the add-ons. And whan I bought it, it wasn't called Gamemaker Studio, it was still Gamemaker 8.
-
Oh yeah, definitely. GM isn't built like that at all. If you are used to using those other methods it can be a big head switch.
I'd almost forgotten about a lot of that stuff, I've not coded outside of GM in at least a decade, besides going through code looking for errors for people.
EDIT: To the thread starter, you might want to look into the program called Construct 2. It costs money, but there is a free version. It is a drag and drop heavy system with no actual coding going on.
-
I'd almost forgotten about a lot of that stuff, I've not coded outside of GM in at least a decade, besides going through code looking for errors for people.
Nothing wrong with that - in spite of its limitations, I like it a lot too. If they added true OOP support, as far as my hobby stuff goes, I probably would just use it exclusively too.
-
It's Interesting and odd to read the comments about GM and compare them to the framework I've evolved for my own use.
I started with a lot of pointer based dynamically allocated structures of the type Brigand evidently prefers - but discovered that most of the central elements of the game (actors and events and the schedule and the map) need to have many references to each other, in places that depend on the semantics of individual subtypes of those classes - so deallocating anything WITHOUT leaving references to it somewhere is very difficult and gets more difficult the more different kinds of things you have. You wind up having to walk virtually the full game's data structure deleting references every time you want to delete anything. Otherwise, you wind up with dynamically allocated data containing references to deallocated things. If your references happen to be pointers, that's bad for two reasons, because there are two different kinds of bugs it can cause when you try to refer to the object the stale pointer points at. First, you can crash, which is bad, but you can also wind up referring to things allocated after the things the original pointers pointed at were deallocated, which is worse. Also, pointers were an extra headache for save-and-restore functionality, because you had to swizzle all the pointers to get a restored game where the pointers mean the same thing as the pointers in the saved game did.
So I eventually abstracted dynamic allocation, using a manager class for each data type. Now when I say New_Actor(), the manager for actors decides where it's going to keep the new actor and returns a reftype. The manager handles allocation, and keeps a pointer (the ONLY pointer to that actor to live in a dynamically-allocated data type) in a hash table keyed by the reftype value. A reftype value, unlike a pointer value, is never reused, so I don't have to worry about aliasing. I can deallocate on command, without worrying about crashes caused by following stale pointers. When something hands the manager a stale reftype, it returns a null value without crashing, which can be checked for and handled at the call site. Finally reftypes mean the same thing in a restored game that they meant in the saved game with no need for pointer swizzling; the new pointer value, whatever it is, is keyed by the same reftype value inside the actor manager, so the rest of the code, which handles data structures that contain only reftypes, never pointers, need never worry about it.
There's no "maximum number of actors," nor "vast amounts of wasted space", both because the data managers do dynamically resize the hash tables at need. This also takes care of "compacting the array", and does not require walking data structures changing reftypes stored in game data to refer to new array locations when it happens. The complexity cost is an O(1) hash table lookup whenever a routine needs to acquire an actual pointer to data, and that has not been a noticeable burden.
Anyway, the rules are simple. In any dynamically allocated data, you store reftypes rather than pointers. When you actually need a pointer, you use the reftype to look it up. Any time you use a reftype to look up a pointer, you check to see whether the pointer is NULL. If it is, that datum no longer exists.
And, um, underneath it all.... the data manager classes use hash tables which are implemented in terms of arrays. Which are what GM uses.... and what annoys Brigand.
One man's drink is another man's poison?
-
It's Interesting and odd to read the comments about GM and compare them to the framework I've evolved for my own use.
I started with a lot of pointer based dynamically allocated structures of the type Brigand evidently prefers - but discovered that most of the central elements of the game (actors and events and the schedule and the map) need to have many references to each other, in places that depend on the semantics of individual subtypes of those classes - so deallocating anything WITHOUT leaving references to it somewhere is very difficult and gets more difficult the more different kinds of things you have. You wind up having to walk virtually the full game's data structure deleting references every time you want to delete anything. Otherwise, you wind up with dynamically allocated data containing references to deallocated things. If your references happen to be pointers, that's bad for two reasons, because there are two different kinds of bugs it can cause when you try to refer to the object the stale pointer points at. First, you can crash, which is bad, but you can also wind up referring to things allocated after the things the original pointers pointed at were deallocated, which is worse. Also, pointers were an extra headache for save-and-restore functionality, because you had to swizzle all the pointers to get a restored game where the pointers mean the same thing as the pointers in the saved game did.
So I eventually abstracted dynamic allocation, using a manager class for each data type. Now when I say New_Actor(), the manager for actors decides where it's going to keep the new actor and returns a reftype. The manager handles allocation, and keeps a pointer (the ONLY pointer to that actor to live in a dynamically-allocated data type) in a hash table keyed by the reftype value. A reftype value, unlike a pointer value, is never reused, so I don't have to worry about aliasing. I can deallocate on command, without worrying about crashes caused by following stale pointers. When something hands the manager a stale reftype, it returns a null value without crashing, which can be checked for and handled at the call site. Finally reftypes mean the same thing in a restored game that they meant in the saved game with no need for pointer swizzling; the new pointer value, whatever it is, is keyed by the same reftype value inside the actor manager, so the rest of the code, which handles data structures that contain only reftypes, never pointers, need never worry about it.
There's no "maximum number of actors," nor "vast amounts of wasted space", both because the data managers do dynamically resize the hash tables at need. This also takes care of "compacting the array", and does not require walking data structures changing reftypes stored in game data to refer to new array locations when it happens. The complexity cost is an O(1) hash table lookup whenever a routine needs to acquire an actual pointer to data, and that has not been a noticeable burden.
Anyway, the rules are simple. In any dynamically allocated data, you store reftypes rather than pointers. When you actually need a pointer, you use the reftype to look it up. Any time you use a reftype to look up a pointer, you check to see whether the pointer is NULL. If it is, that datum no longer exists.
And, um, underneath it all.... the data manager classes use hash tables which are implemented in terms of arrays. Which are what GM uses.... and what annoys Brigand.
One man's drink is another man's poison?
What your saying may be true, but the conversation stops for me at "need to have many references to each other". As you say, as soon as you start placing pointers everywhere, you end up with memory leaks - you get circular references that don't get garbage collected but you cant reference, stale references that are pointing at some object that is now out of scope - the object continues to exist because "something" is pointing at it, or the most fun bug to track down, the null pointer reference (which is admittedly hard to debug in dynamically allocated system, so that it a point for doing it with arrays).
deallocating anything WITHOUT leaving references to it somewhere is very difficult and gets more difficult the more different kinds of things you have
I keep it simple - items/inventory instances point at/are pointed at by an actor or a SINGLE map manager (for items laying on the ground) and that's it - the destructor for the actor simply points the item objects back at the map manager (the items fall to the ground) which also makes it easy to determine what gets displayed. Actors are in an action queue, eliminating the need for a schedule, and that's it. The only cross pointers you get are actors targeting other actors. The first thing I do in the destructor is pass the 2 lists a single time, and set the pointers that refer to the dying object to null before the object goes out of scope - it takes literally 1 line of code in a do/while loop, and eliminates the need for a manager class as well as null pointer references.
Yes, I do have to peel off the objects when I save and then write them out manually, but that all occurs in one easily maintainable spot (and what other way would you do it anyways?). Each object has a unique id that sets the pointers back up when I load the game. Its an easy way to do it that I think the OP can grok as he is learning a language. (swizzling as you say)
Maybe I'm unrealistically biased, but I just like super encapsulation with a one-way pointer system; I definitely have produced spaghetti before, going overboard with pointers, but its something everyone does as they are learning. (I should add I usually avoid 2-way pointer structures for the very reasons you described; eg, doubly linked lists)
My entire argument is based on simplicity of coding; of course doing it the way you described produces in a more robust system that results in more stable memory use and eliminates null pointers/run time reference errors, but I don't think this is a beginner task. (After all, GML is supposed to be newbie friendly with its drag and drop IDE.) I don't even know if it's possible to do it this way in GML, but I could be mistaken.
Either way it goes, I think the real take away from all this conversation is that the OP quit reading this thread a long time ago (either scared off, or went elsewhere when told to do it themselves.)
-
double post removal
-
op:
Date Registered: September 14, 2014, 05:05:16 am
Last Active: September 14, 2014, 08:58:22 am
I think he long since fled. We may just be pissing in the wind.
-
The only cross pointers you get are actors targeting other actors. The first thing I do in the destructor is pass the 2 lists a single time, and set the pointers that refer to the dying object to null before the object goes out of scope - it takes literally 1 line of code in a do/while loop, and eliminates the need for a manager class as well as null pointer references.
I'm using a system where all 'actors' or game objects know which monsters are targetting them. When let's say an item is destroyed or picked up it's sending the message to all targetters that are in its list. That way monsters know something has happened. Maybe it's not a good idea to automagically remove the item from monster's target, rather change it to "last known location" or if the monster notices who picked up the item, then it's possibly going to attack the thief.
-
It's Interesting and odd to read the comments about GM and compare them to the framework I've evolved for my own use.
(...)
Interesting read. Yeah, it's great when a program can be nicely stratified, and all data stored in simple arrays and trees. The problem with games is that they just don't want to be nice and stratified. They are messy blobs of various interconnected things, and that is our task to put them together ;D
Yes, different entites need to know about each other and refer to each other in some way. For example, I have regions and units. There can be a number of units at the same region. On the one hand, I want to be able to access all the units from the given region. On the other hand, each unit may need to know its current region to find where are the possible exits to the neighboring regions. Such interconnectedness arises very often. And if you avoid it, the code may degrade to a gigantic god-class or a god-function. So, we really need to connect them somehow.
What I do, is almost identical to what you describe. The game entities that need to know about each other are labeled with an ID, a simple integer. The IDs of the units are generated uniquely, so there is no possible collision. The regions have the IDs defined at the map generation stage. The units and the regions simply know each others' IDs, this is enough to link them. The objects themselves are stored in corresponding data structure, in arrays, hash tables, or maps (an O(log n) access binary tree). With a few intermediate abstraction layers, the game data is quite manageable this way. I thought about generalizing this approach somehow with a generic module, but I'm not there yet.
Actually I do have several semi-god modules that combine different things together, but I was always able to refactor and break such semi-gods apart when they were becoming too unwieldy.
-
I think that the data manager is a design pattern; If you're doing complex crosslinked stuff with very diverse semantics, data managers make it easier to keep track.
OTOH, it's not clear that I'd need them if I were using Common Lisp for this project; CL's weak pointers provide most of what I want from them for memory management.
-
I have never really tried CL or Scheme, but macros and quotations are what I would really like to have in my language. Though, Lisp is kind of bad for distributing the game. There are probably more options for Scheme, for exmaple Chicken Scheme that compiles to C. I don't know about weak pointer in CL, can you save a data structure with weak pointers to file, and load it back without breaking the pointers?
Btw, such data manager is not only an alternative to pointers or references. What it does, it names game objects, so it provides additional benefits.
A somewhat artificial example. A unit has the list of previous targets: [monster1, moster2, monster3]. If the elements of the list are names, you can compare, whether they were the same moster or not by comparing their names. Monster's name can be passed to another function that gives some meta information about the monster that might not be available directly from the moster itself, for example it can return the set of monster's neighbors or something like that.
-
Yeah... I didn't want to use something that would require people to install libraries and runtime crap on their machines, (and, inevitably, require me to answer their questions about installation and help them) or spend my effort on maintaining compatibility with moving targets. Or figure out a least-common-denominator that works with runtimes and libraries that exist in many different versions on different machines.
And when you've done that, you're really left with just compiled languages and system libraries, and that compiled with options that get pedantic about a particular standard of that language.