Advertisement Jump to content
  • Advertisement
  • entries
  • comments
  • views

About this blog

Development Diary

Entries in this blog


Nearly done with the Re Write

To begin with, I accidently erased the folder that had my project files, as well as the website, and from the server as well. But is ok now. So I have been re writing the re write. But anyway. The latest version is on newly worked website at Two new features of the site is that previous builds are available, and also, it has pages for the design notes and artwork. I still am working on the site.

On the game, everything I had before has been redone, and a bit more as well. The settings and developer menu work. However there aren't any options for the Web version. In the Mobile version, The Virtual Joystick can be switch between Fixed, Dynamic and Adaptive versions. On the Desktop, under graphics, the window size can be changes between 1x, 2x, and 3x, and also, the game can be set to fullscreen. On the Developer Menu, the Dev Lines can be turn on or off. Right now, it shows some of the input variables and some other ones that I was using at the time. One nice one is perspective. It toggles between Isometric and Cartesian. The game is ultimately and Isometric game, but under the hood, it works on a Cartesian grid. It is helpful to switch between perspectives to see how movement and collision works.

On this release, I finished the animation system, and one thing I wanted to do is to show a character. So the Character is Yol. He is a playable character in the game. I will put more info on him on the design and artwork pages on the site. Thou one thing, I forgot his tail. Going forward, I will start placing one new character in each build.

To end the 005 series on the rewrite, I just need to tidy up the code, and then I can start in working in new milestones. The next one would be NPCs, so that I can put characters in future builds.




Update 005.2 Pause, Menu and Perspective.

The Alpha 005.1 update is up at as well on the Windows Phone Store . This release dealt with the Menu and Pause, as well as the Isometric Perspective. And I spent more time on this release than I should have. As I write this, there are only four days 'till GDC Expo 15, and what I have is not impressive at all.

First off, some rewrites from the last update. The Input model is now its own object, so instead of typing Control.input_horizontal_previous it now is input.horizontal_previous. Also Control has been renamed to game, and so where other variables renamed, especially if they ended in _state. Additionally, I added the _held variables to the face buttons, and they count how steps has the button been held for. And lastly, I omitted last time on describing the pointer model, which is similar to the keyboard, gamepad and touch control types, but not quite.

The pointer model is active when the control_state, now just control, is keyboard or touch. This is because on keyboard, the mouse is accessible, and can be used to navigate menus as well as with the keyboard. On Touch, it is awkward to navigate menus with a virtual joystick when the menu item can just be tapped. On keyboard, the pointer is the mouse, and on touch is the first touchpoint. The pointer model keeps track of the current and previous x and y values, as well if the pointer is clicked, previous, pressed, released, and held. On keyboard, the x and y can change whether the pointer is clicked or not, while in touch, it can only change when it is being clicked. This is all working on the previous release, save for _held which was added on this release, but I omitted it because nothing used it, since menus weren't in the previous release.

But before talking about menus, just a quick explanation on Isometric Projection, since it is simple. Anything that need to draw in Isometric, check if game.perspective==perspective_type.isometric, if so, it draws the isometric sprite of itself at iso_x(x,y) and iso_y(x,y). Those are scripts. Iso_x returns argument0-argument1, and iso_y returns (argument0+argument1)/2. Additionally their depth is set to -iso_y(x,y). The Player also checks for the perspective, and if it is isometric, it subtracts 45 degrees to input.dir, so the Player movements in relation to the screen match the physical input, otherwise, the player would move diagonally in relation to the physical input instead. On the web version, the 'P' key switches between perspectives. I'll later add as a menu option. Speaking of which.

The Menu...
the menu...
the menu. I spent way too much time on this. But I like the end result, still. There is the parent pMenu that has all the navigation logic, and two children, mTitle and mSystem that provide the content and actions. Previously, it was one object that stored all the menus and changed depending of certain veriables. But then there was the settings submenu. It is present on both title and system menus and worked identical except when going back to their top menu. It was too convoluted to check which menu to back to. If I made an identical copy that could back to their proper top menu, I would have to keep them the same and all sort of bug would be waiting to happened. Going back to a top menu is contolled by which submenu is currently active. The quit submenu also suffered from this, but it only had to options, so I made a copy and called the new one exit. So the quit menu backed to the title menu and the exit to the pause menu. But the settings menu is much bigger than quit and exit. Also, quit and exit where a bit different, since exit went back from the game to title screen, and quit closed the game. The settings menu on both Title and Pause do the same thing, so it was going to be confusing. That's when I started experimenting with Inheritance.

The pMenu object has all the logic for navigating menus. It has the array menu[] that holds the menu items. The child fills it up with content. There is the variable menu_position that keeps track which menu item is active. On each step, it reads input.vertical_titled, and based on the that value and the current length of the menu[] array, it determines the value of menu_position. pMenu also has the pressed and back variables. Pressed is set to true if input.attack_released, input.pause_released or input.pointer_released are true. Back is set to true if input.jump_release or input.back_released are true. The children decide what to do with based on those varibles.

Drawing is also handled by pMenu. It stores the variables menu_x and menu_y to determine where to start drawing the menu, spacing for the spacing between buttons and size_x and size_y for the size of the buttons. There is also the label variable that is drawn on top of the menu. Previously, the menu was drawn based on the center of the screen, but now, I want to be able to position the menu more freely. Though I don't think I'll change it from what I have now, the code is more flexible. pMenu draw label on top of the menu. Then for each item on menu[], it draws a rectangle using the size_ variables, and then the string stored at menu. The colors depend if i==menu_position or not. On touch, if the pointer isn't being clicked, menu_position=-1.

The children fill the menu[] with whatever menu they have. There is script menu_goto(menu_type) which is used to change the menus. This script is called when back==true or when press==true. other things can be done when press==true. Right now, only the yes option on both quit menus and start on the title menu do something else than switch menus. And that is just about everything about menus, save for.
The pause menu. Pausing is easy, there is the variable game.pause, which can be set to true or false, and objects act upon it depending on the value. For the Player, the step event calls exit near the top if pause is true, so it doesn't do anything else on that step. mSystem, which is the pause menu, destroys itself if game.pause==false. But the pause menu wasn't working correctly. The menus used to have transitions, but the pause menu wasn't working correctly, so I deleted all that. And pressing and releasing the back button caused for the menu to show up and then it exited back out. And at one point, two menus were created. Previously, the Player controlled when the game would be paused, and mSystem controlled when it would be unpaused. Currently, the game object controls both pausing and unpausing, and it has the variable can_pause which both the Player and mSystem can change. This works, but it feels jimmy rigged. Once I put transitions back, it may how I intend for it to work, but till then.

And that is it so far. I spent too much time on this. I wanted for the Dev Menu to be functional. On the web version, like I had said before, pressing the 'P' key switches perspective. That would be a menu item. As well as the ability to turn on and of the dbug lines. Another new Dev feature was drawing crosslines at the x, y and iso_x,iso_y values of the object, depending of perspective. But because of all the problems with implementing the menu and pause, I postponed on making those features functional, I even took out transitions. Still, I found how useful scripts are.
When I started writing this, it was four days 'till GDC15 Expo. Now, as I am writing this line. I am waiting on the Greyhound Station, waiting to start heading to San Francisco. I took too much time in writing this as well. I hope I can get some time during GDC to add animations back. I am nearly finished animating a character that I could show of with the animation system as well. Still, I hope I have a blast at GDC.

Ps. As I publish this, I am ta GDC.




Update 005.1 - Controls ... Let the ReWrite Begin

As always, [font=arial][color=rgb(34,34,34)]the Alpha 005.1 update is up at [color=rgb(0,0,255)][/color][/color] as well on the Windows Phone Store. The 005 Series will focus on the ReWrite I am doing since I stopped working on the game for some weeks, and when I got back, had no idea where I left. The very first thing to tackle is the controls.[/font]
[font=arial][color=rgb(34,34,34)]The game is being targeted for Windows Phone, Windows 8, Web, and Plain old Windows. Each have different capabilities for input. Overall, it is a combination of three input types: Keyboard and Mouse, Gamepad, and MultiTouch. Instead of repeating code for each input, the game figures out which inputs are supported, filters the input into an internal model, and anything that need and input, reads it from the model. There are only two versions of the game published, Browser and Mobile and each one only supports one input, Keyboard and Touch. So, when the game starts, it figures out which platform it is reading and assigns a [/color][/font][font='courier new'][color=rgb(34,34,34)]control_type[/color][/font][font=arial][color=rgb(34,34,34)] to [/color][/font][font='courier new'][color=rgb(34,34,34)]control_state[/color][/font][font=arial][color=rgb(34,34,34)]. Love that Game Maker now has enums , now, if they had private, public .... Anyways, during the Step event, if statements controlled by [/color][/font][font='courier new'][color=rgb(34,34,34)]control_state[/color][/font][font=arial][color=rgb(34,34,34)] decide how the translation to the internal model is done. But first, since I will be using this internal model, let's call it input, since all the variables are prefixed with [/color][/font][font='courier new'][color=rgb(34,34,34)]input_[/color][/font][font=arial][color=rgb(34,34,34)], I have to keep track of previous, pressed, and released states, so there are variables for that. And before anything, all the values of the current variables are assigned to the previous variables. Next, I need to get the new values.[/color][/font]

[font=arial][color=rgb(34,34,34)]First, the input model is modeled after the Gamepad. Thus, I just read the values of the Gamepad, and assign them to input. Just one small translation. The Gamepad returns the horizontal and vertical axis for each Joystick. Right now, I only care about the Left Joystick. I find using the Direction and Magnitude more useful from a Joystick. So I translate the Horizontal and Vertical to Direction and Speed using arctan2 and the Pythagorean Formula. In total, I have the variables [/color][/font][font='courier new'][color=rgb(34,34,34)]input_attack input_jump input_pause input_back input_horizontal input_vertical[/color][/font][font=arial][color=rgb(34,34,34)], as well as [/color][/font][font='courier new'][color=rgb(34,34,34)]input_direction[/color][/font][font=arial][color=rgb(34,34,34)] and [/color][/font][font='courier new'][color=rgb(34,34,34)]input_speed[/color][/font][font=arial][color=rgb(34,34,34)]. Append [/color][/font][font='courier new'][color=rgb(34,34,34)]_previous _pressed[/color][/font][font=arial][color=rgb(34,34,34)] and [/color][/font][font='courier new'][color=rgb(34,34,34)]_released[/color][/font][font=arial][color=rgb(34,34,34)] for the rest of the input model.

Next is the Keyboard. For the face buttons, I just need to check if the key is pressed. For the arrow keys, a bit of math. The input model is expecting axis values, not keys. Thus, for each axis pair, each key is represented by a +1 or -1, I add the value of all keys in each pair that return true, and assign that value to [/color][/font][font='courier new'][color=rgb(34,34,34)]input_horizontal[/color][/font][font=arial][color=rgb(34,34,34)] and [/color][/font][font='courier new'][color=rgb(34,34,34)]input_vertical[/color][/font][font=arial][color=rgb(34,34,34)]. This has a nice effect of zeroing the value if both keys are pressed. Now, [/color][/font][font='courier new'][color=rgb(34,34,34)]input_direction[/color][/font][font=arial][color=rgb(34,34,34)] is found the same way, using arctan2. But for [/color][/font][font='courier new'][color=rgb(34,34,34)]input_speed[/color][/font][font=arial][color=rgb(34,34,34)], as long as [/color][/font][font='courier new'][color=rgb(34,34,34)]input_horizontal[/color][/font][font=arial][color=rgb(34,34,34)] or [/color][/font][font='courier new'][color=rgb(34,34,34)]input_vertical[/color][/font][font=arial][color=rgb(34,34,34)] have a non zero value, [/color][/font][font='courier new'][color=rgb(34,34,34)]input_speed[/color][/font][font=arial][color=rgb(34,34,34)] is 1, else it is 0. One additional thing, the keys that are checked are stored in variables, prefixed by [/color][/font][font='courier new'][color=rgb(34,34,34)]key_[/color][/font][font=arial][color=rgb(34,34,34)], for example [/color][/font][font='courier new'][color=rgb(34,34,34)]key_attack[/color][/font][font=arial][color=rgb(34,34,34)] or [/color][/font][font='courier new'][color=rgb(34,34,34)]key_up[/color][/font][font=arial][color=rgb(34,34,34)]. This will allow me to later provide a way to change the keys.

Last is Touch. This one is more complicated, because all there is for me to read is a pair of numbers, the [/color][/font][font='courier new'][color=rgb(34,34,34)]x[/color][/font][font=arial][color=rgb(34,34,34)] and [/color][/font][font='courier new'][color=rgb(34,34,34)]y[/color][/font][font=arial][color=rgb(34,34,34)] of the Touchpoint. From that I have to figure how to translate it into the input model. I first start by looping for each Touchpoint, using the temporary variable [/color][/font][font='courier new'][color=rgb(34,34,34)]i[/color][/font][font=arial][color=rgb(34,34,34)] for each Touchpoint ID. If the Touchpoint with ID [/color][/font][font='courier new'][color=rgb(34,34,34)]i[/color][/font][font=arial][color=rgb(34,34,34)] exist, I check whether it is on the left half or right half of the screen. The left side is used for the Virtual Joystick [/color][/font][font='courier new'][color=rgb(34,34,34)]vj_[/color][/font][font=arial][color=rgb(34,34,34)], and the right side is for the Virtual Button [/color][/font][font='courier new'][color=rgb(34,34,34)]vb_[/color][/font][font=arial][color=rgb(34,34,34)]. If the Touchpoint is on the left side, I check if [/color][/font][font='courier new'][color=rgb(34,34,34)]vj_id==-1[/color][/font][font=arial][color=rgb(34,34,34)], meaning unassigned, and if so, [/color][/font][font='courier new'][color=rgb(34,34,34)]vj_id=i[/color][/font][font=arial][color=rgb(34,34,34)]. The same with [/color][/font][font='courier new'][color=rgb(34,34,34)]vb_id[/color][/font][font=arial][color=rgb(34,34,34)] on the right side.[/color][/font]

[font=arial][color=rgb(34,34,34)]Let's deal with the easy one first, [/color][/font][font='courier new'][color=rgb(34,34,34)]vb_[/color][/font][font=arial][color=rgb(34,34,34)]. First, I check if [/color][/font][font='courier new'][color=rgb(34,34,34)]vb_id[/color][/font][font=arial][color=rgb(34,34,34)] still exist, if not [/color][/font][font='courier new'][color=rgb(34,34,34)]vb_id=-1[/color][/font][font=arial][color=rgb(34,34,34)], else [/color][/font][font='courier new'][color=rgb(34,34,34)]input_attack=true[/color][/font][font=arial][color=rgb(34,34,34)], and that is it. I do store [/color][/font][font='courier new'][color=rgb(34,34,34)]vb_x[/color][/font][font=arial][color=rgb(34,34,34)] and [/color][/font][font='courier new'][color=rgb(34,34,34)]vb_y[/color][/font][font=arial][color=rgb(34,34,34)] for future use, but that is all that works right now. The left is more difficult since it will model a Joystick. First, the same thing, if [/color][/font][font='courier new'][color=rgb(34,34,34)]vj_id[/color][/font][font=arial][color=rgb(34,34,34)] still exist or not. If it is not, [/color][/font][font='courier new'][color=rgb(34,34,34)]vb_id=-1[/color][/font][font=arial][color=rgb(34,34,34)]. Here is where it gets complicated. If [/color][/font][font='courier new'][color=rgb(34,34,34)]vj_id[/color][/font][font=arial][color=rgb(34,34,34)] exist, I check if [/color][/font][font='courier new'][color=rgb(34,34,34)]vj_origin=true[/color][/font][font=arial][color=rgb(34,34,34)]. If it doesn't, [/color][/font][font='courier new'][color=rgb(34,34,34)]vj_origin=true[/color][/font][font=arial][color=rgb(34,34,34)]. Additionally, [/color][/font][font='courier new'][color=rgb(34,34,34)]vj_origin_x[/color][/font][font=arial][color=rgb(34,34,34)] and [/color][/font][font='courier new'][color=rgb(34,34,34)]vj_origin_y[/color][/font][font=arial][color=rgb(34,34,34)] are stored as well. This is done on the first step [/color][/font][font='courier new'][color=rgb(34,34,34)]vj_id[/color][/font][font=arial][color=rgb(34,34,34)] exist. It represents the neutral position of the joystick. If [/color][/font][font='courier new'][color=rgb(34,34,34)]vj_origin==true[/color][/font][font=arial][color=rgb(34,34,34)], I skip this step. Next, as long as [/color][/font][font='courier new'][color=rgb(34,34,34)]vj_id[/color][/font][font=arial][color=rgb(34,34,34)] exist, I store its [/color][/font][font='courier new'][color=rgb(34,34,34)]x[/color][/font][font=arial][color=rgb(34,34,34)] and [/color][/font][font='courier new'][color=rgb(34,34,34)]y[/color][/font][font=arial][color=rgb(34,34,34)] position in [/color][/font][font='courier new'][color=rgb(34,34,34)]vj_x[/color][/font][font=arial][color=rgb(34,34,34)] and [/color][/font][font='courier new'][color=rgb(34,34,34)]vj_y[/color][/font][font=arial][color=rgb(34,34,34)]. Now I have two vectors, one for the origin, and the current Touchpoint. I then subtract the current from the origin and I get the same angle and distance the current and origin vectors have with the origin and vector (0,0). This vector is stored in the temporary variables [/color][/font][font='courier new'][color=rgb(34,34,34)]horiz[/color][/font][font=arial][color=rgb(34,34,34)] and [/color][/font][font='courier new'][color=rgb(34,34,34)]vert[/color][/font][font=arial][color=rgb(34,34,34)]. Each one is limited to be no greater than 60 and no less than -60, then I divide it by 60 to get value between -1 and 1. I assign this value to [/color][/font][font='courier new'][color=rgb(34,34,34)]input_horizontal[/color][/font][font=arial][color=rgb(34,34,34)] and [/color][/font][font='courier new'][color=rgb(34,34,34)]input_vertical[/color][/font][font=arial][color=rgb(34,34,34)]. Now, I can find [/color][/font][font='courier new'][color=rgb(34,34,34)]input_direction[/color][/font][font=arial][color=rgb(34,34,34)] and [/color][/font][font='courier new'][color=rgb(34,34,34)]input_speed [/color][/font][font=arial][color=rgb(34,34,34)]the same way as always. At this point, the Virtual Joystick is functional, but I wanted to try something extra.

On Microsoft Build 2014, the team behind Halo: Spartan Assault gave a talk on how they made it. At this point the game wasn't released yet. One thing they pointed out is how they handled the virtual joystick differently. They described it using words like glide and adaptive. Not having played it, I didn't knew what they were talking about. Then I played it. I bought it on launch day. Technically, I got it before it launched, but anyways. The virtual joysticks were intuitive. I don't play many mobile games, so I didn't knew what did Microsoft did different. I downloaded a few and tried their controls. The difference became clear.

To describe what they did, let me describe what other games did. It is all about how they handle the origin. In Sonic CD, the origin is fixed, thus the current Touchpoint will always have the same relation to the origin at the same place on the screen. One must place the current Touchpoint in relation to the fixed origin, let's call this one "Fixed". Next is Grand Theft Auto: San Andreas. In it, there is a defined area where the origin can exist, the lower left quadrant of the screen. The first place the Touchpoint exist is assigned to the origin. So, the relationship of the current Touchpoint is to that initial press. This one is "Dynamic". The Virtual Joystick acts similar to dynamic so far, but with the entire left side instead of just the lower half of that. On both Fixed and Dynamic, the origin never changes. While in Fixed, the origin is always at the same spot. On Dynamic, once the origin is created anywhere in the defined region, it stays there until the Touchpoint no longer exist. What Microsoft did with their "Adaptive" approach is that the origin changes, the origin is being dragged. On Fixed and Dynamic, the Touchpoint can end up far enough away from the origin that it no longer changes significantly the input, and may require long travels across the screen to make a significant change. On mine so far, if the player is more 60 pixels away from the origin, it no longer increases [/color][/font][font='courier new'][color=rgb(34,34,34)]input_speed[/color][/font][font=arial][color=rgb(34,34,34)]. In Adaptive, the Origin stays near the Touchpoint, so shorter travels are needed to make changes. But how does Adaptive decide where the origin should be?

The origin needs to move in a way that keep the same angle to the current Touchpoint as before and the distance should be no more than that of the effective range, which in here is 60 pixels. [/color][/font][font='courier new'][color=rgb(34,34,34)]horiz[/color][/font][font=arial][color=rgb(34,34,34)] and [/color][/font][font='courier new'][color=rgb(34,34,34)]vert[/color][/font][font=arial][color=rgb(34,34,34)] are a vector that is equal in angle and length as the current Touchpoint has to the origin. So the angle is right, but I need to shorten it. It needs to be no more than the effective range of 60px, but I can't just subtract that from the length. If [/color][/font][font='courier new'][color=rgb(34,34,34)]horiz[/color][/font][font=arial][color=rgb(34,34,34)] and [/color][/font][font='courier new'][color=rgb(34,34,34)]vert[/color][/font][font=arial][color=rgb(34,34,34)] are within the effective range, less than 60px, the origin would end up on the other side of the current Touchpoint. [/color][/font][font='courier new'][color=rgb(34,34,34)]input_horizontal[/color][/font][font=arial][color=rgb(34,34,34)] and [/color][/font][font='courier new'][color=rgb(34,34,34)]input_vertical[/color][/font][font=arial][color=rgb(34,34,34)] have the same angle but is only as long as the effective range, but 60 time smaller. So I just multiply it by 60 and subtract it from [/color][/font][font='courier new'][color=rgb(34,34,34)]horiz[/color][/font][font=arial][color=rgb(34,34,34)] and [/color][/font][font='courier new'][color=rgb(34,34,34)]vert[/color][/font][font=arial][color=rgb(34,34,34)] and apply this value to the origin. Now the origin will stay with the same angle, and no further than the effective range. This setup feels good to me, and it will be the default. But ill allow for it to be changed in future build, just in case others like the other options better.

Now that input has the current and previous values, I can check for pressed and releases. For pressed, I check if [/color][/font][font='courier new'][color=rgb(34,34,34)]_previous==false and current==true[/color][/font][font=arial][color=rgb(34,34,34)]. Releases are the opposite, [/color][/font][font='courier new'][color=rgb(34,34,34)]previous==true and current==false[/color][/font][font=arial][color=rgb(34,34,34)]. I could make [/color][/font][font='courier new'][color=rgb(34,34,34)]held[/color][/font][font=arial][color=rgb(34,34,34)] variables if [/color][/font][font='courier new'][color=rgb(34,34,34)]previous==true and current==true[/color][/font][font=arial][color=rgb(34,34,34)]. And maybe I will. So now, [/color][/font][font='courier new'][color=rgb(34,34,34)]input_[/color][/font][font=arial][color=rgb(34,34,34)] is up to date. Time to be used.

The Player object just moves and attack right now, so that's all I'll explain right now. First, it gets a copy [/color][/font][font='courier new'][color=rgb(34,34,34)]input_horizontal[/color][/font][font=arial][color=rgb(34,34,34)] and [/color][/font][font='courier new'][color=rgb(34,34,34)]input_vertical[/color][/font][font=arial][color=rgb(34,34,34)] so that it may use it. These are stored in [/color][/font][font='courier new'][color=rgb(34,34,34)]hspd [/color][/font][font=arial][color=rgb(34,34,34)]and [/color][/font][font='courier new'][color=rgb(34,34,34)]vspd[/color][/font][font=arial][color=rgb(34,34,34)]. These variable will eventually be applied to the Player's [/color][/font][font='courier new'][color=rgb(34,34,34)]x[/color][/font][font=arial][color=rgb(34,34,34)] and [/color][/font][font='courier new'][color=rgb(34,34,34)]y[/color][/font][font=arial][color=rgb(34,34,34)]. They can be applied right now, but the Player would move no more than a pixel each Step. Thus first thing first, multiply it by [/color][/font][font='courier new'][color=rgb(34,34,34)]mspd[/color][/font][font=arial][color=rgb(34,34,34)], Max Speed. Now we have the maximum potential movement the player can take, but what about walls? This is done by checking if at [/color][/font][font='courier new'][color=rgb(34,34,34)]x+hspd[/color][/font][font=arial][color=rgb(34,34,34)], the Player would collide with the object Wall. If so, [/color][/font][font='courier new'][color=rgb(34,34,34)]hspd=0[/color][/font][font=arial][color=rgb(34,34,34)]. But I still would like to move the Player as close as possible to the Wall. I get the sign of [/color][/font][font='courier new'][color=rgb(34,34,34)]hspd[/color][/font][font=arial][color=rgb(34,34,34)], whether it is positive or negative and move Player one pixel, positive or negative along [/color][/font][font='courier new'][color=rgb(34,34,34)]x[/color][/font][font=arial][color=rgb(34,34,34)], until I hit Wall. The same [/color][/font][font='courier new'][color=rgb(34,34,34)]vspd[/color][/font][font=arial][color=rgb(34,34,34)] and [/color][/font][font='courier new'][color=rgb(34,34,34)]y[/color][/font][font=arial][color=rgb(34,34,34)]. That is all the movement.

For Attack, if [/color][/font][font='courier new'][color=rgb(34,34,34)]input_attack_pressed==true[/color][/font][font=arial][color=rgb(34,34,34)] then it creates the Weapon object at the Player's [/color][/font][font='courier new'][color=rgb(34,34,34)]x[/color][/font][font=arial][color=rgb(34,34,34)] and [/color][/font][font='courier new'][color=rgb(34,34,34)]y[/color][/font][font=arial][color=rgb(34,34,34)]. Weapon then destroys itself when its animation ends. That is all. Finally, the directions. Because the game will be on isometric, I would need to know which of the 8 directions the player is facing. All I do is divide [/color][/font][font='courier new'][color=rgb(34,34,34)]input_direction[/color][/font][font=arial][color=rgb(34,34,34)] by 45 and I get a number from 0 to 7, one for each direction. This value is stored in [/color][/font][font='courier new'][color=rgb(34,34,34)]dir[/color][/font][font=arial][color=rgb(34,34,34)]. this variable is used to rotate the sprite of Player and Weapon.

One [/color][/font]unique part [font=arial][color=rgb(34,34,34)]is the back button for Windows Phone, Right now it is used to quit the game because it has to. Later it will bring a menu, alongside the rest of the platforms. But I couldn't read the back button in code. it is mapped the backspace, so I should have been able to read the state of the backspace key and assume it was the back button on Windows Phone, but I couldn't. So right now it uses Game Maker's built in event for the Backspace key and sets [/color][/font][font='courier new'][color=rgb(34,34,34)]input_back[/color][/font][font=arial][color=rgb(34,34,34)] to true. Then, only on windows phone, if [/color][/font][font='courier new'][color=rgb(34,34,34)]input_back==true[/color][/font][font=arial][color=rgb(34,34,34)] then [/color][/font][font='courier new'][color=rgb(34,34,34)]game_end()[/color][/font][font=arial][color=rgb(34,34,34)].

One last thing are the [/color][/font][font='courier new'][color=rgb(34,34,34)]dbug[/color][/font][font=arial][color=rgb(34,34,34)] lines on the right side of the screen. I use this to view variables in real time or other thing, like if a block of code is being executed, or how a variable changes as it is being modified. [/color][/font][font='courier new'][color=rgb(34,34,34)]dbug[/color][/font][font=arial][color=rgb(34,34,34)] is an array of 28 items. I can assign any value to any of its elements and it will show up on the right side of the screen. I usually disabled this before releasing each prior alpha, but decided to keep it on this time. Additionally, the first line shows the platform, the current version, and a color, coded to the platform. I am planning to uses this as an incentive for paid users while the game is in development, along with other things that will be part of a "Dev View". On prior releases, I was also able to switch perspectives between isometric and Cartesian. Right now there is nothing isometric yet on the rewrite. That will be part of Dev View as well. But then there is the web version which is always free. And it would be nice for the Dev View to be on the web version as well, but it may remove the incentive to purchase it while in development. Well, we'll see

This was long. But it covered everything that was done in alpha 0.5.1. It was very reflective. On writing this I realize some things that I could change to make it better. For the next release, I plan to put back menus, screens, animations and add a few additional control elements. And it is the first week of February. One month 'till GDC, and the short month on that. Let's see how far I get. Maybe I should have made this post into parts.[/color][/font]




Update 004 - Animation ... and some News

The Alpha 004 update is up at as well on the Windows Phone Store. Unfortunately, it was taken down from the Windows 8 Store because it isn't feature complete. Bummer. Additionally, this update has been up for a while, but my day job got in the way of doing anything for a while. Sooo.... first the animation, then the News

I really like how simple and elegant the animation system is. First, a state system. So far, the player can only do two things, Stand and Walk. More will be added later. the current state is stored in the variable [font='courier new']action_state[/font], and I use the enum [font='courier new']action_type [/font]to keep track of all the actions, currently only stand and walk. right now, based on the speed, the [font='courier new']action_state [/font]is determined. This will grow in complexity, but makes the next part easy, what sprite to draw?

Instead of relying on the currently drawn sprite to determine what the player can do next, I separated that into the state system. And I just assigned the sprite depending on what state it is on. if [font='courier new']action_state==action_type.stand { sprite_index=sprPlayerStand }; [/font]However, if only it were that easy. The game is Isometric, so I have to do more. I originally had planed for using different sprite on each direction, [font='courier new']sprPlayerUp[/font], [font='courier new']sprPlayerUpLeft[/font], and so on. but I was able to flex my Math Skills, and found and elegant solution.

First of, to correct a small lie, I store the sprite to be used in a temporary variable [font='courier new']ss, [/font]and not assigned it directly to [font='courier new']sprite_index[/font], since I will use some math on it before getting the final result. When trying to find a way to keep all the directions for the walk and stand sprite, I realize that it was divisible by 8. Since I was using 8 direction, no mater how long the animation was, it was repeated 8 times, once for each of the 8 directions. so each sub animation on each sprite was the full length divided by 8. Now I have the length of the animation ,stored in the temporary variable [font='courier new']ll[/font], but where do I start it from? The [font='courier new']dir [/font]variable stores the direction the player is facing, but from 0 to 7, or [font='courier new']dir=Control.input_direction / 45;[/font] so [font='courier new']dir * ll [/font]gets me the start of the animation, but what about the current frame? Well, keep track of it with the variable [font='courier new']sindex[/font]. Each step add the variable [font='courier new']sspd[/font], for sprite speed, and if its grater than [font='courier new']ll[/font], set it back to 0. so I add the number to where my sub animation starts and I get the image to draw, stored in the temporary variable [font='courier new']v[/font].

Long explanation short, if I arrange my sprite with all direction next to each other with Right being the first one, and going clockwise, and do all the math above to find which image of which sub animation to use, the sprites will animate properly and face the right direction. DONE

Now for the news, some bad, some good. The Bad one, because of the long hiatus, I don't know where in the project I am. with variable names like [font='courier new']ss[/font], [font='courier new']ll [/font]and [font='courier new']v[/font], and minimum comments, it is easy to get lost. So I will be rebuilding everything from scratch. I'll try to document everything as much as possible. So it will be a even longer while before a new update is up. on the Good news, I'll will be going to GDC expo this year, hopefully I'll have finished the rebuilding, and added more stuff by the time I go. have about a Month to do that, so I'd best get started




Update 003 - Pause and Menu

The latest update is up at as well on the Windows Phone Store and Windows 8 Store. This is a small update. It deals with pause and menus.

The Pause function is from YouTube tutorial by Shaun Spalding The only difference is that instead of using global.pause, I have Control object that has the pause variable, thus Control.is_paused. Other than that it is identical. I may have some problems when I start having animation, but I'll deal with it when I get to that. And as a side note, the collision system is derived from his plataformer tutorial. That guy has nice tutorials, and I think I'll use a couple more in the future.

The menu on the other hand, I dealt with it myself. The menu itself is stored in a 3x3 array, three buttons, three properties. Text, is_active, and haven't decided yet. I may delete the last property. When drawing, the menu checks if Control.control_type==2 for touch screens. If true, it will draw all three buttons, a rectangle and text, with the same colors, else, if title_menu[i,1]==false, they are drawn with muted colors.

When acting on input, if it is on a touch screen, when the touch point with id==0 exist, it goes on a for loop, checking if the touch point is inside each rectangle. If it finds that it is, if i==0, the start game button, it goes to the test room. Nothing happens for the rest of the buttons, yet.

If Control.control_type!=2, that is keyboard or game pad, it finds and stores the active_button. If Enter or Start are pressed, if active==0, it goes to the test room. Now, for selecting the other options, it reads whether Control.vertical_control is greater than or less than 0. Vertical_control is between -1 and 1, and it is determined by the up/down keys, the vertical axis of the left stick on a game pad, and also the vertical axis of the virtual joystick. If the menu didn't check for control_type, the virtual joystick could be used for menu selection as well. Once the menu has determined the direction by whether vertical_control is > or
I really like how this is turning up to be, it still has flaws, but the overall idea is holding up. I really like this milestone style of development, it gives me a reachable short term goal to achieve. And determining the next milestone to tackle is also fun. Additionally, seeing the milestone that lie further ahead, that I really want to tackle, gives me motivation to continue. For example, for touch devices, the right side is unused at the moment. I really want to set up the controls that go there. But first, moving on the z axis, crossing floors, going thru stairs and ladders, indoors and out, that is the next milestone. This one will be hard, at least two weeks. Likely more. So next week's update will be for the website. I already got the new feature working, just need to pretty it up a bit.




Update 002 - Indoor and Outdoors

The next update is up on, Windows Phone, and now, Windows 8. This update deals with what I think is a crucial aspect in style for the game, going indoors and outdoors without control and/or visual interruption. In most games, let's take Zelda as an example, when the Character goes Indoors or Outdoors, or basically across a door, the Character no longer responds to input, and an transitional animation plays. Once the animation ends, the Character once again responds to Player Input. Additionally, what goes on across the door has no impact on what goes on the other side of it. Now, we all are accustomed to that. We may not even think about it, or actually exploit it, intentionally crossing a door to get a break from the action that is on the other side. This last one breaks emersion for me. The Enemies are basically waiting on the other side, not going after you. Now, some of this may be technical limitations. The simple loading of rooms, and using the animation to hide the loading, being that in Twilight Princess, going across a door took longer than in Wind Waker, or maybe the animation wasn't long enough. The same may be true for old Zelda games as well. For today, however, it is more of a stylistic choice for games that mimic older games, or even modern games that are not to taxing on the system. Take Minecraft, it is a very large open world that has no transition across the doors. The action of one side of a door can spill to the other side. Not breaking immersion. And I want to see if I could apply something like that to a Zelda style game.

What I have done is simply create two doormat objects. Place one inside the door, when the player is definitely Indoors, and another one outside the door, when the player is definitely outdoors. They both trigger a Boolean is_outdoors in the Control object when the Player collides with them. The wall object have the variable in_room. The value is 0 by default, but anything else if it is to be the indoors of a room. When Control.is_outdoors==True, all Wall objects win a in_room value of 0 are drawn, as well as the Roof, and Indoor Objects. If Control.is_outdoors==False, then the Wall objects whose in_room==Control.in_room are drawn, along with the Floor object. The Control.in_room is set by the Indoor object. Additionally, since the Player can now be obstructed from view, the Player draws itself with very low alpha after everything else has been drawn. So a "shadow" appears on top of everything, like Mario Sunshine.

This feature isn't done yet, for the most complicated part is yet to come, going upstairs, and downstairs. But before that, I'll work on the pause function. It is simple, and needs to be done anyway. Plus I can add controls to test various values and implementation to help fine tune the game. Like whether Static, Dynamic, or Gliding virtual joystick would be the best default implementation, or to just pick one from the three. The next update shouldn't be long, but the following one will.




Update 001 - Isometric Perspective

The Next Update is live at the Windows Phone App Store and It simply draws everything in an Isometric Perspective. It additionally tweaks the directional input to offset the player direction by 45 degrees. Good news also arrived from Yoyo Games and M$ announcing a partnership which in addition to improving their support on M$ platforms, will allow GameMaker to deploy to an Xbox One. Now, ID@Xbox needs to open up to inexperienced devs and I'll be set. In their announcement, Yoyo Games mentions that it will be up and ready by the fourth quarter. So I want to see how far I get with Chronicle Destiny before Game Maker can export to Xbox One.

But about the update. In the previous build, the presentation is top down. All movement and collisions are calculated like that. The latest update draws each object in a new location and with a different sprite. The new draw location is calculated as follows:



All the walls run this when they are created. the player runs it every step, and so far, it works. This allows me to calculate everything in a plain cartesian grid, where everything is more intuitive, and draw everything in isometric. I just need to make sure the Isometric Sprite makes sense with the Collision Sprite. And because the new angled view, going up in the controls sends the player up-right. Thus I just tweaked it simply by offsetting the direction by 45 degrees.

And that is all about this update. Right now it just basic stuff, so the updates may be done in rapid iteration. But later updates may take more time, especially one I add and polish the artwork. And about the artwork, there is a link on the left in the page that shows artwork I have done for the game. I have recently finished making concept artwork for the population of the town the first story starts. The setting for the first story take place in a town and a nearby farm. I have basically done concepts for half the NPC. Next, I'll work on concepts for the NPC on the farm. The artwork is hosted on Deviant art, and I have embedded their slideshow to show of the artwork. Additionally, the homepage right now has a sketchfab hosted 3d model that I'll use to build 3d models, which I'll use to make the 2d sprites. Eventually I'll have dedicated page just like I have for the artwork, but for now, it is on the homepage.

I guess that is all the relevant stuff. I hope I can keep up with the updates. I plan to add more representative artwork on the next release, and a feature that is critical for gameplay. Which I'll talk about in the next update. Now to clean my room.




Chronicle Destiny Live at the Windows Phone store

Kind of. Its basically a blue circle that is controllable by a virtual joystick, and some red block on a green gird background using a top view perspective. It basically is a base for a Zelda game. The same game can be viewed at, save for keyboard controls instead of touch controls. But why publish, and charge $0.99 for, what amounts to a finished tutorial project? Well, to make some money. One can download the trial version and ads will show up, by purchasing it, the ads go away. So I can make money either way. It is basically a jimmy rigged kick starter. But also as a motivational tool. Having something out there in people hands can give one and extra push to continue to work on it.

Thou it still is not nothing. The virtual joystick was a pain to do. Mainly because I was unable to find any info on gliding joysticks. All info I found was on static and dynamic joysticks. Static joystick have a fixed origin on screen and the joystick "tilt" is determined by measuring a touch point in relation to the fixed origin. Simple, but it feels awkward to me. In Dynamic, the origin is determined by the first time the screen is touched, and the tilt is determined as one drags the touch point around the origin. But it still has some awkwardness. This is, I think, because the origin doesn't change while using the joystick. There is no physical limits on a virtual joystick, unlike a joystick on a gamepad that it is mimicking. So, the touch point can end up far from the origin, which when changing direction, one has to travel a long distance to reach the desired new direction, or to release and touch again, which may cause the player to stop.

The gliding joystick drags the origin if the touch point is far enough. Thus when changing direction, the origin is close by, so travel distance to change direction is not much. It does introduce new problems, but I think that, so far, are acceptable. In future builds, when pause and menu are implemented, I'll add a setting to switch between the three so I can get more feedback, but I think Gliding is the best overall, and it will be the default. I think the reason there is a lack of info for the gliding joystick may be because I have only seen it in one game, Halo: Spartan Assault, and I call it "Gliding" because the devs mentioned that their solution for twin stick gameplay addresses the gliding the finger does. I don't know if "Gliding" is the proper term, and that could be why I couldn't find anything. Additionally, it isn't evident that the origin is being dragged in Spartan Assault. After, building the joystick using the dynamic style, I figured that changing the origin may mimic what halo does, and it did.

So at the very least, I can show off the gliding joystick. The web version uses keyboard, and the pc version also supports the gamepad. Both are straight forward, easy to implement, nothing to special. But the gliding joystick couldn't be show cased on the web. So putting the phone version up can help me get feedback on something that was truly hard to make. However, if I did a good job, no one will notice. Hope people download the game and give me feedback so I can make this game the best I can deliver The store page is And by the way, the trial and web version will only have one level available. The paid version will have three more, and the price will be higher for the final release, maybe $5. So get it while it's cheap




Website is Functionally finished

[font=arial]EDIT: By popular demand, I split it into paragraphs, and proofread it to. Will do the same for future posts.

GDC was an Awesome experience. It brought me hope that what I was doing was possible and worthwhile. Just seeing the one man show of "Papers, Please" take a lot of awards was motivational by itself, but also talking to the various booths at the expo, and with a focus for this post, Facebook.

While it was just a short talk, where the Facebook representative just ended up telling me to look at their developer site, just talking about my idea gave me the motivation to do it. While half of my idea had already been implemented, posting every Milestone "Alpha" build, it was missing the second half, the ability to comment. Now it has it. [color=rgb(5,99,193)][/color] is now the page to all the alpha builds.

Thou because of the way Game Maker exports to HTML5 and wanting to keep some elegance in my code, I had to redo what I had. So while I was up to Alpha 004, now I am down to Alpha 001. It is just my finicky self that I will be redoing all four alphas, 'cause I could just have exported the game as it was and called it Alpha 001, or get the code to work with the old exports.

Still, the main thing here are the comments. I added Facebook comments to each alpha build, so now people can comment on them, which is the entire point of showing each alpha build. Implementing it was a bit tricky, since I want a single page to load up the alpha, instead of each alpha having its own page. While at first glance, it looks like one can only have one Facebook Comment box per page, I soon found out that adding a # followed by whatever, one can place multiple comment boxes on a single page. on my page, it loads up the appropriate comment box with the alpha. The alpha itself is chosen server side base on the URL. the link above right now give you a list of current build, and by clicking on one, it will append /BuildNumber to the URL, Chronicle/Alpha/000 will load up Alpha 000, and Chronicle/Alpha/001 will put Alpha 001, and so on. Right now, the /Alpha page gives the list of current alphas, but in the future, it will load up the most recent alpha, with a drop down menu somewhere to choose previous alphas.

Anyways, right now, /Alpha can load up the alphas, with its proper Facebook Comments Box, and that is core functionality that I want. I will continue to refine the site, and make the code more elegant, but I'll shift my focus back to the game, rebuild the other 3 alphas, and publish Alpha 005. And for the curious, the site is hosted on Microsoft Azure, it is being developed in WebMatrix, and the server-side code is Razor, and other than the code added by Facebook Comments, Game Maker, and Unity3d, everything so far is written by me. Was thinking of using WordPress or Orchard, but couldn't figure how to make this core functionality work.[/font]





I really could get time off this past two week to work on Chronicle Destiny. So, right now as I am standing, waiting for GDC Expo to start, I whip out something Quick. just replaced the generic playable character with the close to actual playable character. nothing else has changed. so just go to and see who the main character is. other than that. I am here at GDC Expo :D looking around, and posting stuff at my twitter and facebook. Lets see were this goes.




Chronicle Update 04

Has it been a Year? or a Month? Nope. It has been a week . Hope I can keep this up. But anyways, the latest update is up at . not much, thou the point of posting as frequent as possible is to get as much feedback as early as possible, so that it is easier to change. Like last update, a comment ( yay comment ) asked if the blue blocks were buildings. while it is quite early in development, and I am using more abstract placeholders, it was a bit confusing to just show 2 lines of blocks forming a corner with an opening on at least one of them and come to the conclusion that it is a room. so I decided on how to display the walls. While still crude and unfinished, it does show that they are rooms better, and it help me figure out how to draw distinct parts of a wall. still highly abstract thou. Now I will focus on showing different levels on the building, like a second floor, roof or basement, which also means stairs and ladders. lets see how much I can finish in a week. Plus, 2 weeks 'till GDC




Chronicle Update 02

It's been a week, right? Since August of 2013? Well, best really, really, really late than never. alpha 002 is up at I have dropped doing my site for now, and just work on Chronicle Destiny. Specially since I will be heading to GDC Expo at San Francisco this year. And I want something to show of to people I meet there. not much to write about other than I haven't forgotten about this journal, nor about working on my game. Plus I can't write much now 'cause I am at my 30 min break. Hope I meet interesting people at GDC. And hope I meet people interested in my project at GDC




lets start this over, again

Well, bunch of things happened that didn't allow me to continue on my game. I think it is over now, I have I nice stable job flipping burgers now, so I can now use my spare time to continue my game. and other stuff happened that prevented me from using what I already had, being that XNA has been abandoned. none of M$ new platforms uses XNA, WP8 does use it as legacy, but it isn't encouraged to use it. So, now what? Game Maker Studio. I originally started using Game Maker, and switched to XNA when I decided to make it 3d. but now, I am switching back to Game Maker and 2d isometric. Crystal Destiny will still be in 3d, using Unity, but for game maker, I decided to make a smaller game, still in the same world as crystal destiny, but smaller. Chronicle Destiny is the new game I am working on. it will include mechanics from Crystal Destiny, but tailored for 2d. Chronicle Destiny is just a series of short stories, each taking place in a small region, like a town, farm, city streets, fortress. each story will be with a different character, unrelated to each other, an the stories wont take more than an hour to play thru, may be even 30 min. Game Maker can publish to Win8, WP8, Windows, and HTML which I will use, similar to what XNA offered. Hopefully it will also support Xbox One down the road, but I am good for now. here is a link to the first alpha. I am aiming for a Zelda-esq style of gameplay. eventually I'll add isometric graphics, but ill work the gameplay like this first. while I think it is a bit to early in development to see the direction it is going, feel free to give suggestions. and that's about it. I am really exited on using Game Maker again. I had done a Zelda engine before ( was trying to make Ocarina of time, Gameboy Style. had done the Kokiri forest and Deku Tree when I stopped a long time ago). will be posting the HTML 5 version on my site every week, I hope.




Let it begin

this past summer I have been busy on learning programming, web technologies and working on artwork. and I got an interesting idea, Silverlight 5 uses XNA for its 3d features. so I have set up a my website to post the Silverlight build for anyone to test. my website is hope this idea works




One More Week

One more week and I am off for the summer. and I will renew my coding and keep at it during the summer. I am going to pump out more content than what I have done so far. and since I cant pay my webhost, is down. but I got another blog at I am trying to mimic what the guys at and their open development concept. but right now my time is consumed on finals, but next week... Can't wait




Prepping for Summer

I will be off for the summer in two weeks. right now, i am doing some artwork, experimental artwork. i have one character from each race and made a model, which i think would be close to the final version. There are 25 races total, and i have done 12 sofar.
and i hope i get to the last 13 by the end of these 2 weeks, cause aftewards, i'll pick up the code for the summer, and i wont touch the art until i implement bone animation. i have touch the the code a bit, but i is just small. the few thing that i have, is running on Win7, WinPhone7 and Xbox360, and just added text that shows which plataform it is running on, but the bulk of the coding will be done this summer. i cant wait for it to start.




Switching Gears

While I will still work on the code, I will emphasize my time more on the art side for a while. I use Blender and GIMP, I have been working on a generic Model, as low poly as possible but with the highest amount of detail possible, two opposing concepts, and I think I archived that goal
This are the Main characters, each representing a Race in the game. There are actually 12 races, and here I show six of them. While I do think 12 races might be a bit too much, it makes sense in the game world. These however are not the final models. This are close to the Windows/ Xbox goal, and WP7 will get Lower poly versions. Hope I can pull it off.




Not dead, but havent done much either.

Hopefully, i can keep this up, but some days after the last update, some past month ago, i had to deal with school. i think i am clear now, so here is the second update the was due some month ago.

it is actually new code, cause i tend not to comment my code, so i forgot what i was doing. i know i was working on game state managment but i simply couldn't pick up were i left of. ill leave that of for now, but i added the movement. which i based of legend of zelda, twilight princes. i also started the wp7 version, and the xbox too(since it is the same as the pc version). ill dedicate the weekends on this project and hopefully i can get thru a faster update cycle.




SoFar SoGud

Still working on my code. Nearly done with Milestone 2, to get the GameScreen management to work on PC and WP7. The problem is that on the PC (and Xbox), the menu navigation is done by the Gamepad or Keyboard. Moving up or down the MenuList, until the proper MenuItem is highlighted and them pressing a button to perform an action. In WP7 one just taps the MenuItem. While it works on the PC, it doesn't, yet, work on WP7. So I am working on that.
Now, if this is Milestone 2, what was Milestone 1? Well, it was displaying models in a structured manner. I made a video on YouTube.Here is the video.

Once I finish with Milestone 2, I'll make a video about it as well.
Since I mention YouTube, I should also mention other places in the net were I am at
Twitter [twitter]zBuLe[/twitter]
and my own site (still Working on it)
Any comments, concerns, questions, suggestions, complaints, requests or cream soda is appreciated.




Console vs Portable

One of the main goals is to release a core experience and a portable one. This is one of the reasons I chose to write it on XNA. I have always been fascinated how core games, like console and PC, translate into portable, and vice versa. while there are really no example of this, save for port of a console title into a future portable, like the PSONE library on PSP, or the Game64 released on the DS, there have always been hint on long running franchises. I mainly refer to the Zelda series. Their games cover both console and portable, and the portables are full experiences unto themselves. the Zelda series has created certain element that remain common, but it accommodates based on the platform it is in. not counting Zelda 2, the pre n64 games built upon each other naturally. When the n64 hit, they could have kept most of the gameplay intact by adding a fixed camera looking downward. But instead they added an orbit one, as a consequence, they added the targeting mechanic. But overall, most of the element carried over. The console games since then are again natural additions to Ocarina of time. The portables retained the same gameplay as the pre 64 games. Until the DS. For this platform they chose to go with the fixed camera, but it also gain element from the console counterparts. Like the swordplay, liming and lock-on. This was possible because of the touch screen. Then they released Ocarina of Time for the 3DS, the foundation for their console addition, the newest console game, Skyward Sword, relies heavily on the motion control, and if one think about it, it is conceptually similar to the DS titles, links actions depend on the gesture performed. The Legend of Zelda has come up with 2 distinct gameplay scenarios, the 2D scenario, in which the camera is fixed, link moves left/right up/down, and the world is divided into rectangles. Examples of this are games like Link to the Past, Links Awakening, Minish Cap, and Spirit Tracks. And the 3D scenario, with orbit camera, full 3D environment and movement, and heavy reliance on lock-on and context sensitive actions. Samples of these are Ocarina of Time, Twilight Princes and Skyward Sword.

Back to the point. It is not hard to imagine any Zelda Game on any of its Gameplay scenarios. Or more specifically, the 3d games in the 2d scenario, or vice versa. Playing Twilight Princess like Minish Cap, or Phantom Hourglass like Wind Waker. They both share so many common elements. The differences are mainly there because of the platform limitations. But as portables become more powerful, they will be able to handle console style games. Like the Game64 release.

So... I plan to make the same game, only differing on what the platform can support. The Game State Management sample is a good foundation, and it already runs on PC, Xbox and WP7. I decided to write the code myself so that I could learn what's going on. I now have to finish the menu and then, I can just worry about the gameplay. Good thing XNA allow me to separate which part of the code runs on pc, Xbox or wp7, or any combination, or all three.




Hello, World!

Welcome! This Diary will be use document the development of a game I have been dreaming of for some years now. I am the sole Programmer and Artist at BlueStar03 Studios, and janitor, receptionist and valet. I don't have much experience in neither field, but I think I have enough to start, and learn the rest as I continue. Today I will write the first lines of code that will became Crystal Destiny. It will be written in C#, leveraging on XNA. For the art, I'll use Blender and Gimp.

About me:
After graduating High School, I served in the US ARMY. I essentially was the IT for my unit. Afterwards, I enrolled at The Art Institute, studied media arts and animation, did not finish. Now I attend a community college, studying Computer Programming.

About Crystal Destiny
The First Ideas of what has ushered me here came to me around 2002, while playing Golden Sun. While I had already wanted to make games before that, I really liked the world of Golden Sun, I found a program called Game Maker, and I started making my game in it. Sometime after, I started to add more ideas from other games I liked, Zelda, GTA, Kingdom Hearts. Once I decided I wanted it to be in 3D, I decided to find another way. I found XNA when it first released, and the ability to play on the Xbox 360 is an awesome feature, but I couldn't program at that time. I looked at others solutions, but I always had an eye on XNA. I finally decided to learn C# so I could use XNA. Now I am decently versed in the language, got better in my artistic skills in the meantime as well. Crystal Destiny is the name I gave my game. It will be an open world, 3dperson action adventure RPG, targeted to run on Windows, Xbox360, and hopefully, Windows Phone 7 and Web. It is an ambitious first project, but my vision is clear, and I believe I can deliver it. In about 2 years. So better get started if I want to meet this deadline.

Any comments, concerns, questions, suggestions, complaints, requests or cream soda is [color=#222222]appreciated[/color].



  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!