ZFGC
Projects => Discussion => Topic started by: Theforeshadower on January 14, 2010, 10:06:57 pm
-
The purpose of this thread:
I've had an urge for a while to try to make a tactics styled rpg using Game Maker with the setting being the Legend of Zelda universe. Essentially, this thread will be like a developer's blog if you will. I'll post updates and such. I would those of you who are familiar with game programming and/or Game Maker to comment and maybe modify the code to improve the engine.
I am starting this completely from the ground up. No one else's engines, none of my engines... hell, I'm not even going to try to look at another engine. This is my "practice" if you will, and I would like the community's input.
Every update will be an attachment and in gmk format or as a docx document.
Checklist
~ Movement (Basic movement finished)
~ Collisions (Obstacles finished)
~ Stats System
~ Action System
~ Inventory System
~ Enemy Logic
ALL GRAPHICS ARE PURELY PLACEMENT.
Latest screenshot displaying the movement diamond:
(http://gamerspub.ismywebsite.com/latestscreenset.png)
Latest Release
http://www.zfgc.com/forum/index.php?action=dlattach;topic=35732.0;attach=7236
Latest Design Document
http://www.zfgc.com/forum/index.php?action=dlattach;topic=35732.0;attach=7244
UPDATE Jan. 22,2010
Sorry I have not updated in a while. I have some of the design document finished.
Be warned, I do not think I am the best at making a design document. I have highlighted the sections that I have finished. If you would like to comment or make a suggestion, please feel free to do so.
-
Okay, just to be on the same page. The movement you are going for is some kind of checkerboard movement, where you can go horizontal and vertical from tile to tile on a grid.
Then here are my comments:
1) Of what I can see, the variables moving and movable are mutual exclusive. Meaning when one is true the other is false. Unless you are planning on giving those variables more values than 1 (true) and 0 (false), you can suffice with just one variable. Because the two if-statements
if moving = 1
{ }
if movable = 1 && steps = 16
{}
can also be written as
if moving
{}
else{
if steps == 16 {}
}
this would make it that you only need to set one variable instead of 2.
2) Your use of consecutive if-statements without the use of else is inefficient. For example with the movedir make use of if-else if-else- statements. In your code for the worst case you need to evaluate 4 expressions and in the best case you also need to evaluate 4 expressions.
If you use if-else if-else statements then the worst case is still 4 expressions, but the best case is 1.
But as the expression steps > 0 is in all for of them and that entire block won't do anything without evaluating it to true, I would put it next to moving. This would also allow for the use of a switch-statement on movedir.
if(moving && steps){
//moving and there are steps to be made.
switch(movedir){
case 1: x += 2; break; //going right
case 2: y -= 2; break; //going up
case 3: x -= 2; break; //going left
default: y += 2; break; //going down
}
//decrease the steps that still need to be made.
steps -= 2;
}
3) the values you assign to the movedir variable would be nice if they are understandable. Make constants of them and then use UP, DOWN, LEFT, RIGHT or the GM's angular system of 0, 90, 180 and 270.
4) where you use keyboard_check_pressed, I would just use keyboard_check to check for holding the key. Or you keep bashing the right arrow when you move a couple of spaces to the right.
5) I have no clue whatsoever gameplay you try to make. So an explanation would be nice if you want any decent help.
PS: Now it is still small code, but it is good practice to comment code if you want others to take a look at it.
-
Answers to you numbers:
1: I think I was overthinking or trying to think ahead, that's why I had both of those variables there. You are correct though that just one would easily do.
EDIT: Damn, I remember now. You are correct, but, I had movable there for when that character is able to move. Like when the run starts.
2: Got me again. Bad habit of mine. It never really dove much into switches, though I always meant to do so. I does solve alot of inefficiency. Thanks for the recode. Insightful ^_^
3: That was my fault. I should have commented that I use 0 as the downward direction and go counter-clockwise from there.
4: I was debating at the time whether or not to have it check or check_pressed. Check would probably be the much better way of doing it.
5: Sorry, I thought it was understood what a tactics style game was. My fault(if I sounded rude with that sentence, I was not <3). Um, quickest explanation is something like Shining Force or Fire-Emblem(or Final Fantasy Tactics). Mostly for the Shining Force style(Google the rom of the second game for Game Gear if interested).
I know I should comment my code more. Bad habit of not commenting.
Thanks for the contribution thus far :)
-
I went ahead with Collisions anyway since it's pretty simple for the overworld objects.
I created a 16x16 object called obj_collisions. I had to set the bounding box on the
spr_player to 16x16 and switched off precise collision checking.
Works out perfectly. Could probably remove the if moving = 1 part.
COLLISION WITH obj_collisions
Code:
if moving = 1
{
moving = 0;
switch(movedir){
case 1: x -= 2; break; //going right
case 2: y += 2; break; //going up
case 3: x += 2; break; //going left
default: y -= 2; break; //going down
}
//set steps to 0 to reset movement
steps = 0;
}
-
Answers to you numbers:
5: Sorry, I thought it was understood what a tactics style game was. My fault(if I sounded rude with that sentence, I was not <3). Um, quickest explanation is something like Shining Force or Fire-Emblem(or Final Fantasy Tactics). Mostly for the Shining Force style(Google the rom of the second game for Game Gear if interested).
I watched youtube videos of the gameplay from the games you mentioned. And I saw some diverse stuff. With all of them the battle gameplay was like this:
- The field is made up of grid space like a chess board.
- A number of units (friendly and enemy) are spread over the field on the grid.
- Each unit can do an action (move/attack/magic/etc.) when it is its turn. No other unit will do an action while this unit still has its turn. Thus the state of the board does not change until the unit has completed its action.
- Action move allows the unit to go to another grid space X over path Y, unless there is a grid space Z that contains a blockade. Thus movement can only be done to grid space Z-1 on path Y.
On the Shining Force videos I also saw that free movement was possible in non-battle areas. Free movement like the ones found in a regular Zelda game.
I went ahead with Collisions anyway since it's pretty simple for the overworld objects.
I created a 16x16 object called obj_collisions. I had to set the bounding box on the
spr_player to 16x16 and switched off precise collision checking.
Works out perfectly. Could probably remove the if moving = 1 part.
COLLISION WITH obj_collisions
Code:
if moving = 1
{
moving = 0;
switch(movedir){
case 1: x -= 2; break; //going right
case 2: y += 2; break; //going up
case 3: x += 2; break; //going left
default: y -= 2; break; //going down
}
//set steps to 0 to reset movement
steps = 0;
}
Well, if you are implementing a free-movement system than collision checking would be needed. But when using a grid-action (movement/attack/etc.) system, than I wouldn't bother with collision events or a collision system. You need a grid-action-check system. This system looks whether the action you are about to do can be done.
I have added a simple and small example made on your old gmk file to show what I mean.
You know what! I think it is best you first make a design document of what you want to make. Design document explaining the flow of the gameplay, entities in the world and work out some technical systems.
-
Niek, I learn something new everyday. I did not know(being serious)that GM had that function "grid_move_check". Makes things alot simpler. Thanks, man.
I was actually planning on working out a design document when I get home after work tonight, so I should have it up late this evening with the basics.
Thanks again for your input, Niek.
-
Niek, I learn something new everyday. I did not know(being serious)that GM had that function "grid_move_check". Makes things alot simpler. Thanks, man.
Actually, it is not a function in GM, but a small script I wrote to validate if you can move to the coordinates x,y. The script is actually really simple. As the assumption is made that Link only moves one square: the script thus only contains place_meeting(x,y,parBlock). Which I now think about that it is wrong and you should use position_meeting(x+8,y+8,parBlock). You should check the center of a grid space, because bounding boxes of sprites might be bigger or smaller than the gridspace, but it does not instantly mean it is on other grids as well.
Ah well, it is something to think about. But my point is. The engine you are probably trying to make is turn-based with grid-based movement, like a chess game. Thus approach it like a chess game. Validate the legality of an action, before executing an action. And if the action is legal, than you don't want collisions of tiny pixels be in the way.
Validate instead off undo.
PS: GameMaker has some grid functions, which are mainly used for GMpaths, but maybe some useful functions are among them.
-
Yeah, the validating part is the next main step with movement. I'll explain in the design document.
I just started it but here's basically the sections it'll will have as of now:
Mechanics
1.1. Mechanics – What are the rules to the game, both implicit and explicit. This is the model of the universe that the game works under. Think of it as a simulation of a world, how do all the pieces interact? This actually can be a very large section.
1.1.1. Physics – How does the physical universe work?
1.1.2. Movement
1.1.2.1. General Movement
1.1.2.2. Other Movement
1.1.3. Objects
1.1.3.1. Picking Up Objects
1.1.4. Actions
1.1.4.1. Switches and Buttons
1.1.4.2. Picking Up
1.1.4.3. Talking
1.1.4.4. Reading
1.1.5. Combat – If there is combat or even conflict, how is this specifically modeled?
1.2. Screen Flow
1.2.1. Screen Flow Chart – A graphical description of how each screen is related to every other
1.2.2. Screen Descriptions – What is the purpose of each screen?
1.2.2.1. Main Menu Screen
1.2.2.2. Options Screen
1.2.2.3. Etc.
1.3. Game Options – What are the options and how do they affect game play and mechanics?
1.4. Replaying and Saving
-
Sorry for not having something better. Bad schedule for work the past couple of days(close,open,close,etc). Been tired, lol.
I attached the design of what the movement should be like.
-
Well, no one really opened the movement document, but I press on.
I used Niek's mod of my starting engine to "enhance" movement.
Probably will be change back to switch. Someone will probably know how to condense
the checking code for the Movement Diamond, but as of how much I tested, works perfect.
It is only DISPLAYING Movement Diamond right now. Next step is altering movement code to only allow the player to move within the diamond then resetting the diamond.
DAMN. There is a very small glitch but you guys wouldn't see it unless you changed the room layout. Fixing it now. BRB
EDIT: NVM, Half way finished just realized....BRB again
EDIT:OFMG, fixed it =P
Should be flawless now with displaying where the player can move.
-
Very nice so far; but (as I'm sure you're already in the process of doing) I would make sure you make the movement path detection a little more advanced. Your system right now allows for 3 spaces to be moved in any given direction, however it doesn't check beyond walls-
(http://www.zfgc.com/forum/index.php?action=dlattach;topic=35732.0;attach=7230;image)
Basically it should be checking if Link is able to move 3 slots to get to that particular position and if not it should find the next available path, as apposed just checking 3 blocks away to see if that's free.
Otherwise, it's gettin there, good work :P
-
I haven't read a damn thing you've done/said, but if the impression I'm getting from what Travis says is correct and you're using a 2D grid-movement system similar to the Fire Emblem/Nintendo Wars games, might I recommend Djikstra's Algorithm (http://en.wikipedia.org/wiki/Dijkstra%27s_algorithm)?
-
Or A* (http://en.wikipedia.org/wiki/A*)
-
Or A* (http://en.wikipedia.org/wiki/A*)
DJikstra's is faster, from experience. Also has a more interesting name. And was used in Fire Emblem/Nintendo Wars.
-
Perhaps :P Just throwin' alternatives out there for variety's sake
-
Looking into it though I never had much love for algorithms.
Working on the problem, though, as a look through of my code revealed some extra parameters were needed.
-
Here's the latest.
Basically, the problem that you found, Mammy, was there were 8 "if"s that needed some more " && "s or parameters if you will. Was a pain in the ass to find them and cost me a sheet of paper which I got into a fight with using a Sharpy.
Feel free to rearrange the room to try to find any more glitches like that.
-
Well, I took a quick browse and I have to say that there are some things in the code that need some work. But I was also wondering whether the player will be able to just control Link or a number of other characters also.
Because in the latter case I would suggest you use a controller object that handles player input and checks if it is possible. And make Link a puppet.
-
That is what I had planned once the movement and action systems were in place.
You would be able to control a maximum of 5 characters.
So a controller object seems necessary.
-
UPDATE
Sorry I have not updated in a while. I have some of the design document finished.
Be warned, I do not think I am the best at making a design document. I have highlighted the sections that I have finished. If you would like to comment or make a suggestion, please feel free to do so.
-
I just gave it a quick glance through. If I find the time I will give some better C+C, but for now I only have 2 things.
1) Advice: add flowcharts when you talk about the process of gameplay and choices in processes. They make everything a lot easier to read.
2) Question: I can't really get a good understanding of the overworld. Is it something like Golden Sun, Final Fantasy and Zelda II games, or is it more like the overworld in MC, ALttP, LA.
-
Sorry for not replying in a while.
The overworld would look and wrok like FF Tactics to just give someone something to work with if they want to use the engine.
In other updates:
I have not uploaded it as of yet.
Most of the movement has been removed from obj_player. What I did was, I put the movement code into scripts that can be called by any of the characters the player can control. It would help out any foreseeable speed issues since instead of calling the movement code in each step per each character, it only gets called if that character's turn is up. That and it makes life easier for use with a controller object.
The MOVEMENT DIAMOND itself is 100% complete from everything I tested vigorously. You can walk anywhere withing the diamond. For the moment, I am not placing a sprite in the originating location when the MOVEMENT DIAMOND is called. That's to let the player know that that was the starting spot.
I also added letting Z finish movement and X bring back up the MOVEMENT DIAMOND to give it a test on a larger environment( instead of 160 x 144, it is now 320 x 288) with moving views similar to older tactics styled games.
Other than that, still working on another release.
-
Or A* (http://en.wikipedia.org/wiki/A*)
DJikstra's is faster, from experience. Also has a more interesting name. And was used in Fire Emblem/Nintendo Wars.
[...] The only things that matter are how many nodes
there are and whether you have a good heuristic for distance /
direction to the target, however that is defined.
A* is good when there are a lot of nodes and you have a good heuristic.
If there is no good heuristic, A* has little benefit and Dijkstra at
least saves some overhead. And if there are only a small number of
nodes there seems little benefit in implermenting A*.
[...]
http://objectmix.com/java-games/131487-dijkstras-algorithm-vs-star.html
Relatively speaking Nintendo Wars was operating on quite small grids, probably why they went with Dijkstra's (also it's much simpler to implement).
EDIT: Holy hell this is my 3k post ^^