I spent most of my time today reading and trying to research useful components we could use on our app, when we get to building it. Having done quite a lot of coding, I switched to reading useful things for a change of pace. Using marquees seems to be a reasonable way to check things like reading speed, and making it adjustable seems useful, so that was the thing I’ve been looking into implementing today. The top result — and the one I spent most of my time on — was this subclass of UILabel by cbpowell. Adam had been tinkering with this one for a while, and it looks very promising so I thought I would do the same.
The main problem is that when the speed of some scrolling text is readjusted, the entire text goes back to its starting point. We both agreed that this sounds frustrating, so we tried to find what could be done to fix this. I spent some time reading the code, but since Adam had already gained a lot more insight into the files, I thought I would be more useful if I read the documentation instead. I did so and made several notes on features that could be useful, but ultimately drew a blank. There are lots of ways in which text can be restarted, but I found nothing that would tell me how to not restart it. I think the notes will be useful later on, especially if we choose to use this subclass, but at the moment I’m not sure how to fix this.
So instead I looked into other implementations of the same concept. At this point I have only a list of results that look useful, and hope to start by looking into these next week.
- StackOverflow’s suggestions
- Stormy Productions’ scrolling UILabel
Today was kind of a struggle. After reading through the 1400 lines of code for the marquee label, I am still non the wiser as to why it resets whenever I increment the speed. I have commented out and then uncommented everything I could think of, but to no avail. I might be able to scrap the code and rewrite my own, but some of it is fairly complicated, so if that is the path I take it will certainly take a little while to just get it right. I spent about 3 to 4 hours just looking over that code; I tried building a relationship map between the different classes therein, but it became too interconnected to be usable. I searched around and found two implementations in objective C for the same basic process. I don’t know any objective C syntax, but if I can do a quick primer or two on it I may be able to port those classes over to swift for use in our project. I will definitely keep working on this, as it is something we will need to have sorted out by the time we get the gyroscopes set up. Other than that I deliberated starting a new game today, but opted not to. Anytime I wasn’t tweaking with the different marquee labels I was reading tutorials on swift storyboards, especially how to programmatically interact with the storyboard, and not just rely on its UI, which I find to be slightly convoluted. For the near future my main focus is just going to be making a working marquee label, but as it seems to be quite the convoluted process it may take a while.
Today was a relatively slow day where I feel like I did not get very much done. To a large extent this is because I spent a whole lot of time on trying something that ultimately did not work out at all.
I started the day by revisiting the app I “completed” yesterday; it wasn’t completely bug free, and I didn’t like its graphics, and I thought these would be quick fixes that could be a good warmup. The two big bugs were: 1) when moving a piece down, valid swaps were not recognized; and 2) the tiles were incomplete on the top and right edge. In both cases the solution turned out to be fixing typos. I had either forgotten to subtract 1 from an index somewhere, or made the range strict instead of inclusive. So while both were time-consuming to find and fix, neither bug was extremely enlightening. I then thought I would make it look prettier, so spent a little bit of time finding a different background, adjusting colors and so on.
At this point I thought I would try something new that wasn’t covered by a tutorial on this app I had just finished. There are 5 levels available on the game, but which one actually loads depends entirely on what is input in the code. I figured it would be relatively straightforward to let that selection be user-determined. To this end, I first spent a long time finding out how to connect a new page to the game page — it turned out to be simple, but took me a while to find. At this point I thought it would be easy to change the variable that loads the level based on which button is pressed, but it turns out that the connection goes to a file called UIViewController, but I needed that data in GameViewController. I looked into importing data from one file into another for a while, but I concluded that it was too complicated to bother with at this point and ended up scrapping the whole thing.
With that constituting a large part of my day, I wanted to do something different and tried to research a little bit on how reading level is generally tested. Almost without exception the answer is using text comprehension. Adam found an API (?) that allows scrolling text to be implemented, so I think I might look into that tomorrow as well as continuing research. I also started a new Sudoku app but feel that making more games is not giving me the expertise I need, so I will try a different approach tomorrow.
Today I floundered for a little while trying to decide what to do. I started a tutorial on using storyboards for iOS, but it quickly became clear the storyboards were functionally equivalent to their OS X NS equivalents, so I didn’t spend too long on those. Vidushi and I went to try and find Prof. Lewis to get developer keys to start testing the gyroscopes, but couldn’t find her unfortunately, so we will try again tomorrow. After that I decided to try and find a way to make text scroll across the screen, as that will be necessary for our final product. This turned out to actually be incredibly difficult. I found two solutions, both custom classes. One was coded in Objective C, and the other was in Swift. I started with the Swift one, and basically just tried to decipher everything that was going on. It had imported a library which was poorly documented online, but I did my best to figure my way through it. I think I kind of understand it, but the animation style here is very different than in the SKSprite Class I worked with previously. I implemented a counter button to increase the scroll speed of a piece of text. However, I noticed two problems: first, no matter the increased speed, there would always be a slight delay when the text looped around on itself and reached its “0” position. Second, whenever the speed was increased the text reset to the origin, meaning it couldn’t be dynamically altered. After spending roughly an hour going through the workflow of the class and commenting out code to see how it affected the final product I figured out how to fix the delay issue. I then spent a long time trying to figure out how to remove the reset to origin, but unfortunately I wasn’t able to figure it out. I think it has something to do with the animation frames of this third party library requiring a home state, but I might be able to add an extension to undo that dependency. I will try tomorrow.
I completed the tutorial for a Candy Crush-like game today. The latter half of this tutorial is instructive in a very different way than the first half, since the problems I encountered the most were problems of the tutorial assuming I knew how to do something when I didn’t. I also had occasions of thinking I knew how to do something and finding out that I didn’t! In particular, this included interactions between the storyboard and the code, since the outlets that connect the two take many different forms. For example, if a button is pressed on the screen, connecting that event to a particular function in the code can be done in many ways, and I had to learn a new way in the process of finishing this tutorial.
Besides this, the other useful things I learnt today were a whole lot of animation and integration of outside features like music and images. How to get music to play in the background, how to use external images one over another, and how to make an image appear only in certain places and not in others — using layers and masks — were among some of the ideas this second half uses. There were few new “Swift things” I learnt today; the only one I can think of was discovering that we can make properties “lazy” so that they are only computed when they are needed. The game isn’t perfect — there is still a strange bug and I’m not very happy with the graphics — but I think it’s done for now. As always, all my code is on GitHub. Since Adam suggested that building his own game was helpful for him, I might start there tomorrow.
I couldn’t decide on a new project to start today, so I decided to return to my 2048 project, and add in animations, like I talked about maybe doing. As I had expected, it required a fairly bottom-up alteration to the system, though it was an interesting way to look back on what I had done, and reason my way through code I had written previously. I optimized what I had down last week a lot based on what I have learned: using optional types to limit variable declaration requirements and the like. Animations themselves were useful because I got a chance to get a lot more practice with SKNodes, the UI elements of swift. I’ve worked with them this whole time, and in the Candy Crush tutorial, but now I really delved into the documentation to look up how to retrieve parents, remove children, and display what I wanted. The biggest overhaul was in the way I displayed the new screen.
I used to accomplish this by simply creating a new node, and recreating all sprite images. I had thought my animation would be a fade in of the new node, and a fade out of the old node, and then removing the old node from my master node which I would create. Instead however, I directly integrated nodal management in my animation method, so not only does it animate the tiles moving around, it also adjusts the node accordingly, so now I only ever create one node. I also learned a little more about enumerations today, though I still don’t fully understand their purpose; everything they do seems to be accomplishable with simple code. What I really need to better learn is to how to start a non game application from scratch, which is what I will start tomorrow with a restaurant ratings application that I will struggle through to do without a tutorial (though I may glance at a storyboard tutorial if needed). As soon as we get the developer licenses I will switch to gyroscope driven applications. I also will spend some time tomorrow making a scrolling text application, where the speed of the text is modulated by button presses, and then I will be able to adapt that framework to be gyroscopically controlled.
My day today was devoted entirely to working further on the tutorial I started last week; that is, the Candy Crush-like game using Swift. Today I completed Part I of the tutorial and started off on Part II. I ran into a number of bugs today that made the process a lot longer.
For example, at one point I had a strange error where a class I have been using for the entire duration of the project was no longer recognized (a call in Swap.swift claimed that Circuit was an unidentified type). I tried various things to resolve this, but the thing that worked in the end was a useful discovery. As the project is simulated various times, significant amounts of the data is stored for quicker and easier access and is not overriden when you make changes to the project. To get rid of this saved data and replace it, you can manually get rid of it (Window > Organizer) and also “clean” the project (Product > Clean). This solved the bug I had encountered before and also another problem I had faced, which was being unable to load images.
Another really useful concept I learnt about today was “extending” a preexisting type. In this tutorial, a dictionary is extended to include functionality where an input JSON file can immediately be converted into a dictionary, and this is done in a straightforward fashion: in a new file, Extensions.swift, I simply declared the extended functions within “extension Dictionary”. This concept sounds very useful for ease of coding once we get to coding our own project.
Finally, today was also a lot of with UI — as this game is like Candy Crush, only certain moves are valid, and detecting these moves and determining their validity requires implementing the functions touchesBegan(), touchesMoved(), and touchesCancelled(), which was a useful look into how Swift deals with UI. As tomorrow is implementing the rules of the game, I am sure this will require even more understanding of UI.