Print

[Mamoruanime]

Mamoruanime

Re: Revamping ZFGC

a) Can't find the latest revision
b) Having a single file makes things confusing, only one person can work on the code at once, otherwise it ends up getting confusing when you have to merge code together
c) It sounds complicated
d) No centralised code direction / information on what needs to be done, eg. if I were to do such and such, how do you want me to go about it

<_< That's why I'm pretty much against GM for a large scale project. I mean sure you can have scripts and such, but it's so much easier to work on individual parts of a project when it's done in a language that supports OoP. If each part of a GM project were individual files, it'd probably be a lot easier to work with in large teams.

[Theforeshadower]

Theforeshadower

Re: Revamping ZFGC

I know I never worked on the MC Engine because well a few things:
I don't feel comfortable with scripts in GM(though I started getting used to them with UN Squadron).
I don't like the coding style used at all.  I just look at the code and to me look like one giant mess.

Sure if i slowly look over everything, I can understand it...even the scripts.  But when you have everything centralized in one GM file, it is hard to put your own touch on it.
Maybe Travis is right.  Moving to a language is the better route to take for a community project.  I still place my vote on C# as it is very similar to GML and XNA is quite easy as well.  If you want cross platform, there is java.  I haven't personally touched it but I hear it is quite easy as well.

Someone needs to maybe spark some developmental interest again in languages with a decent starting set of tutorials based on Zelda styled games.

Hmm, I am at my dad's place so my time using the net before I get back to college is limited to today and tomorrow.  I will look into maybe setting something up with XNA and C#.  I am no pro at it but I could probably toss something decent together.

MG-Zero should be my mentor

• 

[4Sword]

4Sword

Re: Revamping ZFGC

About the GM Minish Cap Engine, yes there are issues with it in terms of its management. When there are two people working on it and no one else is really seeking to help out, there hasn't been too much of a need for management beyond Niek and I just working to consolidate our styles. Additionally, I sometimes don't put comments in, we both get busy with life stuff, I have other duties on a forum where few others pitch in to help out, etc. There is a sense of responsibility with the project though, namely in that I don't rush to put something into the project at the sake of efficiency. I could throw a whole bunch of !@#$% together and there would be an engine with many features, but it would be !@#$% and people would have worse issues adding to it then. A lot of time is taken up trying to do things well that others have settled for being !@#$%.

Just because Game Maker has its quirks and moving to a new language might get rid of those issues of dealing with those quirks, there are still going to be new quirks. Beyond getting the engine's skeleton all sorted out, the game development guts all operate under similar logic. Issues like people rushing to hodgepodge features together without ensuring they work fully well together could still come up, there would be more hesitancy in using something other than Game Maker for users who wanted to help, etc.

On Windy's points specifically:
a) The latest version is a little tricky in that whenever the base needs to be refined, feature topics which are add-ons to that base also possibly need to be revised. Once there is a good enough base in terms of movement, then the issues with this shouldn't be so bad.
b) Game Maker 7 has the ability to merge games, whereas Game Maker 8 has importing/exporting of resources as a Pro feature. I have coded a lot in Game Maker 8 but should go back to doing stuff in Game Maker 7 since the merge games stuff would be helpful and Game Maker 7 code should run full-well in Game Maker 8. Feature topics would be able to be downloaded and merged into the base engines if the user wanted them.
c) I need to comment my code better, and switch from using move_x/absv_x/disp_a sort of naming conventions to stuff which is more readable. Oh and possibly have a different style of indenting as for some people that is bothersome.
d) It is true that Niek has done more weapons while I have focused more exclusively on movement. Once movement would be done it'd mostly break down into just doing features which happen to mostly be weapons. It's also difficult for those wanting to contribute when a base isn't fully out there as they don't want to start what has already been started.

If there are a group of users who want to do something in a fancy language though, organize yourselves and attempt to do what you are saying. Something like that can exist the same time as the GM Minish Cap Engine, as long as there was someone who knew what they were doing working on the project (there doesn't have to be a whole bunch of people, but at least someone dedicated to it).

But otherwise in terms of coding stuff, I really like coding Pokemon and some Mario physics stuff, so if I ever get time I will be putting more of my stuff out there for that.

[MG-Zero]

MG-Zero

Re: Revamping ZFGC

4sword, I haven't read your post yet, so I'll get to that in a bit.  As for Mammy's question..

1) A project manager is obviously a necessity.  I believe we have this right now for the GM Minish Cap Engine, but there's no one to take on that responsibility should the manager step down for whatever reason.

2) Delegating work.  Right now, we're kind of just saying, "Ok, here's the GM file.  Go do whatever you want with it."  This is really not a good way to go about this.  Specific things should be assigned to specific people.  Otherwise you'll have conflicts left and right.  People coming on board need to have work assigned to them and that needs to be recorded.

3) Source control (such as a git repository).  This resolves the one file issue.  There would be a release branch which contains the most up to date release which is not touched until a release is ready.  Coming off of there are the development branches, which define what the release will be.  This is where development occurs and when a development branch is finalized, it's merged into the release branch.  This way multiple people can work on the project without interfering with each other.  This is also where the work delegation would come into play.  This is best suited for a real language such as C# from my experiences.

4) Coding standards, there are none as far as I know in the GM project (I could be wrong, please feel free to correct me).  Standards meaning naming conventions for example.

5) Planning phases.  This one is REALLY important.  When developing a large scale project (such as the GM project), it's generally not a good idea to just jump right into coding.  It's best to plan what you will need, how these things are structured and how they will work.  I'm referring to UML diagrams and the SDLC in this.

An application process of some sort would be helpful as well.  Last, every bit of information about the team should be collected somewhere.

I'm sure I can come up with more, but I want to read over 4Sword's post first.

MG-Zero should be my mentor

!@#$%, LET'S DO THIS !@#$%.

i love big weenies and i cannot lie

[Theforeshadower]

Theforeshadower

Re: Revamping ZFGC

Hell Yeah!...It'll just have to uh wait until Spring Break is over.  However, I will throw some stuff together over the next few days.

• 

[4Sword]

4Sword

Re: Revamping ZFGC

The leadership of the GM Minish Cap Engine is really just a de facto position in that Niek and I have given about the same amount of effort to the project, where though that I have recognized his most current contributions as being more than mine and at the time was too busy with other stuff here and in life. If Niek ever got to busy or didn't want to do it anymore, then I would take over; additionally I could also develop my own base that I continued my development from different from Niek's so that we wouldn't have to worry over some of the nuances of our own styles so we could develop things independently more quickly.

As for development plans, I've always just started small and built up; i.e., the movement and collision system, and then refining that system in order to work with determining what Link is primarily hitting and so he could collide with tiles. The most recent thing I had been doing was to do all that but in a dungeon setting, with the plan to refine older dungeon elements I had posted as well as add new ones. Oh and yeah, as I said I could comment my code better. There are a few users here who have worked on Zelda engines which would be awesome if they would want to contribute to the project, but it always seems difficult for people to work together here.

As I also said, if you want to start up some C# project then by all means get some users together, a plan, and whatnot, and the forum can be set up in some way to accommodate your efforts. I was looking to merge the GM Minish Cap Engine into the Zelda Coding board and run the whole project inside of the the board, but I haven't seen how that would go yet - which is to say if you need a board set up that can be arranged.

[Xfixium]

Xfixium

Re: Revamping ZFGC

4sword, I haven't read your post yet, so I'll get to that in a bit.  As for Mammy's question..

1) A project manager is obviously a necessity.  I believe we have this right now for the GM Minish Cap Engine, but there's no one to take on that responsibility should the manager step down for whatever reason.

2) Delegating work.  Right now, we're kind of just saying, "Ok, here's the GM file.  Go do whatever you want with it."  This is really not a good way to go about this.  Specific things should be assigned to specific people.  Otherwise you'll have conflicts left and right.  People coming on board need to have work assigned to them and that needs to be recorded.

3) Source control (such as a git repository).  This resolves the one file issue.  There would be a release branch which contains the most up to date release which is not touched until a release is ready.  Coming off of there are the development branches, which define what the release will be.  This is where development occurs and when a development branch is finalized, it's merged into the release branch.  This way multiple people can work on the project without interfering with each other.  This is also where the work delegation would come into play.  This is best suited for a real language such as C# from my experiences.

4) Coding standards, there are none as far as I know in the GM project (I could be wrong, please feel free to correct me).  Standards meaning naming conventions for example.

5) Planning phases.  This one is REALLY important.  When developing a large scale project (such as the GM project), it's generally not a good idea to just jump right into coding.  It's best to plan what you will need, how these things are structured and how they will work.  I'm referring to UML diagrams and the SDLC in this.

Yeah I like all this. Did someone suggest a project? (Didn't read all the posts)

• 

[Xiphirx]

Xiphirx

Re: Revamping ZFGC

I'm quite sure everyone wants to restart the King of Thieves

For The Swarm (StarCraft II Zerg strategy)

I whip my hair back n forth

• 

[Kren]

Kren

Re: Revamping ZFGC

I would like to see king of thieves back, but with someone taking control on the choices and such, since we can't add all the ideas we get. I remember that was a main issue, we had like 10 or 20 stories, 10 or 20 dungeons, but nothing concrete on what should be done, If done again, I would like to work on it, but first I would like to see a team taking all the choices making it easier to tile and sprite later on, meaning everything as in dialogues enemies, bosses, story, dungeon, etc etc, number of houses on the city etc.....

[Zhello]

Zhello

Re: Revamping ZFGC

I'm quite sure everyone wants to restart the King of Thieves

if you guys gonna resurrect King of Thieves, Ill be happy to help,  I learn a lot of gml at zfgc. 

The IT Guy
Intermediate Coder
Linux is a wonderful thing
~Linkwolf48/Gumstone1080~

The Legend of Zelda - New Beginnings

http://zfgc.com/forum/index.php?topic=34986.0
1.6 Demo -
https://www.dropbox.com/s/56km0iadaras56g/LoZNB%20Game%20Folder.rar?dl=0


Side Projects:

Dragon Diary - Cybernetic Threat
Story: http://wiki.zfgc.com/Cybernetic_Threat

Aero88
ZFGC is like the Hotel California.  You can come in but you can never leave!

devianart: http://linkwolf48.deviantart.com/

[Zaeranos]

Zaeranos

Re: Revamping ZFGC

i know this reply is not going to be read, because it is long. Okay, I purposely held of on replying in this topic for quiet a while. The reason for this is that I am currently not in the right state of mind for it. I am rather cranky, due to the lack of good sleep. TO put a long story short, Since my tenth I have been having a great lack of sleep due to almost suffocating about 30 times an hour during my sleep. And thus not getting mental and physical restoration. I have been given a breathing device to help me sleep better, however in the "getting used to it" period it actually makes the problem worse. And this is the point I am currently in.

So I am reasonably cranky, but I have to get this of my chest anyway as the conversation has turned from revamping ZFGC to another Community Project. My apologies in advanced for being rude to people.

First of all I think it is a good and a bad idea to do an actual game as a community project. And considering that I joined up due to the King of Thieves project back then I would love to see it come back and be finished. I would definitely be involved in some manner if possible.

However I have to point out that KoT was swapped for LA MC because of disagreements of content story and whatsoever and people lost interest. Thus if we start it up again people will have to accept that not everything and maybe nothing will be as they desire it. Some people will have to step up and dedicate themselves as project leaders. Another bad thing is that we have to start mostly from scratch due to the lack of a base engine. And like with LA MC there needs to be a lot of coding and planning done before content like story, sprites, music and whatever can be considered. We can start with a general outline, but then it is a lot of waiting. Even before spriters can get going one would need to make concept art. And concept art still requires storyboards. On the coding you also want to get a language that every one can use and uses development tools that everyone can easily get to and working with. You want this to become a community project and not an elite developers project.



Okay now my response to the MCS Engine project that everyone in this topic seems to love to bash. My opinion that it is not doing so well as a CP is because of the lack of community involvement. Oh yes, you can respond to that by saying that it is not well managed and there is no clear design. And it is either scattered over many files or stuffed into one file. But that is all brought back to lack of community involvement.

First delegating and managing requires that the manager has a team of dedicated people that or also willing to be delegated and do the work. I have asked a number of people to cooperate, but they all thought they were either not good enough or they thought themselves to be to good to help. And those people rather work on their own projects in secret. The people that thought they were to good offered their help as "advisers", which roughly translates to: "Yes I love to have my name in the credits, but I can't be arsed to do the work.". Even then actual replying on stuff in the MCS Engine has also become very little, besides bitching about how bad it goes. Which once again shows a serious lack in involvement. I can list a number of people who I can delegate tasks to because they have the skills in programming, but the result is that wouldn't do it anyway. Mamoruanime, MG-Zero, Xfixium, Theforeshadower, Windy, Dark Hylian, Ryuza, FrozenFire, do I need to go on?

Second. Yes I know that to get a some good development, you need a good design and planning phase first. I have a Bachelor degree in Computer Science. I also know that in order to make a good design you also need to have a basic understanding of the target language. The first thing I did for the MCS Engine was also the first time I worked with GML. Before that I only did the drag and drop tutorials with Game Maker, nothing more. I absolutely had no basic knowledge whatsoever. I gained this by doing things and hoping on feedback. Now that I have I am going to work on a design. How does this relate to a lack of user involvement. Well there are a number of people with good knowledge in GML, better even then me. And those members could not be bothered to make a design either. They stuck up their noses because they moved on to another language. If they didn't we already would have had a design, which only required code-monkey work.

Now on that multiple and single files. In all seriousness, even with C#, C++, Java or any other language which has its source code in plain text you would have scattered stuff. As everyone will be working on their own copy. Even with source control you will get merge and compile conflicts. There are always one or a few people that will merge all the work in a stable/release candidate version. And GM has the ability to import stuff into other project files. The disadvantage with GM is that it is harder to use in version control, because the source code is stored binary and not in plain text. And for coding conventions, it is true that there are very little. But there are some conventions. The conventions aren't completed, because due to lack of involvement there never had been an discussion on what to use.

I don't feel comfortable with scripts in GM(though I started getting used to them with UN Squadron).
I don't like the coding style used at all.  I just look at the code and to me look like one giant mess.

Seriously. If that scares you already into not participating, then you will get a big problem when you are going to do software programming for work. Not everything will be perfectly documented and everyone has his own style.

d) No centralised code direction / information on what needs to be done, eg. if I were to do such and such, how do you want me to go about it

People have brains, don't they? Or are they just meager code monkeys waiting to be fed to get to work. It was a community project and every code is always appreciated. Not to mention look at the sticky topics.

Well, this is all I am going to say now, even if there still is some more left to say.

[MG-Zero]

MG-Zero

Re: Revamping ZFGC

First delegating and managing requires that the manager has a team of dedicated people that or also willing to be delegated and do the work. I have asked a number of people to cooperate

Have you thought that maybe there's not much interest in the current project?  I personally think that people would be more interested in developing a game than an engine, but that's just me.

I also know that in order to make a good design you also need to have a basic understanding of the target language.

Why?  The design is independent from the language.  A good design will be able to transition from language to language without a problem.  And you can tell me I'm wrong, but I've written plenty of designs and transitioned the code from one language to another without ANY problems.  Put it this way:  A flow chart is a flow chart.  A CRC card is a CRC card, a Use Case Scenario is a Use Case Scenario.  These aren't language specific!  Someone with a B.S. in Computer Science should know this  Again, this goes onto a lack of interest, and has nothing to do with programming language knowledge.

Even with source control you will get merge and compile conflicts.

Yes, and this is why you have a specific tree structure.  You restrict access to the master branch from specific users as well.  This way, they CAN'T screw up the release.  If this was truly a problem, Linus Torvalds would be a very VERY pissed off man as SO many people would have screwed up the Linux Kernel.

The conventions aren't completed, because due to lack of involvement there never had been an discussion on what to use.

Goes back to the design phase.  This is something that should be sorted out long before any coding is started.

EDIT: And I apologize if I come off as nasty in this.  Nothing personal, but yesterday was a loooong day.

i love big weenies and i cannot lie

[Zaeranos]

Zaeranos

Re: Revamping ZFGC

Have you thought that maybe there's not much interest in the current project?  I personally think that people would be more interested in developing a game than an engine, but that's just me.

I agree with you here. I am more interested in making a game also. Seriously, I want to work on a game instead of just an engine. However, something that I think is currently wrong with the development activity is that everyone gets bored with making the engine. It is something I have said in the staff section also when it came up. What ZFGC needs is a couple of engine's in several languages that both programmers and nonprogrammer can use to create a fangame. For people that want to get into some serious game development as well for hobbyists.

On ZFGC a lot of engines are being developed and abandoned. The problem is that the open source engines don't get further than walking with an additional feature. And the engines that do get further and have potential are closed source and no one can continue it when it is abandoned.

So I think that ZGFC does need some engines for people to work with, but we have to put in a joint effort to get these engines done. And work on engines one by one, ensuring that at least there will be finished engines, instead of having everyone work on their own engine at the same time, resulting in no finished engine.

At least it seems logical to me to do that.

Why?  The design is independent from the language.  A good design will be able to transition from language to language without a problem.  And you can tell me I'm wrong, but I've written plenty of designs and transitioned the code from one language to another without ANY problems.  Put it this way:  A flow chart is a flow chart.  A CRC card is a CRC card, a Use Case Scenario is a Use Case Scenario.  These aren't language specific!  Someone with a B.S. in Computer Science should know this  Again, this goes onto a lack of interest, and has nothing to do with programming language knowledge.

Yes, I know that a good design can be implemented in any language. However a design has several layers and each layer makes the design more detailed. At a certain point your design gets more aimed at the actual programming. The high global designs hardly have anything to do with a programming language. The more detailed the design the more you go to programming paradigms. And each language has its own form procedural and programming abstractions. The more detailed the design becomes, the more you need to consider these abstractions. At least that is what teachers have been drilling into me all those years.

A design made without some knowledge of programming in the target language can and probably will end up in ugly heck work.

[MG-Zero]

MG-Zero

Re: Revamping ZFGC

But the design is only there to serve as a skeleton/plan for the program.  It just shows the pure logic of the algorithms.  Again, I've written some really detailed designs, the event manager in Harvest being one of them and it was MORE than possible to port the EXACT same algorithm (from the same UML diagrams as well) and logic from C++ to C# for another project.  It's simply not meant to be implementation dependent.  Such a feature would limit it.  This is also evident when you consider the fact that once you know the algorithm for something, implementing it into a specific language is only a matter of being familiar with so said language.  For example, if you know the bubble sort algorithm, you can implement it into any language who's syntax you're familiar with.  That being said, I see no problem with users not being familiar with another language (not like we've even decided on a language anyway).  The only thing they need is knowledge of SOME programming to hammer out the logic for those who WILL be handling the code.

The high global designs hardly have anything to do with a programming language.

so...you're agreeing with me, then?

Regardless though, there's no reason we shouldn't implement a design phase into this project.

A design made without some knowledge of programming in the target language can and probably will end up in ugly heck work.

And jumping straight into code WILL end up in an un-manageable mess.

i love big weenies and i cannot lie

[Kren]

Kren

Re: Revamping ZFGC

I really want to make KoT to work, I was wondering who is willing to work on it? we can actually start it tho, and just design a team, leaders, and start accepting ideas and organizing a document. I mut admit that the coding part might be a little tricky but still I beleive we can pull it off.

[FrozenFire]

FrozenFire

Re: Revamping ZFGC

On ZFGC a lot of engines are being developed and abandoned. The problem is that the open source engines don't get further than walking with an additional feature. And the engines that do get further and have potential are closed source and no one can continue it when it is abandoned.

So I think that ZGFC does need some engines for people to work with, but we have to put in a joint effort to get these engines done. And work on engines one by one, ensuring that at least there will be finished engines, instead of having everyone work on their own engine at the same time, resulting in no finished engine.

At least it seems logical to me to do that.

I noticed my name mentioned up there in tiny text. Were you saying that if you asked me to help with the MC engine, I wouldn't help? Well, that's true, but hardly because I'm lazy and/or have no interest in it.

Actually, I totally agree with your thinking Niek. I'll tell you exactly why I've never helped out with the MC engine: First, I can't do everything at once, so even though I have some interest in helping out with the MC engine, I have more interest in making a Zelda platformer engine (technically it could be used for anything, like a Super Mario or Metroid for example). And I do plan on releasing the code in various tutorials and examples so that anyone may use the code to make their own platformer games without having to build their engine from the ground up (well, as much "ground up" as you get in game maker).
Second, in all honesty, I'm not a very efficient programmer. My code is rather messy and it takes me a long time to figure out how and if I can make the code more efficient. Also, the code in the MC engine is kinda hard for me to follow last I checked. I just find myself at a loss as to how I can add to something that I don't fully get. :/ You see, I understand my platform engine because I'm the only one coding it, even though my code can be a little messy, I can easily glance at it and get it because it's my unique coding style. Pretty much, I'm just saying, I'm not a professional programmer, I've been completely self-taught.
That said, I do plan on looking at the MC engine's code again to see if I can understand how things are working, and I'm trying to increase my skills at coding in more efficient ways (which I feel better at doing this learning in my coding of Spirit's Quest rather than in the MC engine). So, pretty much my platform engine is my priority and I don't want to divide my time between the two because it will slow progress and I have a life as well.

I think the MC engine, when completed, will be the turning point of ZFGC, as far as fan games go, that is. I've seen so many people get great ideas for Zelda games, but their idea just loses momentum as they get bogged down by the most boring and difficult part, making the engine; it dies pretty much before the actual game has even begun to take form.

Btw, I'm not sure if this question was ever answered or asked but, is the OoT2D project using the MC engine, or something completely different? It just seems to make sense that it would.

Well, when I get Spirit's Quest done and after I release the code in the form of tutorials and examples, I do plan to try to help out with the MC engine. That is, if it's still going and if I can figure out how it works.   Perhaps the comments just weren't helpful enough, or perhaps I just didn't give it enough time to gain an understanding of it.


WHY KOT ISN'T GOING TO WORK WITHOUT THE MC ENGINE:
Last thoughts, if we want KoT to work I think it would be a good idea to use the MC engine. The problem is that it means we need the engine BEFORE the game. Heck, the game is gonna need an engine sometime, and the sooner the better. So it just seems to me that the community project is either the MC engine first, or the MC engine AS WELL AS KoT, which is more work focused on at the same time. If we can't even get the MC engine done, how do we expect KoT to not fail again? Or is my logic flawed (could be, I'm rather tired atm)?
The thing I'm seeing as the issue is that nobody wants to make the engine, they just want to make the game, but you can't have your cake and eat it too... or whatever that saying is. Point is, you can't have your game without an engine. Unless the CP doesn't go by the normal 2D overhead Zelda style, it means: No MC engine, no success. All we can do is write some story, figure out the items Link will use and what actions he may have, do some art, etc. If I'm not mistaken, that's pretty much as far as KoT got before?

I guess that really means we could figure out what the MC engine needs by looking at whatever items Link will use and what actions Link will be able to do in KoT. As well as enemy ai, how the world is mapped out, etc. Though really, if I'm not mistaken, KoT should have mostly the same functionality as the MC, so really it comes down to new items and actions of Link. Right? So yeah, just my thoughts on the matter of a CP.

• 

[rivexco]

rivexco

Re: Revamping ZFGC

Hey did anyone notice a small spike after creating this topic?

Humans thrive on emotion. the more emotion put into ZFGC the more active it is.

[MG-Zero]

MG-Zero

Re: Revamping ZFGC

I'll be more than happy to work on it!

i love big weenies and i cannot lie

[Zaeranos]

Zaeranos

Re: Revamping ZFGC

Well, I started a design for an engine already in this topic: http://www.zfgc.com/forum/index.php?topic=38186.0 You are welcome to add and help with it. I am a really slow writer and prone to make mistakes or miss something at the moment.

@FrozenFire: The list in tiny letters was actually a number of members I would feel comfortable on asking something to program in GML, but each one has their own (valid) reasons for not participating. And on getting better with GML, it is better to just show your code like TFS does. Because you can get advice and pointers on everything and learn things a lot faster. It is the premise of the modern education system. There is a teacher that shows what can and needs to be learned and guiding and correcting them on mistakes. The education system is not have a child just look at the world and have him figure out for himself.

The high global designs hardly have anything to do with a programming language.

so...you're agreeing with me, then?

Regardless though, there's no reason we shouldn't implement a design phase into this project.

Yes and no. I understand that the first stages in a design are very global and focus more on what you need and want instead of how to do it. A domain analyses and requirements specification are the prime examples in here. But the more detailed the design becomes on how to do it, the more it leans on the target language(s). UML for example does have parts that can be used for any language such as Use Case Scenario's, but UML is optimized for Object Oriented languages. Thus a design made in UML can easily be ported to C++, C#, Java or any other object oriented language as the procedural and data abstraction is similar if not the same. in that manner a design is language independent. But porting it over to a language that is not Object Oriented, like Miranda, Prolog and others, you seriously need to reconsider the design as they have different procedural and data abstractions.

Because Mammy frequently hammered on the fact that GM is NOT Object Oriented. I was not that rushed to make a design in UML as it might need some serious reconsiderations in order to work with the language. Now that I have a better understanding of GML and the possibilities of GM I can say that it best resembles C in procedural and data abstractions. But due to the limitations and the setup of the IDE and language, along with an inheritance setup in the objects, it is possible to use UML and OOD for designing the engine.

Which I will also do now. I agree that it is still a bit of a mess, but this mess at least has been a learning experience and some people have had some use for it.

[MG-Zero]

MG-Zero

Re: Revamping ZFGC

GM can be considered object-oriented.  Not to the same degree obviously, but you have classes in a sense which can be instantiated. 

Anyhow, are we going to start this project up or not?  If so, we can start putting a team together.

i love big weenies and i cannot lie