ZFGC
Resources => Coding => Topic started by: 4Sword on March 24, 2009, 01:28:45 am
-
To those who are able and to those who will be able to see the board shortly, this board itself may seem a little dead even with there being some life in it. I decided to let some of you see this board in the hopes that some stuff could get started.
Anyway, beyond that here are the top things we have to figure out:
- Having a system such that we can make updates to a Link object via updating GML script files
- Having some of Link's abilities that appear at the beginning of Link's Awakening ready to go
Also, if there is someone who you think I have included yet early who would be helpful to these early stages, feel free to mention someone. The current list of those brought on is:
- Scooternew: helped out with the previous community project, worked with MC graphics
- Xfixium: has worked with Game Maker and has attempted Link's Awakening
-
Wow, up sooner than I thought. Excited to get going here. I know Scooternew was involved with the last community project. So I'm guessing he has a basic framework in mind considering it was Minish Cap styled also. So I guess we should wait for his lead on this.
My general suggestions are to have discussion about certain game aspects. Like global variables that will be save and loaded. Desired game resolution. That sort of thing. Again, I'm new to this whole team idea, so if I step on toes and such, or I'm just plain out of line, don't be afraid to let me know. I'm not all that hard to get along with or reason with.
I'm not totally sure how it worked in the previous project, but I'm working on a room editor that allows for the editor's room to be exported to a GM project. This might be helpful for people working on this project. As they could submit their room files to the team to add to the main project.
-
Yeah, one of the reasons that I brought you in to help with the beginning stages is that you thought outside the box on stuff. In the previous crack at Link's Awakening you had, the way in which you had some of the level loading seemed to be pretty good in terms of resource management.
Beyond what I already mentioned though, there is something that needs to be worked out in terms of reducing stored image size - something to tackle would be redundant images. For example, Link walking down without a cap, Link walking down with a cap, Link without a cap holding something and walking down, and Link with a cap holding something and walking down. All of these have the same legs. Having the animations sawed in half so to speak for images such as this wouldn't be that difficult I'd think.
About the desired game resolution, it would likely be either 240 x 160 or 480 x 320 in a window, and probably 480 x 320 full-screen as well.
Specifically in regard to global variables, do you feel that it is better for many of Link's variables to be global, or in general any game's main player, because the game practically revolves around that character?
-
Well, we could use the GBA resolution. I had tried that awhile back when I was looking for a good resolution to match the original. The only problem I had is trying to get the "widescreen" resolution to have the same feel visually as the original. I found myself with alot of filler width-wise. Your thoughts on that?
Basically, with the globals, my suggestion is to store what we absolutely need to have written and read. Stuff that is specific to Link like his facing, state, speed and such should stay as member variables. Basically anything to do with his animations and movement behaviors. Does this sound reasonable?
-
The engine for this project is attempting to mirror the Minish Cap, while the game part uses the engine and tries to best work with it to fit Link's Awakening. There have been some maps for at least the Oracle games which seemed to be alright graphically updated for Minish Cap. What I think about when the screen size is reduced is that the buildings and trees and stuff in the Minish Cap will look cramped in a smaller size.
As for global variables, that would be alright - in a lot of cases, just referring to objLink.facing is just as easy to do as global.facing in an enemy or object's code - might even be more appropriate to work with locals. You are right though, the essentials that would be global variables would likely be the stuff that needs to persist when those having them go poof. If the room management thing I mentioned before of yours did not involve multiple rooms in a Game Maker context of rooms, you may not have needed it.
-
Well, the code is very old. I started it in the middle of 07. I worked on it for several months. All I know looking back on it, is that it could have been done better. lol I basically had one gigantic overworld map sectored out in a grid of 16 X 16 rooms. I loaded objects and collision masks on the fly when transitioning to a new sector. Was this the best way to handle it? I haven't a clue. While I thought that was a creative solution, it introduced different problems.
I'm also sorry if my terminology is a bit weird for GM. I say member variables because it reminds me of public c styled member variables. As in a declared variable within the creation event can be seen by other objects. I usually use the term "local variables" for temporary variables that are only within the scope of a script. Just so people do not get confused on what I am saying.
-
My terminology is a bit off as well because I am taking a C++ and Unix class right now which is going over shell scripting. Anyway, would you recommend that anyone else be brought in early to help with this from the list of those who applied in the News/Updates board? So far it is just me, you, and Scooternew.
-
I COULD help but I am not sure. I mean I only used GM5.3a for 4 years and we are probably using GM7.0...
Concept programmer? XD
-
I think the recruiting should be left to people other myself. :) Not too familiar with the people that want to help so far.
-
I will help whenever needed and do more of the complicated GM programming if anyone needs help with this, but I'm going to be taking a backseat for the most part (mainly because I have little spare time lately, and also because I disagree with the direction the CP has headed).
-
I'll help with programming as well.
-
Well, I think we've got everybody. Or close to it. What's the next step? Specifically, how are we organizing this?
-
As I was mentioning in the topic in News/Updates, this stage of the engine is mainly to get the initial setup of the engine ready. All the engine does is emulate to the best of its abilities what goes on in the Minish Cap in terms of Link, NPCs, enemies, rooms, etc.
There are only two key ways Link's Awakening plays a role in the engine's progress overall. The first being that since the Community Project's game is Link's Awakening, the engine should try and prepare for what is going to happen in that game as it is being remade. This keeps the engine development focused as there is some priority as to what to do and makes sure that the stagnation levels on the Community Project's game in relation to its programming are reduced.
I first think that we should start on getting a Link object which has its primary events run as script files. This goes back to something I said earlier in which we could just update the GML scripts prior to public releases of the overall GM file so we would not be updating the project amongst ourselves by having to save and upload an entire big file each and every time. If we use GML script files, this allows us to also use things like Assembla to manage different versions of the source code.
So, here is where we will start in terms of coding stuff:
- Programming a workable Link object that utilizes scripts in its main events
- making sure that there isn't unnecessary redundancy in animations (e.g. hat/no-hat/run/hold)
- the main events are pretty much in terms of gba are a, b, l, r, start, and select and create/step/draw/animation end
- we'll probably be using keyboard keys a, s, z, x, enter and backspace
- at least getting some of the beginning Link's Awakening Link actions into the engine.
The organization once it goes public is going to be such that a group of coders who know what they are doing - probably all you guys - are going to handle the stable releases. People will be able to contribute to the engine and since it is open source they may submit their own, but as for it being added to what is the official release, what they submit will have to be screened to see if the code is good and if it will work with the project.
As for what people contribute (assuming the code is good), if it is an object like an enemy, there will be a separate GML file set up with just that enemies stuff in it (the code, sprites, etc). The user will also be required to make sure to mention what other GML files are needed for the file to work with the latest stable release. Other users will have the option of downloading that user-made enemy and merging into their version of the stable release. This will hopefully foster some creativity in those making things - it's not hard to do a little or to make a little contribution.
Of course though, in the Community Project's engine, there will be parent objects so that the enemies, NPCs, etc. that users create will have to work with the variable names of the parent objects. This further keeps their code in line with ours.
-
Okay, got some things going here. I'm going to use this test project as a discussion piece so that I may have a clear idea how the more experienced people want the work to flow. I have a project attached with some basics thrown together.
What it contains.
Basic movement (Goodnight's movement engine used)
Link can blink randomly
Toggle screen size with the "Q" button for now
Some things I should note, I have several coding conventions I use:
For constants:
Constants are all capitalized: eg. CONSTANT
For Member variables:
Member variables start with capitals for each word: eg. MemberVariable
I also use the "self." keyword when referencing a member variable. This makes the code more easy to read.
For Local variables:
Local variables always start lower cased. eg. localVariable.
I also declare every local at the top by prefixing "var" keyword at the top of the script.
For Globals:
Same a member variables: eg. global.GlobalVariable
The seperate themselves with the "global." keyword. I also declared each global on it's own line to comment what they represent.
For resources:
All lower case with underscores for separation. Also prefixed with a resource acronym:
eg. scr_set_something (A script resource) .
Whether or not these conventions are acceptable can be discussed. We should come up with a uniform way to code amongst one another, whatever it may be.
-
Look, I know not everyone is enthusiastic about this project, but a little feedback would be nice. XD Maybe my post update got wiped when this board got moved. *shrugs*
-
I am sorry, I have been busy with college classes and trying to help my friend Zahnle get his C++ homework to work (odd in that it compiles fine in Dev-C++ but Unix is giving it errors). I will look at this over the course of the day and weekend.
-
Understandable, you take your time. I will continue to get some more things done.
-
An updated version, with dialog box functionality. I've tried to make it pretty generic. It all happens with a call to scr_create_dialog which accepts; a background resource, x, y, width, height and text string. It also supports some simple tags.
Color tags:
[col=aqua]
[col=black]
[col=blue]
[col=dkgray]
[col=fuchsia]
[col=gray]
[col=green]
[col=lime]
[col=ltgray]
[col=maroon]
[col=navy]
[col=olive]
[col=orange]
[col=purple]
[col=red]
[col=silver]
[col=teal]
[col=yellow]
Special MC specific color tags:
[col=item]
[col=place]
[col=event]
[col=name]
Close color tag:
[/col]
New line tag:
[b]
LA specific image tags:
[img=yoshi]
[img=ribbon]
[img=dogfood]
[img=bananas]
[img=stick]
[img=honeycomb]
[img=pineapple]
[img=hibiscus]
[img=letter]
[img=broom]
[img=fishhook]
[img=necklace]
[img=scale]
[img=lens]
Quite honestly this could probably be made even more customizable. That would be going above and beyond. It may be unnecessary. Of course that's up for debate.
EDIT: The continue prompt is not done yet. Also you can draw the text fast with the "X" button.
-
About shadows, in the actual Minish Cap game, do Link/enemy shadows blend against the environment or do they stay a solid color?
As for some of this coding though, I am having a minor issue in that some of it is GM 7 Pro, so I cannot fully observe it (although I am able to understand the data structures part since I work with them in my C++ class currently). I know that there is also a way in which to have a text engine that can be run effectively in GM 7 Lite too but if Pro has a better system then it might be good to go with it. A thing to consider is the difference between those who have GM7 registered or not.
-
They are a solid color. However, the color changes depending on the pallet it seems. This is seen when Link enters different areas of the game. I mimic this behavior by having a base white shadow sprite, and have a global shadow color that can be changed anywhere in the game. It's probably best to change this when the room changes. The color is used to blend with the shadow sprites in the game. That way it's one sprite, that can be blended to any color the global shadow color is.
Hmmm, I see your point. If we wish to reach everyone with it, it'd have to be lite. That makes me a sad panda. Unfortunately it will be a more convoluted route to use the Lite version. Data structures unfortunately make things faster in GM. The whole color blending with the shadow sprites would be dashed. I also used scaling and a surface for the dialog box. I used scaling on Link also. Well, whatever is decided. If we must make it Lite, so be it. It just won't be as efficient.
-
I decided to at least upload a .exe of what I was working on. Nice avy 4sword btw.
-
Still, I don't think you should compromise what's already there just so people with GM lite can use it. I know it brings it to more people, but it works well atm.
As for the shadow, we are trying to make it MC style, right? Just draw the shadow with some alpha and blend it black or something, that'd work.
-
Yeah, I agree, I'd rather use the pro version. As for the shadows. The way I'm doing it right now is the closest to MC style. Hell, I'd gladly do what you said. Make it black and alpha blend, because it's what I did with my original LA engine. However, that would not be MC style.
I have an example of what I described earlier. But you don't have to take my word for it, pull your emu out and play for a bit.
-
Sorry, I have gotten really busy. I have Linear Algebra homework due Monday, a Stats test next week on Tuesday, and programming assignment due Wednesday, Unix homework due by that week Thursday possibly, and other things as well - figuring out if I am still in the Honor's program technically and then if I am making one of my programming classes an honor's one next semester.
Anyway, with the shadows, they will be a solid color due to how it is done in the Minish Cap. Not only is it authentic, but in terms of Game Maker, it would be easier to implement. Anyway, I was tinkering around and trying to get the concept worked out for how sprites/animations could be reused by dividing up certain animations based on common elements.
In Link without the hat and Link with the hat standing, there is a pixel difference in the hair line which if not there would make some of the divisions easier - that is not to say that the change should be made to correct this. The concept of dividing certain animations up still works, I am just also trying to get it efficient - a problem encountered is that Game Maker does transparency by the lower-left pixel, which is pain in the ass if you take it for granted.
Currently I am trying to finish up the standing and walking with this concept (taking into account how holding works into the animation divisions), Xfixium's blinking, and working in either a "states" or multiple Link object way of handling actions. Chances are we are going to build off of Goodnight's walking engine as well - a while ago I made some tweaks to it which I think handle sprite correction better as well.
-
Sounds great, can't wait to get some direction here so we can progress. I worked on debugging the dialog scripts in my test project. I found that putting 2 tags in a row made some new problems so I fixed that. I also made it more encapsulated, and customizable. I like the suggestions you made, and it will be fun to implement them.
-
Just inserting my opinion here.. but how far ingrained is the code that requries the pro version?
Would it be possible write all the pro code in a way where it can be easily disabled if necessary (like using an contant), so those using the lite version can still code, if its all graphical effects and stuff, I presume that most people coding could forgo those sorts of things.
-
Well, with the source I wrote, here are the Pro functions used:
The dialog object uses surface functions for all the drawing.
The script scr_clear_surface uses surface code.
Use of draw_background_ext in dialog code for when the dialog background is scaled.
Use of data structures for globals, like an item list.
The use of draw_sprite_ext for the shadow color blending.
Use of data structures for dialog default images.
I'm sure this can be re-worked for a lite version. The dialog script will suffer the most. The data structures can be replaced with arrays with some speed sacrificed.
-
Personally I think that the Lite version should be what is primarily developed for. We could have it though so people could download different "implementations" for the Lite/Pro versions of certain things; this assumes that a call to a function to draw something like a text box could be written with the same number of arguments and produce a same result (albeit some of the resources might be different and possibly other scripts needed).
I am a little unsure of how the data structures work but meh; a lot of it seems to be with things relating to text. The shadow blending can be handled by a multiple image shadow sprite with Link's drawing of the shadow draw differently the sub-image depending on a variable.
Also, I was working on the movement code and trying to make it similar. I found that because Game Maker treats key statuses as boolean and numerical value, you can do logic and operational properties better. Looking at Goodnight's code, he takes advantage of this in some places, but not in all. Here is the current code I was working on (for Link's step event):
var hold_u, hold_d, hold_l, hold_r, move_count, move_step;
hold_u = keyboard_check(vk_up);
hold_d = keyboard_check(vk_down);
hold_l = keyboard_check(vk_left);
hold_r = keyboard_check(vk_right);
if (hold_u == 1 && hold_d == 1){
hold_u = 0; hold_d = 0;
}
if (hold_l == 1 && hold_r == 1){
hold_l = 0; hold_r = 0;
}
switch (hold_u + hold_d + hold_l + hold_r){
case 2: move_step = sqrt(2); break;
case 1: move_step = 1; break;
case 0: move_step = 0; break;
}
move_count = move_speed;
if (move_step != 0){
while (move_count >= 1){
if (place_free(x + hold_r - hold_l,y)){
x += hold_r - hold_l;
}
else if (hold_u + hold_d == 0){
}
if (place_free(x,y + hold_d - hold_u)){
y += hold_d - hold_u;
}
else if (hold_l + hold_r == 0){
}
move_count -= move_step;
}
}
A key to the concept I mentioned above only works with prioritized movement effectively. Because pressing up and down cancels them out, the only possible values that pressing all directional keys can attain is either 0, 1, or 2.
What the code needs to finish though is the corner cutting. I do not think that you need a for-loop for it per-say. I am still trying to figure out that - it comes down to if you bounding boxes aren't overlapping but will be if you move then you stop (if you run smack into it), if your bounding boxes do overlap and you move then it will determine your position in relation to the colliding objects bounding box and yours (you hit it off-smack).
If you are going down, for example, if you hit it perfectly you run in place. If you hit it off-perfectly, the code checks to see if you are pressing left or right (if you are on the left of the colliding object, pressing left will make you still go correctly, but if you go right you stop - just like in the Minish Cap). If you are just pressing down though and you are off-perfectly, the code adjusts your move_step value and should just move you in a left or right direction by one each step.
-
Anyone have luck with getting my movement code to include corner cutting? If so, it would save a lot of code complexity compared to Goodnight's version (at least I would think so, even the direction checking corrections could possibly be reduced).
I will be able to work more on this Wednesday night, unless I decide to go to a Shakespeare Twelfth Night show in Chicago - I probably won't because I will be pulling an all-nighter for tomorrow's homework that I have due.
-
Anyway, I worked on the movement code a bit and like I thought I was able to reduce the code's overall length and if I am thinking about it right, it's code complexity and possibly it's big O notation (w00t). Here is some new code (still needs the corner-cutting, I know how to implement it, but it is not fully ready done):
var hold_u, hold_d, hold_l, hold_r, move_count, move_step;
hold_u = keyboard_check(vk_up);
hold_d = keyboard_check(vk_down);
hold_l = keyboard_check(vk_left);
hold_r = keyboard_check(vk_right);
if (hold_u && hold_d){
hold_u = 0; hold_d = 0;
}
if (hold_l && hold_r){
hold_l = 0; hold_r = 0;
}
switch (hold_u + hold_d + hold_l + hold_r){
case 2:
move_step = sqrt(2); is_moving = true;
switch (facing){
case "U":
if (hold_d)
facing = "D";
break;
case "D":
if (hold_u)
facing = "U";
break;
case "L":
if (hold_r)
facing = "R";
break;
case "R":
if (hold_l)
facing = "L";
break;
}
break;
case 1:
move_step = 1; is_moving = true;
if (hold_u)
facing = "U";
else if (hold_d)
facing = "D";
else if (hold_l)
facing = "L";
else if (hold_r)
facing = "R";
break;
case 0:
move_step = 0; is_moving = false;
break;
}
move_count = move_speed;
if (move_step != 0){
while (move_count >= 1){
if (place_free(x + hold_r - hold_l,y))
x += hold_r - hold_l;
else if (hold_u + hold_d == 0){
}
if (place_free(x,y + hold_d - hold_u))
y += hold_d - hold_u;
else if (hold_l + hold_r == 0){
}
move_count -= move_step;
}
}
About the corner cutting though:
1) It checks to happen if your next place is blocked by something
2) If, for example, you are going up and pressing left or right and the left place is not blocked, moving right makes you collide with a diagonal orthogonal to your motion, moving left does the corner cutting for you).
3) If with the previous example you were not pressing left or right, if your bounding box was not overlapped already with the collision objects, you wouldn't do anything (you are hitting a flat surface head on), but if it was overlapped, you would then do the corner cutting (you are hitting something off-center which is what corner cutting corrects)
I think that that logic explains the crux of the code.
-
The code seems to work perfectly. However, I am having trouble with the move speed. Originally, I calculated 1.5 as the move speed for Link at 60 fps. However the script seems to ignore fractions. There is a big difference between 1 and 2 on the move_speed variable. Both not close to the MC engine. Either too slow or too fast. I tested the script on 30 fps, and there seems to be more control over this, but with animation choppiness.
Link does have the correct feel when he collides with a solid, more so than the old code. It just needs some tweaking.
-
I like the way you think in your algorithms 4sword. It's intriguing to me :P
-
keep it at 60 fps, I can't stand how choppy 30 is >_>
-
I had the move_speed set at 3, the image_speed at 0.5, and the game speed set at 30 frames per second. I wasn't sure if running 60 frames per second would be work well on many machines at consistent levels.
Anyway, I looked into it and the error with fractions is an error on my part. In Goodnight's original version, the movement was move of a "continuous" process while mine was based on "potential" based on move_speed. Essentially, I think, all mine was doing at a speed of 3 diagonally was moving 2 lol. The likelihood is that I was doing it wrong. I have corrected it in my code but I am looking into how and if changing movement from non-diagonal to diagonal causes problems because of the decimal poop - if the decimal poop is negative, I am looking into how that affects the number of times the loop iterates.
I like the way you think in your algorithms 4sword. It's intriguing to me :P
Meh, the only thing neat about my algorithm was how diagonal/non-diagonal/and no movement could be related through knowing that all the keys added up when prioritized could only be 0, 1, or 2. It just shortened the code and allowed some things to be combined when now possible - which also reduced the conditions when the events would be checked or that the same condition wouldn't be checked twice.
-
lol, nice. Great to see that you have an eye for things. 3 works just fine as Link's movement speed at 30fps. Which makes sense when you bring it up to 60. 1.5 being half that amount. I wonder if we can make the move speed and image speeds relative to the fps? Perhaps then we can give an option on the fps of the game.
-
lol, nice. Great to see that you have an eye for things. 3 works just fine as Link's movement speed at 30fps. Which makes sense when you bring it up to 60. 1.5 being half that amount. I wonder if we can make the move speed and image speeds relative to the fps? Perhaps then we can give an option on the fps of the game.
easy, just add the room speed to all the equations. Don't know how that would affect performance though. and if collisions aren't programmed correctly they'd mess up too.
-
I wonder if we can make the move speed and image speeds relative to the fps?
Maybe I should have put "should" in there instead of "can". :)
-
That shouldn't be too difficult. Just have some script that changes the speeds on the room start based on what the selected fps is. I haven't gotten a chance to look at the code yet, I'm getting on that now, though.
-
I have been a little busy, but here is the concept for sprites reducing redundancy (pressing "A" changes to wearing or not wearing the hat). I didn't have time to put in the sprites for left and right though. Also, you are prompted at the start of the level to set the movement speed; the actual setup of this can be altered and made more professional though.
Here is some number crunching I did with the diagonal, non-diagonal loopage, to figure out what could go wrong. There is an error I figured out, but it is minute. You see, if your move_count is negative from the result of moving diagonally and then you immediately switch to moving non-diagonally, there is a little bit of delay.
You see, if the loop which figures out the movement is positive and not above 4, it runs three times for non-diagonal movement (e.g. 3.5 2.5 1.5). If the move_count starts out negative before you add three too it before the loop you could get something like this (2.5 1.5). That indicates that there is a little delay (it corrects itself after the delay - the next loop is 3.5 2.5 1.5 which is normal, but just saying for that one movement you are delayed).
Anyway, here is some of my unfinished code (the movement is almost done. That error in the above paragraph could likely be fixed by a condition check in the hold_u + hold_d + hold_l + hold_r switch statement - the check being to see if you are moving non-diagonally and doing some kind of alteration to the movecount, such as adding a number to it or absolute valuing it (adding a number is better though and more practical - avoids a function call and the numbers we are overcoming are decimals - aka one is enough and not to much to fix it).
Without further ado, the code is in the attachment. It works in Game Maker 7 Unregistered.
-
Just to restate my position on pro here, I'm not suggesting that pro code be rewritten or anything like that. I'm just suggesting that for development purposes that pro code be encapsulated within a constant that can be turned off by those developing using the lite version of game maker in order to avoid getting any pro warnings that would disrupt development and for the bits and pieces that require logic that you have a basic alternative that can be implemented in order for those that have the lite version can use that code, for example for dialog you could probably get away with using popup dialog boxes, as long as the logical flow is the same, because when developing, what it looks like is unimportant.
-
I am not sure exactly what you are saying and that is probably my fault. I can't remember how Game Maker fully handles this, but can you run a game maker file if there is code in a GML function that is for the registered version when you have the unregistered version (even if the registered version stuff is not called anywhere in the game)?
Also, I think I fixed the code. The idea came to me early this morning when I was working on my Unix assignment. Looks like this:
var hold_u, hold_d, hold_l, hold_r, move_factor;
hold_u = keyboard_check(vk_up);
hold_d = keyboard_check(vk_down);
hold_l = keyboard_check(vk_left);
hold_r = keyboard_check(vk_right);
if (hold_u && hold_d){
hold_u = 0; hold_d = 0;
}
if (hold_l && hold_r){
hold_l = 0; hold_r = 0;
}
switch (hold_u + hold_d + hold_l + hold_r){
case 2:
move_factor = sqrt(2); is_moving = true;
switch (facing){
case "U":
if (hold_d)
facing = "D";
break;
case "D":
if (hold_u)
facing = "U";
break;
case "L":
if (hold_r)
facing = "R";
break;
case "R":
if (hold_l)
facing = "L";
break;
}
break;
case 1:
move_factor = 1; move_count = 0; is_moving = true;
if (hold_u)
facing = "U";
else if (hold_d)
facing = "D";
else if (hold_l)
facing = "L";
else if (hold_r)
facing = "R";
break;
case 0:
move_factor = 0; move_count = 0; is_moving = false;
break;
}
if (move_factor != 0){
move_count += move_speed;
while (move_count >= 1){
if (place_free(x + hold_r - hold_l, y))
x += hold_r - hold_l;
else if (hold_u + hold_d == 0){
}
if (place_free(x, y + hold_d - hold_u))
y += hold_d - hold_u;
else if (hold_l + hold_r == 0){
}
move_count -= move_factor;
}
}
I think that this should work. My early error in the movement code was that I had the diagonal movement based on potential ability to move, this works similarly except that it realizes that when you move non-diagonally, that potential does exist as you can only and should only move three times each step potentially if the move_speed is 3.
I am not fully sure how this will work with the corner cutting in that corner cutting happens when you are hitting something skewed, the corner cutting only really happens when you are only applying the keys to move non-diagonally. This is to say I am am not certain right now if the setting the move_count to 0 in the one switch statement will affect the speed of the corner cutting. It could be a little faster than true diagonal movement which when you think about it is kind of accurate in that you are not really moving purely diagonally.
-
I am not sure exactly what you are saying and that is probably my fault. I can't remember how Game Maker fully handles this, but can you run a game maker file if there is code in a GML function that is for the registered version when you have the unregistered version (even if the registered version stuff is not called anywhere in the game)?
Exactly, unless the registered functions are actually called, game maker will not throw up an error message.
Hence you could have something like,
if(PRO_VERSION)
{
// perform your data structure stuff here for us pro people
}
else
{
// or use an array based solution for us lite people
}
sort of thing.
-
Meh, I was too busy to get that worked into it and too lazy to test it, but here is what I got done so far. It includes left and right movement images, the corrected diagonal to non-diagonal delay, and redoing the facing variable such that the built-in direction variable is used instead. Still needs the corner cutting. I put a rock in the file because I was going to use that for testing the corner cutting and picking the object up and throwing it, but I haven't gotten around to it. Anywhere, it's attached.
I think that the first stable release of the engine should have two enemies, an NPC who can be talked to and can move, and at least two Link objects which define their abilities based on how they can move (Link's actions can all be categorized based on the ability to change direction or not). This relies on a parent object system - includes using items likes a sword and shield (I have the shield and sword ripped just not fully usable).
The movement code again might also need to be changed such that movement in general is just movement and not directional changing; the good thing is that my movement code allows this easily - albeit necessary redundancy as non-directional changing doesn't use the code and directional changing has the same check twice. Then again, there might be an easier way to do this; it's easy to do though because the switch statement that checks the added value of the key presses does the directional checking.
This might mean the movement code will be rewritten a bit. Looking forward the actions of dashing with the sword and moving while on fire should be figured out too as those wouldn't work fully under the current movement system. Furthermore, an additional movement system for "bump back" will need to be devised for when Link is hit or when an enemy is hit.
As for working in the GM Lite/Pro thing, that could be implemented in the draw event primarily.
But yeah, attachment (the fps is 30 just because I got tired of setting it when it ran all the time):
-
I think we should split the engine up in stages and not just keep it in one topic.
Example:
Topics:
-Getting started (Organizes the team)
-Basic Movement (Gets the movement down)
Then for every step, we add another topic. That way it is much more organized and less macro oriented.
-
Meh, I guess that sounds better in terms of organization. I cannot really work a lot more on the engine until my semester is over for my school though which is about two weeks away.
-
Is there anyway I could help out too? I worked on my game alone it gets boring so Ill work with you guys :)
-
To be perfectly honest, a lot of what you do seems to just be asking for engines or taking the engines of others for your own use. A lot of the challenges of the GM Minish Cap Engine involve creating engine features which haven't been done so well or at all before and making them work together as one solid unit.
And really, the Community Project's source code is open to all users of ZFGC to use in their games; SO LONG AS CREDIT IS GIVEN TO ZFGC OF COURSE (Even if you are a user here, credit must be given for its use). The goal of the Community Project is to create something useful for users here, and in that same spirit user contributions should also be helpful and well-done. Otherwise, providing feedback to those working on it about the features they have implemented is also welcome so long as any criticism is constructive.