Unfortunately, this is my last blog post for the year. This journey has been full of ups and downs (a lot more downs), however it has really opened my eyes to the challenges that are involved in trying to create something new. Sadly, I do not have a finished product to show for all of my efforts, however I plan to attempt to finish this project during the summer. If I somehow manage to finish this time, I'll be sure to post it here for everyone to see.
0 Comments
Unfortunately, not much more was accomplished during this innovation class. Scratch simply does not have an efficient way to determine if a card is on the top of a stack or not. I've been brainstorming some solution, however all of them involve very complicated arrays and I doubt that Scratch can handle that either. I plan to work on my project this weekend with the hope of solving this nagging issue.
Unfortunately, I didn't make much progress this week. I was unable to find a workable solution to the problem that I outlined in my last post, and I really cannot progress without some viable workaround. It's starting to get down to crunch time. I need to make some serious progress on this thing or I will have spent an entire school year of work with nothing functional to show for it. But first, I need a solution to my many problems, both code and mental.
This week I managed to think through some nagging problems and made some progress on my project. I finally loaded all 52 card sprites into Scratch, which took a bit longer than I expected. I also developed a partial method for ensuring that only cards on the top of the stack can be flipped over. The cards that initially land on the top of the stacks can be flipped over, however I haven't discovered a way to make cards that are revealed after another card moves able to be flipped. Unfortunately, Scratch doesn't have any functionalities that will make this easy, and it will likely take a long time to think this through. Hopefully by next week, I will have a partial solution in place for this problem.
This past innovation time, which was about a week and a half ago due to spring break, I took a little break from my project and helped out a friend who is also working on a game in Scratch. Together, we worked through many of the bugs and improved his game in many ways. This experience is also beneficial to my innovation project because it gives me more experience working in Scratch. Additionally, it gave me the opportunity to see how other people think and solve problems and how their way of thinking different from my own.
This week, I began to work on my new project in Scratch. There was a little bit of a learning curve to figure out Scratch's workflow, however I overcame that and have made some solid progress. I currently have a program that will place the cards face down on the screen in the correct positions when a new game is started. From here, I need to create a way to have the correct sprite show when the card is flipped over. Also, the most challenging part will be ensuring that no card is used twice. Hopefully, I will have both of these things sorted out by next week.
Just when things were starting to look up, my project decided to delete itself. I had stored the files associated with my project inside of the specific version of the text editor that I was using. During the week where I was unable to make any progress, the text editor decided to update itself, and I had a week long window of time before the old version and my files were deleted to save space. Unfortunately, I didn't check back on my project within that week long span of time, and my project was deleted forever. Moving forward, I have decided to move my project to an online coding platform called Scratch. Scratch makes use of block coding and provides a much nicer learning environment for students who don't know what they are doing. I still plan to code my own version of solitaire, and hopefully Scratch will allow me to reach the finished product much sooner.
Unfortunately, this past week has been very busy for me, and I didn't get the chance to work on my project at all outside of school. During our regular innovation time, I spent more time speculating about how the more important parts of my game will work and how these will solve my current issues. I still believe that incorporating the random position generator associated with the start up of the game will allow me to better manage and update the positions of my cards as they move across the screen. This would mean that all of my position data would be stored in the same place, and this should end my issues involved with updating positions. I hope to have more progress done by next weeks post.
Unfortunately, I still don't have any major progress to report. However, I did spend this last week doing a sickening amount of brain storming, and I think that I might've found a possible solution to my problem. My brilliant solution is to ignore the problem! Now, this may just sound like a frustrated student waving the white flag (which it kinda is), however I believe that some of the infrastructure that I have to lay for later parts of the game may help me overcome my current issue. Namely, my solution has to do with the start up of the game, where the cards are shuffled and placed randomly on the board. Without going too in depth, I currently give each card its position outside of my main script (script being the stuff that makes anything dynamic happen). However, in order to create the start of the game, I need to define the positions of the cards within the script because the cards should be in a different place for every game. Hopefully, I can move forward and create the start up for my game and then backtrack to fix my nagging issue. I feel like I'm on the horizon of a major breakthrough. If this idea works like I think it should, I could very well be finished by the end of March. Keep your fingers crossed for good news in my next post.
So you remember how I promised to deliver video of the new code running this week? Unfortunately, the screen recording software that I usually use refused to cooperate, and this is a pretty good indication of how my week has been going. Sadly, the data structure problem that prevents me from storing each cards position after it moves has yet to be solved. This problem feels like it shouldn't take nearly as much thought as it is taking, and it's really starting to frustrate me. I've begun to look at other solitaire codes in JavaScript to see how they have handled this problem, however my approach to coding this game is less than conventional. Most other games will handle moving cards with a click and drag as opposed to a movement function just to mention one disparity. This leads me to a crossroads in my project. I can either continue to be bogged down with setbacks in my creative approach to coding solitaire, and I can model my game after the more conventional approach and have a product much sooner. However, the more conventional approach would feel as if I was simply copying someone else's work and not making any original choices. More updates to come next week.
|
AuthorI'm an Honors American Lit student and this blog chronicles my innovation project. Archives
January 2017
Categories |