This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

1421

Other Projects / Re: [Demo] Alttp-style game / tech demo -- No name yet

« on: August 08, 2009, 06:09:28 pm »

I'm going on vacation soon so here's the latest demo to round of the last weeks of work. Some things are still under construction but then again .. they always are. I'll list the changes since the last demo since most aren't visual. Only for those interested.

Ooh and before I forget. The shading I already showed a screenshot of is not in the demo. It needs some more work (= glitch hunting and altered placement). The anti-fairy at the beginning is also gone. Instead the flying tiles have made a comeback. I improved the collisions between the tiles and solids but I also need to redo some work to get the shield collisions back up to the earlier standard. Finally basic throwing has also been included. You won't believe how long it took me to get it all the way I liked it.

Here is the list of changes:
- Keys no longer respawn if collected
- Doors and switches get reset when exiting a dungeon
- The shadow of items now dissappears along with the item when in another room
- Poking containers is no longer the same as poking a wall
- Death resets the sprite of an equipped bottled fairy
- Added a sword beam
- Redid the pause mode
- Improved the routine of enemies being getting back
- Added 3 more rooms to visit (and some more you can't visit )
- Updated the collisions between flying tiles and solids
- Cannonballs continue to move from room to room
- Made some alterations to the Link walking through doors
- There are now conditional doors that only open when all enemies are defeated
- You can pick up / walk with / run with / throw containers and bushes
- Altered the way paths, rooms and timelines are referenced in the coding
- When link is hurt he turns transparent instead of invisible
- Enemies turn negative when hit
- Some lettering in the starting menu is now yellow
- Rupees etc now turn transparent before dissappearing
- Fix a whole lot of glitches and what not

For those wanting to help: I'm looking for some feedback on the cannonball puzzle room.
Also I'm still looking for a spriter and a programmer to join the team.

1422

Recruitment / Re: [Recruiting] GML Programmer, Spriter

« on: August 07, 2009, 03:35:58 pm »

Anybody interested in joining as a spriter?
All this talk of programming while I'm really looking for a spriter over a programmer.

1423

Discussion / Re: What makes a good 2D zelda dungeon?

« on: August 07, 2009, 03:33:07 pm »

There are lots of tips for creating a dungeon:
-Avoid simple backtracking. Instead try having the player naturally end up at / near an older locations where they now have newer options with there found item / key / whatever.
-Tease the player with unreachable locations they know can be reached later on.
-Connect your rooms with more than just doors. An examples from my game are pits spanning multiple rooms and cannonballs continuing to move through a second room after leaving the first.
-Puzzlewise it's mainly preference. Using simple mechanics can be very forfilling as long as you don't use the same thing twice (in exactly the same kind of situation)! Harder puzzles or for further down the line or something fresh. Just look at tetris.
-Post what you have, have it get flamed / praised and learn for the next one.
-Don't plan too big! Seriously. Don't plan too big!

1424

Contests / Re: Zelda Design Competition #1 - Dungeons | NEW DEADLINE |

« on: August 06, 2009, 05:03:57 pm »

So true. The bare minimal needed to enter is like a scrap of paper with mock-ups and idea's. Raen has mentioned something like this far more than once. Along with warnings that people shouldn't plan too big.

1425

Recruitment / Re: [Recruiting] GML Programmer, Spriter

« on: August 01, 2009, 05:48:23 pm »

This is probably my mistake. Well I wasn't looking for code, but more like how you would use GM. For example: In the CP 4Sword has all the game logic coded in the Step event, but ahmio has the game logic separated over many events, like key presses/releases and collisions.

I'm using multiple events per object. If I had to start from scratch maybe I might do it differently but that's not an option anymore. I do take the time to clean up when I feel it will help with the overview. For instance: keycommand are now handled through the general key press/release/hold events. There they are routed to the corresponding user_events (one per action (=left/right/run/menu/esc). So you have one event for actions, one for items etc.

I'm guessing this is what you want to hear: After the game select screen you there is one master_control_object and a character_control_object. These are the bases for the game. Beyond that you have a control object per area (which are also persistent), a control for the hud and some for the menu's (when those become needed).

The obj_Master_Control_Tile holds all the global game data. In other words, all the variables you would need the save in order to be able to restart later on. This includes a variable called Game_Mode which indicates normal play or wether menu's etc are active.

The Character_Control_Tile holds all the variables for actual gameplay. Like the variables needed in the movement engine (speed, direction, character facing etc), wether the character is hurt, falling, running, slashing or the id of the container he has above his head. Stuff like that. The most interesting variable is probably Link_Status that indicates his current activity (0=default walking/ standing, 1 = pulling/pushing, 2 = running etc)

The dungeon control tiles hold stuff like the sprites needed for the map menu. Wether rooms have already been visited, doors are still open or closed, wether cutscenes have occurred etc. I have not build these for the overworld yet because I feared I had to do them again anyway when I'd have arrived at programming the overworld. The objects for the overworld will essentially have the same function, just slightly different.

Other things: Are you trying to get the most of the code in scripts, or is the code mostly in the objects. Do you use external libraries or just Gamemaker code.

I start out by coding everything in the objects. Whatever I feel could be recycled for other objects or functions gets it's own script. When something needs temporary variables I also use scripts. So in the end most thing end up in a script one way or the other. I don't use external libraries because I simple don't know how. I should also mention that I only just got the pro edition (just a couple of weeks). I haven't really done much with it yet aside from play with transparency and use some blending. So much to do, so little time

This is some info I am looking for. Can you clarify a bit about what you mean with "as little objects or variables as possible"?

The variable Link_Status (mentioned earlier) is a good example. It has a value per state, since none of the states can occur together. I don't like using a separate value per state, just like I don't like using constants or global GML variables. They clutter the code and waste space (maybe just a little but it's the idea that matters). What I meant to say was that I like to be efficient with the variables I use. I'm in no way perfect, but I try to be

1426

Other Projects / Re: [Demo] Alttp-style game / tech demo -- No name yet

« on: August 01, 2009, 11:36:16 am »

It's already above Link. It's just a little hard to see on those screenshots.

I'm currently using:
draw_set_blend_mode(bm_subtract);
draw_set_color(c_dkgray);

There is one glitch with this I haven't figured out yet. At the start off the pause-state I use screen_redraw() directed at a surface. When I display that surface on the screen the shadow area is gone. Everything below the surface is gone as well. So if Link's head is under the shadow, then the surface shows him without a head. Similar things happen with enemy sprites. The tiles get displayed normally.

So, if you have suggestions then I'm listening.

1427

Recruitment / Re: [Recruiting] GML Programmer, Spriter

« on: August 01, 2009, 09:53:12 am »

Well, there's a distinct difference between = and ==...

I know. I just don't use it because I don't see a point to change it right now. Maybe I'll do it later when there is nothing else to improve on.

I am unaware of the universally used conventions simply because I know jack about programming except for one class of VB what I tought myself after that. I have zero interest to follow suit, simply because, either. I'm also not using sourcefiles, but that mainly because I haven't learned about them yet.

I get the point though. I'll posts some recent scripting. Since I'm learning as I go along the scripting gets better and more consistent when it's more recent.

Part of the movement routines that turns vector into an x and y component.

Code: [Select]

// Input:
// argument[0] = Walking_Direction
// argument[1] = Partial_Distance

if (argument[0] = 360) {Final_xspeed = argument[1]; Final_yspeed = 0} // move right
else {if (argument[0] = 270) {Final_xspeed = 0; Final_yspeed = argument[1]} // move down
else {if (argument[0] = 180) {Final_xspeed = -1 * argument[1]; Final_yspeed = 0} // move left
else {if (argument[0] = 90) {Final_xspeed = 0; Final_yspeed = -1 * argument[1]} // move up
    
else {if (argument[0] < 90) // upper right kwadrant
{
    Final_xspeed = cos(degtorad(argument[0])) * argument[1];
    Final_yspeed = -1 * sin(degtorad(argument[0])) * argument[1];
}

else {if (argument[0] < 180) // upper left kwadrant
{
    Final_xspeed = -1 * cos(degtorad(180-argument[0])) * argument[1];
    Final_yspeed = -1 * sin(degtorad(180-argument[0])) * argument[1];
}

else {if (argument[0] < 270) // lower left kwadrant
{
    Final_xspeed = -1 * cos(degtorad(argument[0]-180)) * argument[1];
    Final_yspeed = sin(degtorad(argument[0]-180)) * argument[1];
}

else // lower right kwadrant
{
    Final_xspeed = cos(degtorad(360-argument[0])) * argument[1];
    Final_yspeed = sin(degtorad(360-argument[0])) * argument[1];
}

;};};};};};};
Creation of a cannonball

Code: [Select]

// Input:
// argument[0] = required timeline

// Creation bubble
argument[1] = instance_create(x,y,obj_Cannonball);
argument[1].depth_scale = depth_scale;
if (depth_scale = 0) {argument[1].depth = 1003} else {argument[1].depth = 3};
argument[1].sprite_index = cannonball_sprite;
argument[1].damage = damage;
argument[1].magic_damage = magic_damage;
argument[1].damage_type = damage_type;
argument[1].origin_id = id;

// Start timeline
argument[1].timeline_index = argument[0];
argument[1].timeline_position = 0;
argument[1].timeline_speed = 1;
A script for creating an item through an container (or enemy).

Code: [Select]

// With (container)
// Input:
// Argument[0] = origin ; 0 = regular (origin top left corner); 1 = enemy (origin centered)
// set argument[4] = item created
// set argument[3] = shadow instance_id
// set argument[2] = check for heart

argument[3] = 0;
switch(item_index)
{
    case 0: exit; // no item
    case 1: argument[4] = instance_create(x,y,obj_Magic_Bottle_Small); break;
    case 2: argument[4] = instance_create(x,y,obj_Magic_Bottle_Large); break;
    case 3: argument[4] = instance_create(x,y,obj_Small_Heart); argument[2] = 1; break;
    case 4: argument[4] = instance_create(x,y,obj_Bombs_Single); break;
    case 5: argument[4] = instance_create(x,y,obj_Arrows_Five); break;
    case 6: argument[4] = instance_create(x,y,obj_Rupee_Green); break;
    case 7: argument[4] = instance_create(x,y,obj_Rupee_Blue); break;
    case 8: argument[4] = instance_create(x,y,obj_Rupee_Red); break;
    case 9: argument[4] = instance_create(x,y,obj_Small_Key); break;
};

argument[4].image_speed = 4/30;
argument[4].transparancy = 0;

// Position created item based on creating object
switch (argument[0])
{
    case 0:
        argument[4].x += abs(argument[4].sprite_width-sprite_width)/2;
        argument[4].y += abs(argument[4].sprite_height-sprite_height)/3 - 2;
        break;
    case 1:
        argument[4].x -= argument[4].sprite_width/2;
        argument[4].y -= argument[4].sprite_height/2;
        break;
};

argument[4].depth_scale = depth_scale;
switch (depth_scale)
{
    case c_Lower: argument[4].depth = 1025; break;
    case c_Upper: argument[4].depth = 25; break;
};
argument[3] = instance_create(argument[4].x+argument[4].sprite_width/2,argument[4].y-1+argument[4].sprite_height,obj_Item_Shade);
argument[3].transparancy = 0;
argument[4].shade_id = argument[3].id;
switch (depth_scale)
{
    case c_Lower: argument[3].depth = 1100; break;
    case c_Upper: argument[3].depth = 100; break;
};

argument[4].active = 0;
argument[4].alarm[0] = 5;

if (argument[2] = 1)
{
    with(argument[4]) {timeline_index = tl_Dwindeling_Heart; timeline_position = 0; timeline_speed = 1;};
}
else
{
    with (argument[4]) {path_start(path_Common_Item_Appearing,3,0,false)};
};

// Item dissapears with time (except for the key)
if (item_index <> 9)
{
    argument[4].counter = 20;
    argument[4].alarm[1] = 210;
};
    
// Make it so keys are one time items (all item are one-time in case of the containers)
if (object_name(object_index) = 'obj_Enemy_Regular_Death')
{
    if (creator_id <> 0 and item_index = 9)
    {
        creator_id.item_index = -1;
        argument[4].key_index = creator_id.key_index;
    };
}
else
{    
    if (creator_id <> 0)
    {
        with (creator_id) {item_index = 0};
    };
};

1428

Recruitment / Re: [Recruiting] GML Programmer, Spriter

« on: August 01, 2009, 09:02:30 am »

Conventions? I don't understand this word in this context. What's the dutch equivalent?

I code mostly like this:

Code: [Select]

switch ()
{
     case 0: // clarification if needed
          do something;
          break;
};
I use = instead of == but ! instead of <>. Those are not the bigger issues, as long as it work (well).
Every single variable I use (except argument) gets documented.
Resources are named script_ , sprite_ , bg_ , obj_ , parent_ etc. Little to no shortened names are used to keep the code somewhat simpler to get back into later on.
Older resources (mostly sprites) are still referenced by number but I'm gradually converting those.
I have a strong tendency to use as little objects or variables as possible.

I comment where needed but that of course is a relative term. Whatever is unclear I'll explain. I don't mind thinking up the solutions either. It's a team effort anyway.

1429

Recruitment / [Recruiting] GML Programmer, Spriter

« on: July 31, 2009, 05:44:37 pm »

We are looking for a GML Programmer and a spriter to help with our project located here:
http://www.zfgc.com/forum/index.php?topic=33701.0

Everybody is free to work on there own sections at there own pace. As long as you have attendion for detail.

The story and dungeon design are coming along nicely, but you'll have to send me a message if you want details like that beforehand. I don't want to spoil any surprises. The focus right now is to finish the first dungeon. Don't be fooled if you think that's not very ambitous because it includes every bit of needed engine as well as the required storyline. We are looking to make something solid (play the demo and you'll probably understand what I mean). Feel like you want to help then let me know.

1430

Other Projects / Re: [Demo] Alttp-style game / tech demo -- No name yet

« on: July 31, 2009, 05:11:20 pm »

Jup, we've moved production there since I felt we needed some place where we could freely post idea's, dungeon maps and boss sprites without ruining the surprise. I'll post some screenshots when I get my router so I'm not bound by this stupid datalimit anymore.

Anyway, progress has always been slow since I'm the soul programmer (with a fulltime job).

So we are recruiting!

If anyone wants to join the team as an added programmer or as a spriter please send me a message. I'll make a topic in the recruitment area right after this.

Update:
Here are two images of some shading I´m experimenting with. What do you guys think?

1431

Coding / Re: Negative sprites in Gamemaker (round 2)

« on: July 27, 2009, 08:07:50 pm »

Never mind. The code is not the problem. Appearantly GM starts to experience errors when you try to switch targets within a draw event. So I'm now using the End Step event to set the surface and the draw event to use and destroy it.

Again. Thanks for the help.

1432

Coding / Re: Negative sprites in Gamemaker (round 2)

« on: July 27, 2009, 06:14:19 pm »

Thanks for the post. I was looking into surfaceses (?) so I'm glad I was on the right track.

However, I still can't get it to work. Even worse, I have no idea what I'm doing wrong. This is the same code structure I use for my pause function (excl the negative bit) and that works fine.

Here is the code I have currently put in the draw event of an enemy's sprite:

Code: [Select]

if (control_id.recovery_time > 0)
{
    // draw negative sprite
    surface_Enemy_Sprite = surface_create(sprite_width, sprite_height);
   
    surface_set_target(surface_Enemy_Sprite);

    draw_clear_alpha(c_white, 0);
    draw_set_color(c_white);
   
    draw_set_blend_mode_ext(bm_inv_dest_color, bm_inv_src_color);
    draw_sprite(sprite_index, image_index, 0, 0);
    draw_set_blend_mode(bm_normal);

    surface_reset_target();
    draw_surface(surface_Enemy_Sprite, x, y);
   
    surface_free(surface_Enemy_Sprite);
}
else
{
    // draw sprite regularly
    draw_sprite(sprite_index, image_single, x, y);
};
The result is that (almost?) all the enemy sprites turn invisible as well as the character sprites (excl shadow) and the hud images. That makes absolutely no sense to me. Anybody see what's wrong in the code that might have caused this?

1433

Coding / Negative sprites in Gamemaker (round 2)

« on: July 26, 2009, 05:54:39 pm »

I'm sure some of you do this blindfolded. If you could also explain the answers then that would be most appreciated.

In alttp enemies turn negative when hit. That what I want to recreate. The enemy's sprite need to turn negative through it's own draw event. White turns to black etc. But the transparent pieces should stay transparent.

The answer I got in a previous topic turned the the images grayish. Including the parts that were previously transparent.

1434

Discussion / Re: [Request] LA sprites in ALttP style, please!

« on: July 11, 2009, 08:52:01 pm »

Welcome to the site. It's a kind of haven for Zelda fangames. The lack of anti-Zelda posts alone makes it worthwhile, let alone some of the competent members.

I'd like to give you a tip when making requests, especially when you're new: show some of your progress somewhere. How far along are you engine-wise for instance? You'll get help a lot sooner if you can convince people that the sprites will be used, if not used very well. Or when you present yourself in a skillfull or determined programmer/designer/whatever. Makes sense right?

No negative undertone intended. Just honest advise.

1435

Discussion / Re: Discussion on *why we don't finish projects*

« on: July 10, 2009, 03:05:36 pm »

Kinda true. I personally plan the most difficult things/complex I can think of just to keep myself challenged, but that's the point. I create my challenges. Stopping a project because there is no more to learn is "incorrect" thinking. You can always make it more challenging! There are other factors involved.

1436

Coding / Re: Loading maps with text files in GM7

« on: July 06, 2009, 07:48:03 pm »

I've been looking through the various functions of GML and I'm sorry to say I'm not convinced you can convert text to an object name. You can however use strings in combination with the switch command. Not a pretty sollution but it'll work. Or just use the index numbers for referencing. Sorry, that probably isn't a lot of help.

1437

Contests / Re: Zelda Design Competition #1 - Dungeons

« on: July 05, 2009, 09:24:41 am »

Raen: Be sure to make a sequel to the compition in it's current form! If I wasn't working on my own game so much (ooh and work ) then I'd definitely have entered.

For the next competition I do suggest some more flexibility with the items at your disposal. Some people want to build around a small amount of items and some around a lot of them. Give people the freedom to indicate a subselection of items they want to use for there dungeon, provided they uphold the other rules. Don't penalise when a puzzle can also be done with an item they didn't want to use. Maybe you'll already take stuff like that into consideration during the judging, I don't know.

Also when two or more people want to build a dungeon around the same item try and add in extra dungeons for that. One dungeon with a short range hookshot and one with a long range for instance. Or both with the hookshot but one with a .... shovel or whatever and the other with a heat resistant tunic. (BTW, I'll bow to the ground for the guy using the shovel). As you said, it's the designing that matters. I'd find it really interesting to see how two people go about the same concept and it'll be easier and fairer to judge. Also you'll still be forcing them to use a unique item (= shovel or tunic). Well maybe a shovel is a bit harsh.

Regardless. Be sure to organise sequels!

1438

Coding / Re: Turn current screen into background or other image?

« on: July 05, 2009, 05:12:59 am »

Okay, so that stuff is usefull for when you want to change the colors to empifice your pause mode.

DJVenom: You can still use it. It saves the screenshot into a background but the surface bit seems more practical now since backgrounds don't have variable depth. The background will either get behind my tiles or infront of my menu's.

Still it's good to know such functions exist. Thanks.

1439

Coding / Re: Turn current screen into background or other image?

« on: July 04, 2009, 06:47:32 pm »

I just can't let this one go just yet. It works but I still don't get half of it.

Here is the code the guy in the other topic suggested:

s = surface_create(view_wview,view_hview);
surface_set_target(s);
draw_clear_alpha(c_black,0);
screen_redraw();
draw_set_blend_mode_ext(bm_inv_dest_alpha,bm_one);
draw_set_color(c_black);
draw_rectangle(view_xview,view_yview,view_xview+view_wview,view_yview+view_hview,0);
draw_set_blend_mode(bm_normal);
surface_reset_target();
instance_deactivate_all(1);

Here is the code I am using, that seems (?) to work just as well:

surface_screenshot = surface_create(view_wview[current_view], view_hview[current_view]);
surface_set_target(surface_screenshot);
screen_redraw();
surface_reset_target();
instance_deactivate_all(true);

Both codes looks more efficient then my own concoction since they do not require saving to an external file, changing a sprite's image and they have the option to later empty the used layer. You create a surface, draw the current screen onto it and use it as a replacement image during the drawing event of an object. I get that part.

So what do the lines do between my shorten code and the code above it? What is there added value?

1440

Coding / Re: Turn current screen into background or other image?

« on: July 04, 2009, 05:35:14 pm »

Looks usefull. I don't get it (yet) since I've never before used surfaces, alpha's or draw events, but I'll be sure to take a closer look at it when I have some more time.