pass parameters

Basic Php array and function usage tutorial

I was planning to post a tutorial about “How to develop a Facebook application” but one of my friends wanted me a simple php code and i thought posting it on my blog can be useful for people who’s searching basic tutorials about functions,arrays and date function usage with php.

Now let’s take a look what we’ll do. We’ll code a simple php file that takes system date and counts 4 days on it and puts them into a html form with month, year and hour limits that we decided before.

You see, its a simple tutorial. But its bit more complex then it seems. We have to check if its over a months last day when we’re counting next 4 days. If we passed next month we’ll add next month option to form. Maybe its last 4 days in a year so we have to pass next year or we have to check if february has 28 days or not.

Anyways lets start tutorial;

First we need an array that we’ll push months day limits


Later we need three more arrays to push 5 days,months and years. We use arrays for months and years coz we can pass next month and next year




Now we can check if january has 28 days or not. We use php mod math function to check.

if(date(“Y”) % 4 == 0)


Now we need 4 variables for starting day,month,year and for day limit of a month. We’ll get system date for these variables.





Later we’ll code three functions, first for init arrays for days,month and years. We’ll push systeam day for first day, system month for first month, and system year for first year. Second function is for filling arrays. We’ll push next 4 days and maybe we’ll push next month and next year. And third one is for printing html form on screen.

Focus on we pass arrays and pass variables to functions in php. You can ask why i use functions for this basic and simple tutorial. It doesn’t metter how hard or simple problem that we faced. A professional coder use effective methods and dividing problems into simple parts with functions. 




Now we can code functions.

First add first values to specified arrays. (System date)

function initArrays(&$da,&$ma,&$ya,$d,$m,$y)

{ array_push($da,$d);




Second add days next 4 days and if neccesary next month and next year to specified arrays

function fillArrays(&$da,&$ma,&$ya,$d,$m,$y,$l) 

{ $i=0;

for($i;$i<4;$i++) // counting next 4 days

{ ++$d; 

if($d>$l) // if we passed new month

{ $d=1; // make day 1;



{ ++$m; // add new month to array

if($m>12) // we passed next year

{ $m=1; 













Third and finally print form on screen

function createForm(&$da,&$ma,&$ya) // html formun oluşturulduğu kısım.
{    $i=0; $k=0; $p=0;   
    echo ’<form method=“post” action=“zaman.php”>
            <select name=“gun”>’;
                echo ’<option value=“’.$da[$i].’” >’.$da[$i].’</option>’;
    echo ’</select>
        <select name=“ay”>’;
                echo ’<option value=“’.$ma[$k].’” >’.$ma[$k].’</option>’;
    echo ‘    </select>
            <select name=“yil”>’;
                echo ’<option value=“’.$ya[$p].’” >’.$ya[$p].’</option>’;
    echo ’</select>
            <select name=“saat”>
            <option value=“00”>00</option>
            <option value=“03”>03</option>
            <option value=“06”>06</option>
            <option value=“09”>09</option>
            <option value=“12”>12</option>
            <option value=“15”>15</option>
            <option value=“18”>18</option>
            <option value=“21”>21</option>
            <input type=“submit” value=“gönder” />


Now we learnt how to use arrays, functions and date function in php. And also we passed parameters arrays to functions.
I hope it was a useful tutorial for newbies on php.

Coding the perfect slope

This is very different from the other stuff i’ve posted so far. This is a technical post on how I made 45º slopes in my game.

First of all, this post is intended for those who are coding their own platformer physics. If you’re using an engine, the hard work might have already be done for you.

What the hell is a “perfect slope” anyways?

When I finished implementing square tiles in my game I was ready to make slopes, when I remembered countless games that had wonky slope physics. I didn’t want something like that for my game.

In those games the player would do things like these:

  • Slide down the slope when idle
  • Not be able jump off a slope
  • “Fall” off a slope when descending it
  • Stand on a slope with only the corner of their feet

Would you play a game if the player couln’t jump off a slope?

Me neither.

I decided i would have to either drop slopes or adress all those problems. I did the latter and it turned out pretty well (after about 2 weeks).

How my collision works

My collision is done in two passes, horizontal and vertical.

First i update the player’s x position and detect horizontal collisions, then I update the player’s y and detect vertical collisions. Here’s pseudocode:

“px” and “py” are the player’s positions, and “pSpeedX” and “pSpeedY” are the player’s velocities. the parameter passed to “collisionDetect” is the pass. 0 for horizontal, 1 for vertical.

Detecting collisions with slopes (45º only)

With square tiles it’s pretty trivial, since both are box-shaped. This is called an AABB (Axis Aligned Bounding Box) collision detection and it’s done like this:

Detecting collisions with square tiles are done in both passes.

With slopes it’s a little bit different:

First of all you need to know which direction the slope is “facing”. I do that with a boolean called “slopeDirection”.

You start by checking if the player is inside the slope’s bounding box before making further checks. You do that the same way we did with square tiles. Then, we have variables “collisionX” and “yTop” (forgive my bad naming conventions).

collisionX is the horizontal position where we will be checking for collisions. If the slope is facing right (slopeDirection == 1), we know the collision will only happen with the player’s bottom-right corner. When the slope is facing left, it happens with the bottom-left corner. We set this variable based on the slope’s direction.

yTop is the slope’s topmost position where collisionX is. This image explains it better:

Then we do a second check to determine if the player is intersecting an AABB where the topmost position is yTop. Since yTop changes when collisionX changes, this AABB’s height will change too.

This is important: While collisions with square tiles are detected and resolved on both passes, collisions with slopes are detected and resolved only on the second (vertical) pass!

Resolving the collision

OK, we know when the player’s inside the slope, but how do we make him react to it?


We set the player’s topmost vertical position to yTop minus his height. This pushes the player up to the point where his feet is barely touching the slope.

Now the player reacts correctly to slopes, but we have a problem:

The “Heel/Toe Stand”

This one is particulary infuriating. Take a look:

What’s happening here is that since the player’s hitbox is rectangle-shaped, it stands on slopes with only one corner, leaving the player’s feet floating. Hitboxes shown below.

I fixed this by making a special slope-only collision “box” for the player. The word “box” is between quotes because it’s actually a line, not a box:

Now the player collides with square tiles using the green box and collides with slopes using the blue line. This ensures his feet are centered on the slope.

To achieve this we change the slope detection code to this:

Now “collisionX” is set to the center of the player’s collision box regardless of the slope’s direction, and instead of detecting intersections using the player’s box, we check intersections using the player’s line, with “collisionX”.

At this moment i thought i fixed it. Unfortunately i was wrong.

Inside-ground collision

Since the player collides with slopes using the blue line, some part of the green box remains inside the ground, and upon walking up this slope, that green part inside the ground collides with the side of A, preventing the player to walk up the slope.


This is a tile-based environment, so when loading the level, i disable collision with the left side of all the tiles that have a slope to it’s left, and disable collision with the right side of all that have a slope to it’s right.

Other problems arised.

“Falling” off a slope

I thought everything was fixed and working, until i tried descending a slope. This happened:

Instead of smoothly descending the slope, i fell off it.

The fix was rather complicated, but worth it.

The player has a boolean “onGround”, determining if he is “grounded” and able to jump. This is set everytime the player collides with something on the vertical pass and his vertical speed is greater than zero (meaning he’s falling).

The slopes were only detected on the vertical pass, but I changed that and made the slope’s horizontal pass set a boolean called “descendingSlope” if the player is “grounded” and colliding with an enlarged version of it’s bounding box:

Notice I set “descendingSlope” to true if

  • It’s the horizontal pass
  • The player is “grounded”
  • The player is colliding with an enlarged version of it’s bounding box

What does this boolean do then?

On the update loop that runs every frame, if this boolean is set and if the player’s vertical speed is greater or equal to zero (means he’s falling), the player’s vertical speed will be set to same value as the horizontal, meaning the player will move downwards and horizontally with the same speed, making him move in a 45º angle and “stick” to the slope.

This variable needs to be reset to ‘false’ every frame after checking it!

Why do we check if the player is falling before “sticking” him to the slope?

If we don’t perform this check, the player will stick to the slope even when he’s going up, meaning he can’t jump off the slope.

Also, have you noticed that “descendingSlope” is only set to true in the detection code when the player is “grounded”? This is because we don’t want the player sticking to the slope before he even touches it.

Wait, what? More problems?

The “Ultimate Heel/Toe Stand”

You thought we already squished this bug. You were wrong.

The blue line should be touching the slope, but it isn’t, because the player is heel/toe standing on the square tile on the side of the slope.

Fix: Disable collision with all square tiles if the player is inside a slope’s bounding box.

If the player is inside a slope’s bounding box, we set a (yet another) boolean called “onSlope”.

This boolean is reset to 'false’ every frame along with “descendingSlope” and “onGround”.

Now that we have this boolean, we can disable collision with square tiles if it’s set. Slopes and squares must be checked separately though: all slopes must be checked, then all the squares must be checked, but only if onSlope == false.

Now for the final touch:

Resultant speed on slopes

If slope collision resolving only changes the player’s y position and speed, it means the horizontal speed stays intact. And if he’s going up or down at the same time his horizontal speed stays the same, it means his resultant speed is greater when on slopes than when on ground.

There’s an easy fix on the update loop though:

Before “maxSpeed” is changed, it represents the maximum horizontal speed he can achieve on a flat ground. If the player is on a slope and he’s grounded, we change that so that he doesn’t go faster on a slope than on ground.

We basically want the maximum resultant speed when on slopes (diagonal) to be equal to “maxSpeed”. But since “maxSpeed” is only horizontal, we need to find the horizontal component of this diagonal vector.

We need to find 'x’.

x*x + x*x = maxSpeed*maxSpeed
(x*x)2 = maxSpeed*maxSpeed
*x = (maxSpeed*maxSpeed)/2.0
x = sqrt((maxSpeed*maxSpeed)/2.0)
x = maxSpeed/sqrt(2.0)
x = maxSpeed*(1.0/sqrt(2.0))

Now the player runs on slopes with the same speed as when on ground.

This took about 2 hours to type, so reblogs are appreciated. I hope i helped someone with this huge post.

Also, would you like more technical posts like this, or only gameplay/progress posts from now on?

Status Report - Week of 10 Nov 14

Now that 0.50 has rolled out to stable branch, the focus of the team shifts to the incremental roll out of 0.51 for November’s monthly stable branch update. As with any monthly stable branch update, this comes with several new features, functional changes to existing systems, and its own unique collection of bugs and general game play issues. Those who encounter any frustrating blockers to their gameplay experience on either stable or experimental branch are encouraged to utilize the DayZ feedback tracker at

Looking towards the 0.51 update and the Christmas break, in addition to the obvious feature and functional goals - Server side performance is paramount. Addressing critical issues and blockers in releasing 0.50 on schedule has resulted in reduced server performance and with our end of year feature/functional goals coming up the programming team is focused on ensuring a smooth and solid server side frame rate. Experimental/Unstable servers will be used to profile and test 0.51’s performance throughout the month, so if you are looking to participate in this stress testing - make sure to opt into Experimental branch!

On experimental branch this week we’ve pushed out several new security related hotfixes, as well as pushing BattlEye’s upcoming changes. As always with security, working in tandem with our external partners (BattlEye and VAC) as well as observing exploits and behavior on experimental and stable branch servers allow us to iterate, and address via experimental > stable branch update paths.

It is important again to understand that during the Early Access Alpha period of DayZ’s development vulnerabilities will be introduced as the engine and systems surrounding it are created. Addressing these vulnerabilities and iterating via the experimental > stable branch update path is a constant tug of war. Through utilizing the DayZ feedback tracker to properly report valid information and issues encountered surrounding these areas, we can more quickly “patch the holes”

This Friday (the 14th) we had the first of our “dev play sessions” on experimental branch and the footage captured during this stream will be edited and commentated over in next weeks “dev experimental branch discussion” video to be released in next weeks Status Report. It is our hopes that combining general developer experimental branch gameplay with a “directors style commentary” alternating weekly will allow both the light hearted side of seeing the team play and experiment with systems in development, and the more serious gameplay and design oriented development discussion that the dev experimental branch discussion videos will allow.

This paired with the upcoming restructuring of the Dev Hub, as well as moving the Status Reports to Fridays and rolling out “Update Notes” for Wednesday experimental branch releases (via the dev hub) will be the first step towards increasing community/developer interaction moving forward into 2015.

Don’t forget about our private shard contest, announced during last weeks Status Report. Submissions are still being accepted!  - Brian Hicks / Lead Producer

Peter / Lead Game Designer
“Not much has changed since the last status report update on our front. Vehicle implementation is still flagged with the highest priority. There are of course some issues down the road which needs to be tackled to some extent so it can be considered ready to go for public testing. We advanced a bit as we were passed the vehicle physics parameters in configuration to set up car behavior correctly which is not an easy task and can take countless hours of tweaking and balancing to get the feeling right and believable. For example we already had iteration where our beloved “V3S” was acting like a boat or was falling on its sides while steering.

At Thursday and Friday we had a visit from part of the Bratislava team here to talk about features and design. It was nice to have them there and discuss things in details - like animals, cooking and horticulture. In meantime we’ve added MP-133 with pistol grips and fixed walkie talkies. We also added one more way to gather meat. Apart from that there are some new issues with restraining and struggling which we are taking the care of now. We are also revisiting the way how the suicide was supposed to be working and if everything goes fine it will be seamlessly integrated into the gameplay at the end.

Come get some… see you in Chernarus folks!”

Chris / Lead Artist

“This week, I’ve been working closely with Peter regarding design of the V3S and will be working on a high quality interior of the V3S with functional gauges. The initial implementation of the V3S will have some placeholder interior as the high quality version is being created.

We have also finished the prison uniform and are closing in on finishing the prison complex, which will be an interesting area to explore. We plan to also create prison-themed zombies which you will have to face if you want to explore the facility.

The Steyr AUG model is done and we will soon send it for animations, cfg, and sounds. I am optimistic that it can be in for next stable release but its worth saying that it will be the base version only. We are looking into swapping barrels to convert from the standard AUG to an HBAR version.

The military tent is also finished. I expect it will be found in next stable release.”

Standup Notes for the week of 10 Nov 14
(Note: Standup notes are not a change log - they are a quick high level look at tasks the teams worked on throughout this week)

• Prison Complex
• High fidelity V3S instrument panel
• Steyr AUG
• Prison-themed zombies

• Mp133 Pistol Grip Reload Animation done
• Player Suicide Animations in Progress
• Vehicle animations
• Throwing in crouch and prone
• Animation changes for new controls
• Zombies with new AI
• Vehicles

• Configs and scripts for new items (V3S Praga, MP-133 with pistol grips)
• Fixing restrain/struggling
• Fixing walkie talkies
• Fixing suicide
• Vehicles
• Horticulture
• Cooking
• Damage system

• Critical inventory fixes
• Vehicle settings for physical simulations
• New gamecontrols
• Loot distribution improvements
• Zombie/Animal AI
• Player connection issues (possibility of attacking players before they can play)
• Character duplication fixes