I think it would be easiest to just ignore manual panning, as it simplifies things as well as makes it easier to keep track of everything. The camera max zoom will probably be bound as by the area needed to see all nodes, and the minimum zoom will be based on action - planning phase will allow zooming in all the way to the centre node, but during testing will follow the minimum bounds required to show all moving bits.
Decisions, decisions...
I think it would be easiest to just ignore manual panning, as it simplifies things as well as makes it easier to keep track of everything. The camera max zoom will probably be bound as by the area needed to see all nodes, and the minimum zoom will be based on action - planning phase will allow zooming in all the way to the centre node, but during testing will follow the minimum bounds required to show all moving bits.
Moving controls to the phone
 |
| oh lawd. |
Then I found this and that.
Tried to get the pointers (made multiple of them, one for each possible number of touches) to work with multi-touch, causing many, many array exceptions, since the size of Input.touches[] changes based on how many touches it detects. And when that didn't work, attempting to formulate some way of using ray casts from the tapped position to check against the collision of the entities.
Then I found this.
The moral of this story? Search the documentation before you jump onto the internet looking for silly answers to simple solutions. Also to note, is that sometimes Unity Remote 4 will stop working with unity when you run it. This is fixed by restarting Unity, at least its worked for me when it does happen (seems to be caused by things such as phone disconnection during gameplay). Also, Unity Remote 4 does actually support touch controls properly from the script, not just a translator for PC controls (meaning it does actually register Touch Phases).
Thinking up UI
So before I actually get into adding more stuff to Ping, I need to consider what it actually is going to be like as an interface. After all, no app has won any favour with unintuitive design and poor looks. Here are some notes of things I've considered.
 |
| Amazing design skills right here |
Developing an Idea
I've hit upon an interesting idea that could make for an android game.
And I've built a working prototype of this thing I'll call Ping. Time to see what I can actually do with it.
 |
| Consideration for phone input is important. |
 |
| ping! pingpingping! pingpingpingpingpingping! |
Iterative Design on bug wings
I always find that one of the toughest things about sprites is getting them to look just right, and especially for animations. An example is this flying wasp-thing I made the other day:
There are a surprising amount of choice in how you can animate this. The way the wings move in all three animations are based on things I have seen done similarly in the past, but its always a bit of personal preference as to which style fits best. I like the first one the most but it certainly wasn't the one I originally tried (in fact they made in order from right to left).
 |
| Bzzzzz |
Thinking with Slopes & Platforms
I recently tried my hand at making a platforming game using GameMaker: Studio because of how much its changed, gained popularity and apparently is much less restrictive since the last time I tried to use it back in the 2000s.
The first thing about making a platformer is to consider what you want to go for at a later stage. This is important, especially in studios like GameMaker which only provide the basics, since it helps a lot to have support for things down the line - like if you want something to be moddable you do away with some things you'd usually make constants and instead assign them to variables. Not hard but can be a bit finicky at times if you plan to do it for a lot of variables. Plus it avoids brute forcing a problem (which is almost always a bad idea down the line, or immediately), and helps to avoid every build having a patch note along the lines of *tweaked X* or *fixed bug/exploit regarding X* or *fixed ctd caused by X*
For example, in my case I decided pretty early on that I'd use some slightly awkward things for my soon to be platformer engine to handle - namely slopes and one-way platforms like the ones in Sonic. This means things taking into account checking for single pixels increases in elevation and acting accordingly for slopes, and just generally awkwardness for one-way platforms.
The first thing about making a platformer is to consider what you want to go for at a later stage. This is important, especially in studios like GameMaker which only provide the basics, since it helps a lot to have support for things down the line - like if you want something to be moddable you do away with some things you'd usually make constants and instead assign them to variables. Not hard but can be a bit finicky at times if you plan to do it for a lot of variables. Plus it avoids brute forcing a problem (which is almost always a bad idea down the line, or immediately), and helps to avoid every build having a patch note along the lines of *tweaked X* or *fixed bug/exploit regarding X* or *fixed ctd caused by X*
For example, in my case I decided pretty early on that I'd use some slightly awkward things for my soon to be platformer engine to handle - namely slopes and one-way platforms like the ones in Sonic. This means things taking into account checking for single pixels increases in elevation and acting accordingly for slopes, and just generally awkwardness for one-way platforms.
Subscribe to:
Posts (Atom)