Jump to content

  • Log In with Google      Sign In   
  • Create Account

BlueStar03



Nearly done with the Re Write

Posted by , 29 June 2015 - - - - - - · 2,696 views

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 http://bluestar03.com/Chronicle/Alpha. 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.

Posted by , in Chronicle Destiny 04 March 2015 - - - - - - · 578 views

The Alpha 005.1 update is up at http://bluestar03.com/Chronicle/Alpha 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[i]. 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

Posted by , in Chronicle Destiny 02 February 2015 - - - - - - · 211 views

As always, the Alpha 005.1 update is up at http://bluestar03.com/Chronicle/Alpha 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.
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 control_type to control_state. Love that Game Maker now has enums , now, if they had private, public .... Anyways, during the Step event, if statements controlled by control_state 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 input_, 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.

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 input_attack input_jump input_pause input_back input_horizontal input_vertical, as well as input_direction and input_speed. Append _previous _pressed and _released 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
input_horizontal and input_vertical. This has a nice effect of zeroing the value if both keys are pressed. Now, input_direction is found the same way, using arctan2. But for input_speed, as long as input_horizontal or input_vertical have a non zero value, input_speed is 1, else it is 0. One additional thing, the keys that are checked are stored in variables, prefixed by key_, for example key_attack or key_up. 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
x and y 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 i for each Touchpoint ID. If the Touchpoint with ID i 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 vj_, and the right side is for the Virtual Button vb_. If the Touchpoint is on the left side, I check if vj_id==-1, meaning unassigned, and if so, vj_id=i. The same with vb_id on the right side.


Let’s deal with the easy one first, vb_. First, I check if vb_id still exist, if not vb_id=-1, else input_attack=true, and that is it. I do store vb_x and vb_y 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 vj_id still exist or not. If it is not, vb_id=-1. Here is where it gets complicated. If vj_id exist, I check if vj_origin=true. If it doesn't, vj_origin=true. Additionally, vj_origin_x and vj_origin_y are stored as well. This is done on the first step vj_id exist. It represents the neutral position of the joystick. If vj_origin==true, I skip this step. Next, as long as vj_id exist, I store its x and y position in vj_x and vj_y. 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 horiz and vert. 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 input_horizontal and input_vertical. Now, I can find input_direction and input_speed 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
input_speed. 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.
horiz and vert 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 horiz and vert are within the effective range, less than 60px, the origin would end up on the other side of the current Touchpoint. input_horizontal and input_vertical 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 horiz and vert 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
_previous==false and current==true. Releases are the opposite, previous==true and current==false. I could make held variables if previous==true and current==true. And maybe I will. So now, input_ 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
input_horizontal and input_vertical so that it may use it. These are stored in hspd and vspd. These variable will eventually be applied to the Player’s x and y. 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 mspd, Max Speed. Now we have the maximum potential movement the player can take, but what about walls? This is done by checking if at x+hspd, the Player would collide with the object Wall. If so, hspd=0. But I still would like to move the Player as close as possible to the Wall. I get the sign of hspd, whether it is positive or negative and move Player one pixel, positive or negative along x, until I hit Wall. The same vspd and y. That is all the movement.

For Attack, if
input_attack_pressed==true then it creates the Weapon object at the Player's x and y. 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 input_direction by 45 and I get a number from 0 to 7, one for each direction. This value is stored in dir. this variable is used to rotate the sprite of Player and Weapon.

One
unique part 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 input_back to true. Then, only on windows phone, if input_back==true then game_end().

One last thing are the
dbug 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. dbug 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.



Update 004 - Animation ... and some News

Posted by , in Chronicle Destiny 26 January 2015 - - - - - - · 489 views

The Alpha 004 update is up at http://bluestar03.com/Chronicle/Alpha 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 action_state, and I use the enum action_type to keep track of all the actions, currently only stand and walk. right now, based on the speed, the action_state 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 action_state==action_type.stand { sprite_index=sprPlayerStand }; 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, sprPlayerUp, sprPlayerUpLeft, 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 ss, and not assigned it directly to sprite_index, 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 ll, but where do I start it from? The dir variable stores the direction the player is facing, but from 0 to 7, or dir=Control.input_direction / 45; so dir * ll gets me the start of the animation, but what about the current frame? Well, keep track of it with the variable sindex. Each step add the variable sspd, for sprite speed, and if its grater than ll, 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 v.

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 ss, ll and v, 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 Posted Image


Update 003 - Pause and Menu

Posted by , in Chronicle Destiny 07 September 2014 - - - - - - · 364 views

The latest update is up at http://bluestar03.com/Chronicle/Alpha 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 < 0, it checks if active_button is == to 0 or menu_length, depending on direction. If it is either one, it make other button the active one, if not, the one adjacent to it, one up or down, and makes the current one inactive.

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

Posted by , in Chronicle Destiny 30 August 2014 - - - - - - · 529 views

The next update is up on http://bluestar03.com/Chronicle/Alpha, 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

Posted by , in Chronicle Destiny 15 August 2014 - - - - - - · 535 views

The Next Update is live at the Windows Phone App Store and http://www.bluestar03.com/Chronicle/Alpha. 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:

iso_x=x-y
iso_y=(x+y)/2

depth=-iso_y

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

Posted by , in Chronicle Destiny 08 August 2014 - - - - - - · 739 views

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 http://bluestar03.com/Chronicle/Alpha, 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 Posted Image The store page is http://www.windowsphone.com/s?appid=8929b97c-c911-4033-8ee8-b18902273ff3. 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 Posted Image


Website is Functionally finished

Posted by , in Chronicle Destiny 14 April 2014 - - - - - - · 544 views

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. http://bluestar03.com/Chronicle/Alpha 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.



At GDC

Posted by , in Chronicle Destiny 19 March 2014 - - - - - - · 406 views

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 http://www.bluestar03.com/Chronicle/Alpha/004/ 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.






August 2016 »

S M T W T F S
 123456
78910111213
14151617181920
21222324252627
28 29 3031   


PARTNERS