Hello Guest, please login or register.
Did you miss your activation email?
Login with username, password and session length.

Show Posts

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.

Messages - Martijn dh

Pages: 1 ... 53 54 [55] 56 57 ... 77
1081
Contests / Re: Dungeon Design Contest (using GMare)
« on: April 07, 2011, 06:52:57 am »
Noted. I'll add you to the list.

------

Here are a couple of general comments:
- The explanation section on the first post will be improved upon during the next two weeks.
- If there are any comments or questions let me know! I've currently got the time to help. I may not always be able to do that when the contest is underway.
- I've increased the number of roomblocks you may use from 10 to 16. (check step2)

1082
Updates / The Dungeon Design Contest will start on April 22nd
« on: April 06, 2011, 05:55:03 pm »
Registration is now open!

As promised there will an upcoming dungeon design competition.

When does it start? - April 22nd
Till when can I enter? - You have to register before the 29th of April to enter
Till when will it run? - The contest will run til the 31st of May or untill all the results have been send in

For more information read the connected topic in the contest section of the forum.

1083
Contests / Dungeon Design Contest (using GMare)
« on: April 06, 2011, 03:15:05 pm »
Dungeon Design Contest (using GMare)

When does it start? - April 22nd
How and till when can I enter? - Post here before April 29th to enter
Till when will it run? - The contest will run till the 31st of May or until all the results have been send in

On April 22nd each participant will be presented with a GMare file preloaded with the relevant objects and tileset. No additional resources may be used. All particants attempt to build a dungeon before the end of the event, which will then get graded by the general public. The winning design will be converted into a stand alone game, so we actually see it in action. You'll also receive a little trophy by your name as prove.

Below will be a detailed description on how to build a dungeon, how to add object and so on. Please browse through the text when it is finished. Preferably before starting on your dungeon design. Check the final chapter for details on how to submit your endresult.


Registered contestants:
- Homegrownpwn
- infinitenintendo
- Jetstorm4
- Knighty
- shongshui




HELP INDEX:




How to build a dungeon?

Step 1. Downloading GMare & resources

GMare can be found here: http://gmare.codeplex.com/
Resources can be found here: http://www.mediafire.com/?dagrrcudf6amsa6


Step 2. Defining rooms

When building your dungeon you will need to determine how large each individual room will be and where it is placed. To help you can do the following. First create a new layer, called Room Borders, at the default depth of -1000000000. Set your GMare grid to 320x320 and color the borders of the rooms you wish to use. Keep in mind that your dungeon may use no more than 16 blocks of 320x320 pixels. Here's an example:



The example shows that I want to build 3 rooms in my dungeon, using four blocks of 320x320 pixels.
Just a friendly warning: do not make rooms consisting of more then 6 blocks. It may murder the framerate if you are going place lots of objects in them later.

The following is an example that is wrong:


Rooms must always have a rectangular shape. The example above has a room that is a different shape and thus will not be usable.

After you have placed down the blocks to build your dungeon it is time to document the basic variables needed. Give each room a indexnumber starting from zero and create a separate textfile to document the following per room: room index / x / y / width / height

For the example I would have to document the following.


Code: [Select]
// Room information
Index / x / y / width / height
 0 /   0 /   0 / 320 / 320
 1 / 320 /   0 / 320 / 320
 2 /   0 / 320 / 640 / 320


Step 3. Tiling your rooms

When tiling rooms you have to keep an eye out for using the proper depths.

The two depthranges are:
- The upper floor (= all depths between 500 and 600)
- The lower floor (= all depths between 1600 and 1700)

Basically all basic floortiles may be placed within the lower depths. The exception to this is when Link (or any part/extention of Link) can pass under that piece of tiling. In that case the tiling has to be placed within the higher depths. I will demonstrate with the example below.

Upper Layer


Lower Layer



Step 4. Connecting your rooms

You'll want to connect your rooms with doorways, but it is important to understand that you can not just randomly place these anywhere. I'll try to explain and add some examples.

The reason lies in the in-game cameracontrol. When you are walking around in a room nothing outside of that room will be displayed on screen. This means that the camera does not always center on the main character. When you touch a doorway the screen will move in the direction of that doorway towards a new room. Upon arrival the game considers the new room as the current room and it checks if the camera can be centered yet again. If it then can than a nasty screenjump will occur. That's bad room design!

Let's say you want to add a doorway through a vertical wall:
- Place the doorways on both sides of the wall where you'd like to put them.
- Look at the center of your doorways and imagine an line going up 120 pixels and down 120 pixels (also see the example).
- If your line hits any room borders (which are the bright red area's in the example) and the same thing does not happen in both rooms equally then the doorway is not placed correctly. All other situations are fine.

Example 1 (Bad)

In this example I'm trying to place a doorway through a vertical wall. In the second image you can that I have marked the area 120 pixels up and down of the doorways. On the left side of the wall I hit the left room's border. This does not happen on the right side of the wall so my doorway is not placed correctly.

Example 2 (Good)

Here I am once again trying to place a doorway through a vertical wall. The second image highlights an area 120 pixels up and down from the center of the doorway. On both sides of the wall the upper border of the rooms is hit within those 120 pixels. This is fine! It happens, but it happens on both sides so there is no problem. If it would not have hit any borders then it would have been fine also.

Positioning a doorway through a vertical wall is basically the exact same thing. Only instead of looking 120 pixels up and down, you'll need to look 160 pixels left and right.

< I'm skipping the rest of this step to keep things simple. You will not have to worry about changing tiledepths between doors. Nor will you have to place the needed objects >


Step 5. Placing doors

There are currently 3 doorobjects:
- obj_Locked_Door_Small_Key
- obj_Locked_Door_Large_Key
- obj_Conditional_Door

Place these at the center of the doorway where you want them (see example below).
I will need a list of the following information per locked door: x / y / doorindex / small key or large key / opened or locked
I will also need a list of the following information per conditional door: x / y / doorindex / opened or closed

Doorindex = The indexnumber by which one or multiple doors may be referenced. The count starts at 0 and there is separate count for locked and conditional doors. Doors that share the same state (=opened or closed) and are dependant of each other (=open together or close together) should be given the same index number. Each other door should get it's own index number.

Here is an example placement and documentation.


Code: [Select]
// Locked doors
// x / y / doorindex / small key or large key / opened or locked
104 / 264 / 0 / large / locked
104 / 360 / 0 / large / locked
472 / 384 / 1 / small / locked
472 / 240 / 1 / small / locked

// Conditional doors
// x / y / doorindex / opened or closed.
272 / 96 / 0 / closed
352 / 96 / 0 / closed


Step 6. Placing chests

To add a chest to your game, wether it is a large or small chest, first tile the bottom half of the chest into your room like you would the floor. Then place the object obj_Chest on top of it as show in the example below. Finally document the following information per chest: x / y / index / large or small chest / content

Possible chest content:
- Nothing
- Rupee (green/blue/red)
- Key (small* / master)
- Book of Mudora
- Bottle containing a fairy
- Compass
- Dungeonmap
- Pegasus boots
- Glove (silver / gold)
- Sword (default / master sword)
- Shield (default / upgraded shield)
- Tunic (upgraded tunic)
* more details can be found in step 11

Example placement and documentation:


Code: [Select]
// Chests
// x / y / index / large or small chest / content
408 / 200 / 0 / small chest / master key
104 / 464 / 1 / large chest / pegasus boots


Step 7. Placing containers

To add a container to your game simply place the object obj_Container_Creation. Then add the creation coding as seen below. Containers basicly only need three input variables:
- depth_scale: meaning is the container positioned on the upper or lower floor.
- type: what kind of container you want it to be. The possible options are listed inside the creation coding example.
- item_index: what items should be created when the container gets destroyed.

Creation code:
Code: [Select]
depth_scale = <fill in c_Upper or c_Lower>;

type = <fill in one of the numbers below>;
// 0 = vase normal
// 1 = bush lightworld
// 2 = skull
// 3 = small rock light
// 4 = small rock heavy
// 5 = gray square block
// 6 = large rock heavy
// 7 = large rock darkworld
// 8 = large rock light
// 9 = crate
// 10 = bush darkworld
// 11 = vase middle
// 12 = vase large
// 13 = barrel

item_index = <fill in one of the numbers below>;
// -1 = random
// 0 = none
// 1 = small magic bottle
// 2 = large magic bottle
// 3 = small heart
// 4 = single bomb
// 5 = five arrows,
// 6 = green rupee (1)
// 7 = blue rupee (5)
// 8 = red rupee (20)
// 9 = small key*
* Check out step 11 for more information on adding keys

Overview of the available containers:



Overview of the different weights:

Light (no gloves needed)
 0 = vase normal
 1 = bush lightworld
 2 = skull
10 = bush darkworld
11 = vase middle

Heavy (silver gloves needed)
 3 = small rock light
 8 = large rock light
 9 = crate
12 = vase large
13 = barrel

Very heavy (golden gloves needed)
 4 = small rock heavy
 5 = gray square block
 6 = large rock heavy
 7 = large rock darkworld


Step 8. Placing ledges and lights

Ledges

Link can jump from ledges in a straight line. You will do not have to place objects needed for this, but as the designer you should make sure Link does not get stuck while landing. I will attempt to further explain this with two images.

Image 1:


The locations along the ledge that are marked red indicate bad locations to jump down. Moving in a straight line down from there will result in the character getting suck in the walls. The brown area is equally unsuited because moving down in a straight line will get the player stuck inside the chest or the stairs. Had the chest been positioned 8 pixels lower then the location would still be unsuited, since Link always links a tiny distance away from the wall. Had the chest been positioned 16 pixels lower and the stairs 8 pixels further to the right then it's all good. The green area is what remains and those are the positions where Link can jump down safely without any further adjustments.

Image 2:


Taking the comments from the first image into consideration your room might end up looking something like this (if you want Link to be able to jump done anywhere possible).


Lights (also named "torches")



1. Small torches
These are the lights you could light with the lantern in Alttp. In my game however you currently can't do anything special with it (yet) so adding one would just be for decoration purposes. Simply place the obj_Small_Torch somewhere in your dungeon and you're done.

2. Large torches
These are the larger lights (32x32 pixels), you sometimes see in dungeons, which are also just meant as decoration. Place the obj_Large_Torch somewhere in your dungeon and you are done.

3. Wall lighting
These are the lights you sometimes see attached to walls inside dungeons. Adding them is a small hazzle. First place a obj_Wall_Light on the wall like as seen in the example above. The add the following creation code:
Code: [Select]
sprite_index = sprite_Wall_Light_A;
image_speed = 1/6;
Required_Facing = <fill in c_Left, c_Up, c_Right or c_Down>;

For required facing enter the character's facing when he's looking at the light on wall. If you are placing the light on the left side wall of your room then enter c_Left. Use c_Up for the upper wall, c_Down for the lower wall and c_Right for the right wall.


Step 9. Placing switches and movables

Switches have different means to activate and they are usefull for triggering events, which I'll explain in step 12.

Pressure plates
There are three types of pressure plates:
0. The switch is activate (once) when you stand on it
1. The switch is activate as long as you stand on it
2. The switch alters between an active and inactive state each time you stand on it

To add a pressure plate place an obj_Pressure_Plate somewhere in your dungeon. Next document its location, index number, type and sprite.
Code: [Select]
// Pressure Plates
// index / x / y / type / sprite
0 / 150 / 320 / 0 / 1
1 / 20 / 764 / 1 / 1
2 / 66 / 320 / 2 / 2

There are two sprites to pick from (as seen in the image below). The first sprite is used for a default pressure plate you see under pots and elsewhere. The second is usefull as a more hidden pressure with a simular floorpatern.


Crash switches
A crash switch is an invisible switch that activates when the player crashes up against it using the running boots. To add one of these position an obj_Crash_Switch inside something solid (like a wall, large light or even a master chest) in a way that the player can walk up against it, but not over it.

Next give it the following creation code:
Code: [Select]
index = <fill in the crash switch's index number>;
depth_scale = <fill in either c_Upper or c_Lower>;

And then document all of your crash switches:
Code: [Select]
// Crash switches
// index / x / y
0 / 148 / 320
1 / 204 / 764

Movable objects

When defining a movable object you are given the option to disable each individual movement direction. You can forget about this if you want by allowing all movement. If want however it is possible to get creative.

Example 1: Using events (=step 12) you can use this to create a "pull switch". Let's say the movement object is placed at y = 90 and may only move downwards. When it is moved down to y = 98 you can use that as a trigger for an event like opening a door and/or lock any further movement with that movable object by disallowing all directions.

Example 2: Let's say you want a moveable object / statue in your room with a limited action radius. The object allows movement in all directions, but if  x < 90 then you disable further movement in the left direction. Doing this for all directions allows you to define a nice (rectangular) area for the movable object to stay containt in. Like for instance, the statue may not move off the carpet on the floor.

To add a movable object place down a obj_Movable_Object somewhere in your dungeon. Next document its location, index number, sprite and which directions the object is allowed to move in.
Code: [Select]
// Movable objects
// index / x / y / sprite / allow left / allow up / allow right / allow down
0 / 150 / 320 / 1 / true / true / true / true

There are two sprites to pick from (as seen in the image below).



Step 10. Placing enemies

To create an enemy you will have to place the following object in your dungeon: obj_Enemy_Creation. Next, right click on the created instance and fill in the creation code to specify the enemy parameters. I'll go over the needed creation code per type of enemy in a minute. The symbols <> indicate what values you may (or have to) change. First though there some variables to explain.

depth_scale - This variable tells wether the enemy is positioned on the upper or lower floor. Fill in either c_Upper or c_Lower for the respective floors.
facing - This variables tells which side the enemy should be facing at the time of his creation. Fill in either c_Left, c_Up, c_Right or c_Down.


Enemy creationcodes

Plant
Code: [Select]
// parameters
name = "Plant";
depth_scale = <fill in c_Upper or c_Lower>;
enemy_type = 0;
item_index = -1;
active_outside_room = 0;

Stalfos (blue / red / yellow*)
Code: [Select]
// parameters
name = "Skeleton Normal";
depth_scale = <fill in c_Upper or c_Lower>;
enemy_type = <fill in 0 for a blue and 1 for a stronger red stalfos>;
item_index = -1;
facing = <fill in c_Left, c_Up, c_Right or c_Down>
active_outside_room = 0;
*Check out step 12 for information on how to add a the yellow stalfos (= the one falling from the ceiling)

Cyclops Guard (green / blue)
Code: [Select]
// parameters
name = "Cyclops Guard";
depth_scale = <fill in c_Upper or c_Lower>;
enemy_type = <fill in 0 for a green and 2 for a stronger blue cyclops>;
item_index = -1;
facing = <fill in c_Left, c_Up, c_Right or c_Down>
active_outside_room = 0;

Anti-Faerie
Code: [Select]
// parameters
name = "Anti-Faerie";
depth_scale = <fill in c_Upper or c_Lower>;
enemy_type = 0;
item_index = -1;
direction = <fill in any number from 0-360 to set the starting direction for this enemy>;
active_outside_room = 0;

Pol's Voice
Code: [Select]
// parameters
name = "Pols Voice";
depth_scale = <fill in c_Upper or c_Lower>;
enemy_type = 0;
item_index = -1;
active_outside_room = 0;

Buzz Blob
Code: [Select]
// parameters
name = "Buzz Blob";
depth_scale = <fill in c_Upper or c_Lower>;
enemy_type = 0;
item_index = -1;
active_outside_room = 0;


Step 11. Understanding keys

Adding small keys to your dungeon can be done in 5 ways, which I'll explain below.

Default - placing it on the floor
Place the obj_Common_Item somewhere on the map. Then document the location of the object plus the key index you want to give it.

Inside a container
Place a container on the map like you normally would. Then document the location of the container and the key index you want to give it.

Inside a chest
Add a chest and document it like you normally would (as seen in step 6). Next document the location of the chest (again) in the small key overview. This time in combination with the key index.

Held by an enemy
Place an enemy on the map like you normally would (as seen in step 10), giving it it's usual creation coding. Then document the location of that enemy in combination with the key index.

Falling from above
You may make use of keys that fall from the ceiling if the right conditions are met (see step 12). For example when all the enemies in the room have been killed. Do you not have to place an object in your room for this one. Simply document where you want the key to land and what it key index should be.


Each key needs it's own index (so they are one time occuring objects) and you'll need to document where it is located. This is important that there is one seperate listing for the small keys eventhough a key's location may also have already been documented elsewhere. Fragmented / scattered documentation is bad!

Example. If I place a key for each of the 5 possible I would have to document something like this:
Code: [Select]
// Small Keys
// index / x / y / description
0 / 552 / 168 / default
1 / 180 / 180 / inside container
2 / 208 / 766 / inside chest
3 / 344 / 208 / held by enemy
4 / 500 / 504 / falling from above


Step 12. Understanding events

Events have to be coded in scripts, so the contestants will not have to actually do this. You can however (to keep it simple) add a default trigger + event to your dungeon by documenting a line like so:
Code: [Select]
For room <index>: if <condition(s)> then <event(s)>Should your dungeon be the winner then I'll code the events for you using the given instructions. The conditions and events available are listed below. If however you feel a vital event or condition is missing then you should contact me. The conditions are stated as A = B, but you may also use A < B or A != B and so on. If-then-else is also possible.

Available conditions*:
-Entering room
-Chest [index] = opened
-Pressure Plate [index] = active
-Crash switch [index] = active
-Count enemies of type [name or all] = number
-Position [x or y] of Moveable object [index] = value
-Movable object [index] in contact with Pressure Plate [index] = true
-Permanent_condition <index> = value

Events:
-Conditional door <index> opens / closes
-Enemy <description> appears at position <x,y>*
-Enemy Yellow Stalfos falls down to position <x,y>*
-Pressure_Plate <index> state = active / inactive
-Crash switch <index> state = active / inactive
-Movable Object <index> allow movement in direction <direction> allow/disallow
-Drop small key <index> down at position <x,y>
-Permanent_condition <index> = value
*For enemies appearing/falling down make sure to also add the creation coding af that enemy to indicate it's type and so on.

Permanent conditions
You've probably noticed that I also listed something called permanent_condition both as an condition and event in the list below. That's a variable name that is stored for your dungeon. This will help you with your events if you want to make an event a one time occurance. Or if you want an event in one room have impact on another room.
To use permanent conditions first define them by documenting them:
Code: [Select]
permanent conditions
index / starting value
0 / false
1 / 0
2 / -7

Examples
I'll give some examples of what events can do for your dungeon:

Example 1: When I enter room 3 I immediately want the doors to close and have 3 skeletons and 1 plant appear every time. When all enemies are dead the doors open.
Code: [Select]
For room 3:
if enter room then
  appear blue stalfos at (100,50) , (90,90) and (100,70) and appear plant at (80,80)
if count enemies of type all = 0 then
  conditional door 0 opens and conditional door 4 opens

Example 2: I want the same as example 1 but it should only happen when I first enter the room. Remember: I have already documented that permanent_condition[0] = false.
Code: [Select]
For room 3:
if enter room and permanent_condition 0 = false then
  appear blue stalfos at (100,50) , (90,90) and (100,70) and appear plant at (80,80) and permanent_condition 0 = true.
if count enemies of type all = 0 and permanent_condition 0 = false then
  conditional door 0 opens and conditional door 4 opens

Example 3: Let's say I have a room with a pressure plate and a movable object. The pressure plate is only active if you stand on it, but you need to stand on it to open a door. The player has to move the movable object on top of the plate to open the door.
Code: [Select]
For room 2:
if movable object 0 in contact with pressure plate 0 = true then
  conditional door 1 opens
else
  conditional door 1 closes

Example 4: Let's say I have a door in room 0 that only opens if I use three switches in three of the other rooms
Code: [Select]
For room 0:
if permant_condition 1 = true and permanent_condition 2 = true and permant_condition 3 = true then
  conditional door 3 opens
For room 1:
if Crash switch 0 = active then
  permanent_condition 2 = true
For room 4:
if Pressure_Plate 0 = active then
  permanent_condition 3 = true
For room 5:
if Pressure Plate 2 = active then
  permanent_condition 0 = true


Step 13. Global dungeon design

This step describes the two minor details to finish a dungeon: the start and end

The start of your game
Please fill in the following form to indicate where the character starts and what stats he should have.
Code: [Select]
Starting conditions
Starting location: (x,y)
Health: (number of hearts)
Sword: (none / lv1)
Shield: (none / lv1)
Pegasus Boots: (none / collected)
Gloves (none / lv1 / lv2)
Bottle 1: (none / empty / life medicine / magic medicine / cure all / caught fairy)
Bottle 2: (none / empty / life medicine / magic medicine / cure all / caught fairy)
Bottle 3: (none / empty / life medicine / magic medicine / cure all / caught fairy)
Bottle 4: (none / empty / life medicine / magic medicine / cure all / caught fairy)

The endgoal of your game
To set the endgoal of your dungeon place the object called obj_Credits in your dungeon. This object is invisible for the player and if they touch it the credits will roll and the game ends. It is possible to make this object visible and use a different sprite, but that is up for you to decide should you win. I'm open for suggestions on that matter.


Step 14. Sending in your submission
< explanation is being worked on >

1084
Plenty of progress in the last two weeks:
-All objects storing dungeon data have been converted into a single object
-All references to dungeon data have been adjusted to fit the new situation
-Started working on including all dungeondata in the savefiles
-Spend a couple of days tweaking the pick up mechanic, but I was unhappy with the result and scrapped all of the progress. :(


I've also been spending a number of days working on the room below. It's not much to look at right now, but I'll upload more images as it progresses. Personally I always like seeing something come to life like that. If anybody spots inconsistencies then feel free to point them out, but don't bother with comments on the green earth. That's gonna change anyway. The setting is a mountainpath up to dungeon 1. The goals of this room (and the once before it) are: give the player the feeling he is really moving higher and higher up a mountain and give the player the felling of discovering a far away hidden temple.


1085
That's a though question as I have been without help for quite a while now :( I estimate I will be adding in new stuff in about 2 or 3 months time, depending on your definition of added content of course. It also depends on how the proposed "Design your own dungeon" contest mid April will work out.

Right now I have the following planned (in order) before releasing a new demo:
- Finish the saving feature to also include dungeon data (will also require me redefine the area control objects in a more uniform manor)
- Finish cleaning up the coding behind the starting screen (not essential but I'll probably continue my work on it anyway)
- Finish the snake enemy (more or less new content)
- Revisit picking up containers (worked on this a little yesterday. It's something I've been putting off for far to long already)
- Make some tweaks container shadows and stabbing of enemies
- Recode the sword's energy attack
- Add in magic attacks for the firerod/icerod/rod of medu (new content. This will be a major undertaking as it also means enemies should be burnable, get frozen etc)
- Make dungeon updates for the use of the firerod (new content. It should allow access to about 10 more rooms and it will straighten out order in which the dungeon is to be completed)

All in all, it's not heavy on new content. I'll see about adding more enemies and items for the demo after that one.

I must say, since I have little time to actually spend on the project I tend to work more on improvements rather then completely new content. It's not very flashy progress but I don't believe I've ever aimed for something like that XD.

PS: Having people help out with dungeon/area design would greatly improve the odds for new content in the near future. A tester would also be welcome.

1086
The weekly progress:
+ Finished the save feature for the character data (plus send FrozenFire a copy)
+ Further lessened the number of objects and variables needed for the startingscreen

1087
Zelda Projects / Re: The Legend of Zelda: Spirit's Quest
« on: March 20, 2011, 07:43:27 am »
Arrays are a godsend when you have an large/variable number of (identical) variables. One advantage is that you can very easily loop through stored data. It is probably learn about them early on so you know what options are available! Discovering them later on and having to recode sections is a timely affair. Trust me, I know XD

An array example:
Code: [Select]
....

for (argument[1]=0; argument[1] < obj_Master_Control_Tile.body_sprite_count; argument[1]+=1)
{
     draw_sprite_ext(
                    obj_Master_Control_Tile.body_sprite[argument[1]],
                    image_single, floor(x), floor(y), 1, 1, 0,
                    obj_Master_Control_Tile.body_pallet[obj_Master_Control_Tile.Equipment_B3,argument[1]],
                    argument[2])
};

...

What you see here is a part of the script I use to draw my character (= first example that came to mind).

First just a little description of it's use. What this coding does for me is that I can switch between tunics/frozen/stone appearances on the fly. When I want another set of colors drawn I change Link's tunic variable. If I want to add, remove or alter a set of colors it is as simple as altering the arrays going into this coding. This all makes it so I do not have to physically alter every Link-sprite used when I want to change his colorpallets or when I add/remove a tunic and so on.

First I predefined how many layers my character will consist of using the variable body_sprite_count (There is also a function like Ubound(insert array, insert array dimensionindex) that can also be used, but I prefer using a variable). The sprites I wish to draw are defined in the body_sprite array, which has only one dimension. The colors I wish to use are defined in the body_pallet array which has one dimension to determine what set of colors to use and a second to pick the actual color.

So I circle through a preset number of sprites. For every sprite I wish to draw I retrieve it's reference from body_sprite and draw it in the color associated with the current tunic and sprite.

The arrays used are defined like so:
Code: [Select]
// Layer count
body_sprite_count = 5;

// Body sprites [pallet number ; sprite]
body_sprite[0] = sprite_Link_Body_A;
body_sprite[1] = sprite_Link_Body_B;
body_sprite[2] = sprite_Link_Body_C;
body_sprite[3] = sprite_Link_Body_D;
body_sprite[4] = sprite_Link_Body_E;

// Body colors [pallet number ; color]

// B0. [Default tunic];
body_pallet[0,0] = make_color_rgb(248,248,248); // white
body_pallet[0,1] = make_color_rgb( 56,144,104); // dark green
body_pallet[0,2] = make_color_rgb( 64,216,112); // light green
body_pallet[0,3] = make_color_rgb(136, 88, 40); // arms
body_pallet[0,4] = make_color_rgb( 80,144, 16); // dark green

// B1. [Water tunic];
body_pallet[1,0] = make_color_rgb(248,248,248); // white
body_pallet[1,1] = make_color_rgb(  0, 96,208); // marine
body_pallet[1,2] = make_color_rgb(136,160,232); // light blue
body_pallet[1,3] = make_color_rgb(200, 96, 32); // arms
body_pallet[1,4] = make_color_rgb(192,168, 72); // dark yellow

..... and so on

The only problem with Gamemaker is that it can't handle anything beyond two dimensions.

1088
Why hate to ask? You've helped me plenty in the past. I haven't forgotten.
Once I'm done figuring it out for myself you'll receive simular scripts.

1089
Spend the last couple of hours working on a more elaborate saving system (using ini files). And then I started thinking up ways to prevent people from messing around with the savefiles. I may have went a little overboard, but at least the data in the ini files is impossible to crack now.

Currently I've implemented the actual saving plus encrypting of the data. Hopefully I'll get around to the loading aspect next week.

1090
Feedback / Re: How about another contest?
« on: March 13, 2011, 02:00:18 pm »
I'll see about setting up the contest mid April (which is right after my exams). Contestants will be given about 4 or 5 weeks to turn in their results.

1091
Latest progress report:
- Finished recoding the item menu (it's now just comprised of one object).
- Made some more coding changes to the startingscreen, saving more resources.
- Added in an auto-save function for the game settings. It should be a welcome addition for those that dislike the pre-set controls.

1092
Feedback / Re: Revamping ZFGC
« on: March 05, 2011, 05:28:35 pm »
The "we" and "this will be a whole new era" parts. No offense meant though.

1093
Feedback / Re: Revamping ZFGC
« on: March 05, 2011, 05:19:51 pm »
I believe you are getting a little ahead of yourself there.

1094
Feedback / Re: Revamping ZFGC
« on: March 05, 2011, 12:41:25 pm »
Who says we have to upload video's each week, or each month for that matter? Just upload if there is something you would normally create a video for.

1095
Feedback / Re: Revamping ZFGC
« on: March 05, 2011, 11:48:53 am »
The PotM had plenty of activity each month. The only reasons it isn't continued right now is because I got a new girlfriend last year (= less free time), nobody stepped up to continue on, 4Sword wanted to change it once again.

1096
Feedback / Re: Revamping ZFGC
« on: March 05, 2011, 11:36:29 am »
Why not pick up on that idea of a combined zfgc youtube account? I find it a wonderfull idea.
Low level of effort required to try out. Large audiance to appeal to. Why not?

There will be the occasional shitty video, sure. But people interested in zelda fangames who see that most fangames are clustered on one forum will likely come and visit. More so then when I (or someone else) mentions zfgc in a video or in a comment on some other forum.

1097
Feedback / Re: How about another contest?
« on: March 05, 2011, 11:02:05 am »
If we are going to do this, then it's best to start slow. More available features will be added as time goes by and more contests have been held. I don't want to start off fluding the contestants with too much with information, rules and so on.

I'll try to explain the proposed contestsrules in more detail in the starting post. What I want you guys to do is comment if the rules are in any way unclear, so that we can work towards a noob friendly explanation.

PS: Can the winner be rewarded with a little icons/trophy like I have earned from PoTM?

1098
Feedback / Re: How about another contest?
« on: March 04, 2011, 08:13:15 pm »
Point taken. Could you please move the topic over to the feedback section then (since my admin rights are gone these days)?
It'll take some time to set up (like a number of weekends) so I figured the staff section would be a good place to start without getting anybody's hopes up too much, but I understand what you're saying.

1099
Feedback / How about another contest
« on: March 04, 2011, 05:10:36 pm »
Event: A dungeondesign contest where I'll turn the winning map into a standalone game
When: Starts mid - late April 2011
Duration: Preliminary plan is for 6 weeks of development

Each participant is presented a GMare file preloaded with the relevant objects and backgrounds from my game. No additional resources may be used. All particants attempt to build a actual dungeon, which is later graded on originality, fun factor and general appeal by the general. I personally will grade it on feasibility. The winning design will be converted into a stand alone game, so we actually play it in action. Should be a fun experiment to pass the time.

At the enddate each participant will return the following:
- The finished GMare file containing the designed dungeon
- A secondary textfile detailing the dungeon for the general audience
The goal is to describe the general working of your dungeon and how you'd like switches and doors to behave.
- Further files aimed towards me giving me the needed information to build your dungeon.
Think along the lines of indexnumbers for a range of different objects and detailing the roomparameters.

I will do my best to describe below how to build your dungeon.

-----------------------------------
-----------------------------------

Step 1. Downloading GMare & resources

GMare can be found here: http://gmare.codeplex.com/
Resources can be found here: <will only be available at the start of the event>

< Maybe I'll include more information on how to get started with GMare >


Step 2. Determining rooms

Part A

When building your dungeon you will need to determine how large each individual room will be and where it is placed. To help you achieve this I have include the objects: obj_Room_Block_Large_A t/m D. Set your GMare grid to 320x320 and place up to 10 blocks to make up your dungeon. Here's an example:



The example shows that I want to build 3 rooms in my dungeon, using four blocks of 320x320 pixels.
Just a friendly warning: do not make rooms consisting of more then 6 blocks. It may murder the framerate if you are going place lot's of objects in them later.

The following is an example that is wrong:


Rooms must always have a rectangular shape. The example above has a room that is a different shape and thus will not be usable.

Part B

After you have layed down the blocks to build your dungeon it is time to document the basic variables needed. Give each room a indexnumber starting from zero and create a seperate textfile to document the following per room: room index / x / y / width / height.

For the example I would have to document the following.


Code: [Select]
Index / x / y / width / height
 0 /   0 /   0 / 320 / 320
 1 / 320 /   0 / 320 / 320
 2 /   0 / 320 / 640 / 320

Part C (not manditory)

You may list a name per room. This name will be briefly displayed in the center of the screen if a player enters that room. The game remembers the last name to have appeared. If the character walks into a room with a different name then that new name gets displayed. Nothing happens if a room does not have a name. You can use this to give the player a message when he first enters an area, whenever he enters a new room or when he moves from once section to another section.

Given the example screenshot I have been using I could send along the following information:
Code: [Select]
Index / x / y / width / height / name
 0 /   0 /   0 / 320 / 320 / Shrine
 1 / 320 /   0 / 320 / 320 / Shrine
 2 /   0 / 320 / 640 / 320 / Treasureroom
The result will be that the player will once get a message that he's entered the shrine (assuming he starts in either room 0 or 1). Whenever he enters the treasury he will get a notification. Whenever he leaves the treasury he will get a notification.

And that concludes defining rooms.


Step 3. Building bare rooms
< explination is being worked on >

Step 4. Connecting your rooms
< explination is being worked on >

Step 5. Adding roommasking
< I'm skipping this step to keep things simple. You will not have to do any masking>

Step 7. Placing various objects
< explination is being worked on >

Step 8. Placing enemies
< explination is being worked on >

Step 9. Detailing dungeon conditions
< explination is being worked on >

Step 10. Detailing the start and ending positions
< explination is being worked on >

1100
Feedback / Re: Death of ZFGC
« on: March 02, 2011, 08:13:25 pm »
Reasons for my own lowered activity: working lots, working late, studying and having fun with the girlfriend.
Haven't grown out of fangames too much because it's a hobby. My personal guilty pleasure.

As a response to the first post. I agree that a cooperative project might do the forum some good.
I have been pondering on this one idea for a number of months now, which may or may not spark some interest. I've got an engine with a decent amount of features in it. Gmare is just released and it helps people to work together on a single game (to an extend). How about combining the two? Maybe it'd be fun if I'd give a group the opportunity to build something in Gmare which I'd in turn convert to my engine, as a standalone game. All that is currently present in the engine would be the available as a buildingblock. Just a thought. It'd need a further introduction obviously.

Pages: 1 ... 53 54 [55] 56 57 ... 77

Contact Us | Legal | Advertise Here
2013 © ZFGC, All Rights Reserved



Page created in 0.111 seconds with 36 queries.

anything