Category: Development

This week went by very quickly with not much visual progress as I was refactoring/fixing much of the non-visual code. You know, the foundation. That critical but unseen chunk of code that makes your application what it is. I did a refactor of the mouse/touch input code, and when I say refactor I mean rip out and replace. I was unsatisfied with the amount of code there was for managing all the mouse/touch state logic. Plus, when compiling for Android, Unity would complain the mouse code could possibly reduce performance on Android. While I know that there is a difference between touch and mouse, it seems to me that there should be a library that better melts them into something more unified than what is already there. In any case I ended up going with Prime31’s TouchKit.  It’s a nice compact library and it worked well for my purposes, but I’m still unsatisfied with all the #if directives in the code all having to do with mouse vs touch.  Some other things that were accomplished this week:

• The camera is now fixed and no longer orbits the puzzle. Instead the user can pan/zoom around as they please.
• Added some puzzle stats such as push success (how often the player was correct when they pushed the cube in to see if it was correct)
• There are now two types of pixicubes: riddle cubes and theme cubes
• Added block rotation tweens for the theme cubes that visually scrambles the puzzle after you have seen it
• There is now a working PixiCube data structure that can be used to store new PixiCubes
• Puzzle cubes can now be locked and locked cubes have a visible translucent lock shown on them
• Settled on the puzzle sizes for the various difficulty levels (4×3, 8×6, 16×9, and maybe 32×18)
• Added code such that when a puzzle is scrambled, none of the cubes should be oriented correctly
• Numerous refactoring of other code

Stuff for this week:

• Look into storing the jpeg pictures as bytes and loading them into textures at runtime. Currently, Unity pulls in a jpeg and stores it in a much less efficient format in terms of storage size.
• Work on storing the user’s preferences and their puzzle progress i.e. which cubes are completed, which puzzles on which cubes are yet to be finished, how many pixi-points they have, which powerups and how many do they have etc.
• Try to implement some of the powerups
• Decide if I want to offer extra downloadable PixiCube packs. If I do I’ll have to figure our Asset Bundles and how to work with them etc.
• Work on a cool title screen where the logo starts out scrambled and is automatically solved
• More sounds
• The user interface is non-existent and must be completed before the deadline!

My March 2016 project is coming along, and I’ve decided to change the name to PixiCubes. I started with my old Ludum Dare Qbers but found it much more satisfying to just rewrite everything.  Here’s what has been accomplished in the last week:

• Base game code is up and running
• The cube grid along with all its cube operation methods is coming along nicely
• Had a 3D office environment in the game where the puzzles would be solved on your desk, but I’ve scratched that
• Added various sounds
• Particle effect for getting a block in the correct orientation
• The prototype works on touch devices
• Fixed the cube grid such that it can be rotated in any orientation and still work. This may not be useful but it was education and fun

While the list above doesn’t seem like much, there was a lot of work put into the base code that will pay off in the long run. After playing with the prototype, I’m undecided as to how I want to make the content available. I’m thinking either making the game free with purchasable add-on packs, or free to play with ads and an in-game economy to purchase new pixicubes.  Some additional things on the TODO list:

• Investigate asset bundles so that new pixicubes can be added without asset store re-submission
• How to represent a pixicube in code
  • min/max grid size allowed for the whole cube or each puzzle
  • name and description of the  pixicube
  • cost to purchase (in virtual currency)
  • Riddles for each face or no?
• Player save data
  • How to save puzzles in-progress
  • Reset puzzles
• Work on a more aesthetically pleasing cube scramble
• Work on a title screen where the title is scrambled and solved
• Menu system
• Prototype consumable skills and see if they increase the puzzle solving enjoyment
• More polish, sounds, and effects
• Improve the UI for touch devices

Well. That’s it for now. It’s off to work…

With my first month project done and under my belt, I’m now moving on to month # 2. I’ve given it some thought and this month I’ll be doing an update/ remake on my Ludum Dare 19 Entry called Qbers. The rules and setup of the game will probably change, but it will still be a puzzle game in which you rotate a matrix of cubes to reveal a specific picture.  Some things I’m looking into doing for this game:

• Possible add-on packs with more puzzles later
• Consumable skills that can be used to help solve puzzles. these might be purchasable using puzzle points
• Earn puzzle points by completing puzzles in different ways: complete the puzzle within a given time, finish the puzzle, finish it on hard difficulty, etc
• More pizzazz  when rotating cubes and putting them back into place
• Look into making the cubes feel like little individual objects with physics. This would probably change the game play but might add a lot to the feel.
• Create a 3D environment where you solve these puzzles i.e. at a desk
• Figure out how to do the different puzzles/packs
• Since a cube has 6 sides, perhaps make each puzzle pack have 6 pictures in it. During that pack, all 6 pictures would be on the cubes but for each stage you would only be trying for a particular picture.
• Riddles or no riddles for each picture? Haven’t decided yet.
• Maybe change the name of the game

This weekend I created a repository for the code and checked in a skeleton for starting out, so I’m ready to get going.  I’m off to code. Until the next post…