Top of The Year

Happy belated New Years to one and all. I know I’ve been missing for the past five months. For those who are wondering where I’ve been, I’ve done a couple of things.

Reviews

For the last five months of 2015, I started writing some reviews for games I had been playing and even the Axentwear Headphones that I had backed in 2014. I reviewed Until Dawn, Wet and Oni. I’m presently playing through Dragon-Fin Soup and should have a review up by week’s end. I’m presently trying to get funds together to preorder Street Fighter V in time and do a review for it. Once I have a better idea of DOOM’s release date, I’ll be working towards that as well. If you’re interested, you can find my reviews here at my Hubpages

Crunchpod

Hoo, boy. Crunchpod, my pet personal project I started after I left college, has been on the backburner for way too long. I resumed work on it in December. Fixed some errors that I had left hanging. Expect more updates in the new year. The repository for this can be found here

Powahball (Powerball)

After powerball madness a couple weeks ago, I thought I’d try a little digging. I started work on a PHP page that would scrape the past powerball winnings, parse them and then give information on what the most hit numbers were. I’ve finished the scraping, parsing and counting. I still need to get the input fields created (I want to display past winning numbers that contain a certain set of user provided numbers), javascript DOM injection that will display it all and formatting to keep it from looking like a colorful, jumbled mess.

So to recap, I’m going to be doing a Dragon-Fin Soup Review and and finishing up the first version of my powerball page. Stay tuned for more updates.

 

Until next time friends, Godspeed and Nekocoder out.

The Good, The Bad and The Ugly

Welcome back for another Crunchpod update!

As promised, I have a few important changes to talk about.

The Good

I was able to get Subversion set for the project.The project is in it’s own github repo now: https://github.com/nekocoder/Crunchpod. Hopefully now, I can better guard against losing progress and even share it for others to edit and enjoy. If anyone is wondering what my rational was for the specific Unity folders that I included in the repo (or may need help deciding which to add for their project), I followed the guidelines shared here.

I added some animations a little while ago. Since I didn’t have any individual sprites created, I decided that this would be as good a time as any to explore Unity’s 2D animation tools. I’m happy that I could create animations by tweaking certain attributes of the gameobjects and their components on any given frame in the timeline. It felt like I was back in Flash, so that bit of familiarity was welcome. I made a hurt animation (blinking red) and a booster active animation. They’re crude but for now, they’ll do. The part that was a pleasant surprise was the animation tree feature. Being able to link animations in a pattern and have them automatically switch between them was great.

That being said, those animations are useless without collision detection. I did some digging in the documentation and was able to get some idea of what tools Unity has for collision detection. My player object and test enemy both have rigidBodidy2D and collider2D objects. They are used in tandem with each other to detect collisions between objects. They send off messages to OnTriggerEnter2D(), OnTriggerStay2D(), OnTriggerExit2D(), OnCollisionEnter2D(), OnCollisionStay2D() and OnCollisionExit2D() methods that you create. The collision variants are used for rigidbodies that have the IsKinematic option disabled while the trigger variants are for when the collider objects act as triggers. Which you use will depend upon whether you want the physics engine stepping in when a “collision” occurs.

The Bad

As expected, there’s always problems, the first of which is this AABB error. It appears to be linked to the scaling I’m using for the idle booster animation. An idle booster has no fire sprite, but I’ve yet to find a way to disable visibility in the animation settings. To compensate, I’ve reduced the X and Y scale to 0. Obviously, that’s going to mess with any calculations that use the sprite dimensions (which an axis aligned bounding box, or AABB, would). If push comes to shove, I may need to just manually do so.

I’ve also noticed some spotty triggering. OnTriggerStay(), OnTriggerStay2D(), OnCollisionStay() and OnCollisionStay2D() are supposed to fire each frame after initial “collision” as long as the two objects are still in contact. Unfortunately, for me, they seem to stop firing after roughly 20 frames. This may correlate to one or more of the objects being in motion, but they seem to have been designed to fire repeatedly despite this. I will check to make sure there aren’t any options with the colliders or rigid bodies that haven’t been set properly.

Either way, I’m thankful for the small bit of progress I’ve made and hopefully I’ll have more updates for you a little later this week. Thanks for sticking around and feel free to ask any and all questions.

Nekocoder out.

Reemergence

Hello folks!

Long time, no see. I do apologize about the long bout of radio silence. The last half a year or so has been a bit wired, dealing with employment and some other issues in my personal life. More will be to come, but in the meantime I’d like to get back to development on Crunchpod. I’ve made some progress in the last few weeks and will be posting information on those this week.

So to make a long story short, I’m back and all systems are a go for Crunchpod

What’s on the menu?

Time for another (long overdue) update on Crunchpod!

I extend a warm welcome to any new faces and, to all returning faces, welcome back. I was hoping to have this done by Thursday last week, which was my birthday, a little bit of a surprise for anyone interested. Alas, it was not to be.

What’s New

menu 1 menu 2menu 3

At the conclusion of the previous post, I said that I’d start on the menu and basic UI. So far I’ve made a little progress. I have some rudimentary menu “frames” (or should I say foundations) set up. Pictured are (from left to right) the Title Screen, Main Menu and Pause Screen. I wanted to at least be able to travel from menu to menu, menu to game (and vice versa) and to be able to present and choose different options in a menu. Doing this means that I’m only roughly 25% (if even that) finished with all of the menus I want in the game, but this at least gives me the materials to start work on the save\load, options and pause menu.

Challenges

There were a few challenges I faced, primarily Input filtering and GUI commands.

Throwing a “menu”, or some abstraction thereof, on the screen is simple (in concept, more on that later). Making sure that it’s robust enough to be functional requires attention to detail. Frames are incredibly fast. Input is checked every frame unless you intervene and if you don’t you’ll blow through multiple menus with multiple inputs with a single button press. That being said, a single button press can be picked up, in parallel, by multiple objects at once. So filtering who gets to act on input using some sort of state system is paramount as well.

Getting on the screen itself can be a challenge too. I hit a rough patch with the GUI class. Being able to put texture2d in a box and put it on the screen every frame was amazing. Until the sizes didn’t line up as I wanted, at which point it became a headache. As you can see, each box also has it’s own background. So formatting becomes a challenge that one will have to deal with as well.

Solutions

I solved the issue of multiple reactions from one input by using a crude “state” system. The main overlord object, ground control, has a variable that reflects the intended state. So when a menu is active, the state says menu. If the player is controlling their character, the state says game. Only the related objects are allowed to react in a certain state. That being said, you’ll still fly through states if you’re not careful. As such, I have a throttle variable that is incremented with each relevant change, even when the state isn’t changed. So if a new menu is transitioned to, it starts its own throttle countdown, which is a frame count during which some input is ignored

I found it easiest to call GUI.box and drop a rect object in it. The biggest issue was the sizes didn’t exactly line up as I wanted. I decided that I’d bite the bullet and do some small scale math. I thought I’d need to resize the textures, but that was a semantic misunderstanding on my part (note that texture2d.resize will change the data of the texture). I found that what I wanted was to scale it’s display size down to look better on screen. I created my own algorithm to calculate the picture ratio, then add a box that was scaled proportionally using a supplied percentage based width or height.

What’s Next

So what I’d like to work on next is fleshing out the menus more (options, anyone?), character rotation (got an idea for that as well) and subversion because I don’t want to lose this work.

Well, that’s about all I have for now. Thanks for sticking around and feel free to ask any and all questions.

Nekocoder out.

Coloring inbetween the lines

Hello friends, it’s Nekocoder. Just a quick update on the problem noted yesterday.

success1 success2

SUCCESS! I talked to some of my colleagues in my RIT GDD facebook group for some help. They pointed me in the right direction. That being the case, now I can properly express what the issue was and how I fixed.

The Issue

What I was seeking to do was to confine the character to the space that was viewable by the camera. It’s worth noting that there isn’t a discrete object that represents this. This is an abstraction that you have to determine and work around (much like screen bounds themselves)

The Solution

Like I previously stated, there isn’t any discrete object that represents the space shown on screen. Or rather, there isn’t a geometric object that automatically grows and translates as the camera moves that can be queried for a width, height, volume and position that is equivalent. to the area the camera shows. There are viewport and screen objects, however, that hold abstractions of the camera output and display respectively. These refer to their own separate “spaces” that are separate from the actual world space. The numbers will literally be ranges between 0 and 1 or 0 and a pixel number. However, the viewport has it’s own function that will converter the 0-1 ranges the viewport uses to represent it’s area of it’s picture to that of world coordinates. These I can feed to my script and check against.

To make an analogy, my camera doesn’t have a spotlight that highlights what it is focused on, but it does spit out Polaroids with GPS coordinates of the scene, which is just as good. Since this is a 2D project, this works out particularly well since those coordinates will be off the square I have on my table instead of 4 disparate points in the room.

So with that hurdle surmounted for the moment, I’ll be moving on to menus and basic UI next.

Stay tuned for more updates.

The journey of a thousand miles…

..begins with one step.

So Crunchpod development is a go. The first part of this is, however, is getting reacquainted with Unity and learning the new 2D components of it.yay

That being the case, I decided that I’d start with creating a few prefabs and getting an object on the screen. Naturally, you need to make sure it moves within proper boundaries (in this case, the visible part of the screen). Success, right?

whoops

Whoops, guess not. Apparently, the vertical component is fine, but the horizontal component isn’t. I’m taking the camera ratio and multiplying the pieces by the orthographic size. May have to check into the specifics of the camera view and how it relates to world coordinates.