A few days before the final day of class, Mike, Matt, Nuhi and me were trying to turn the floating chess board we already had in the Hololen into a game. As always there was a problem, when they tried to import the selector from the sample 2D game Seth found for us, turned out that it wasn't programmed for a 3D environment. So Mike said that is not going to be that easy to solve. The only 2 task we had left were: implementing the selector and Noah Menu, which by the way, Mike noticed that menu is not going to work because Noah developed in the wrong Unity version. I honestly don't think we will have a game to show, we will end with the floating board and Nuhi pieces. Probably, I should have taken the leadership and at least tried to put the team together but with the other 4 classes and 2 jobs I wasn't sure if I would have been able to perform as I would like to (besides the language barrier). In any case, this will be the second class were my team won't be able to show much...
0 Comments
Finally! Mike was able to insert his Unity version on the Hololens and we can test for first time. At the beginning everything seems huge but Mike easily shrink the whole board and pieces. My initial concern was make sure the player would be able to identify each piece (and more important: select them) with their finger without issues. Following Seth advise we reduce half of the initial size. Then, we had the problem of the black pieces really hard to see in the black squares. Although Mike applied so shinning effect on those one I think Nuhi will have to find a better solution for this one. Finally, the size of the pieces no matter the color were unbalance. I wish we could have follow a standard for this, but Mike just adjusted the size which seems incongruous. We will have one more meting before the final class to fix all these.
I started to playtest this simple chess game and quickly found a few or maybe not exactly. After playing for a while trying to win one single piece (taking control of both sides). The match ended in a draw for some reason I couldn't figure out. I search a little and found out that there is this "stalemate" situation when if the king doesn't have available movements the match end in a draw. Cool but there was no explanation at all. That were I realized that this game (the model we are using to build our stuff is focus on player that actually know how to play chess). Which is not a problem but we should explain why or how you lose or win. Also, I found out that there is a problem with "Reverse Last Move" because if you leave the machine play and hit the bottom there is some kind of bug when you can not play and the PC doesn't do anything either. So this trigger a dead end situation, there are probably a lot more but I don't want to keep looking because we don't have time to fix all of them. I actually don't know if we are going to have something to show or even pass this class...
As the days passed I felt even more worried than before. Honestly, I am not sure at all if we are going to make it. I don't know if Mike or Matt actually have something running on the Hololens as they say. For now, I am just trying to ensure at least get enough grade to pass with this blog and the journal. Awful to admit but sadly real. Besides feel shame for ourselves, I noticed that Nuhi was struggling a little to finding proper 3D chess piece models to animate, so I researched them and luckily found some interesting stuff. I had a really stylish board and a set of holographic pieces which just seems awesome. The bad new was that I don't know for sure if he could use because it requires a specific (not free) program. As always I am just trying to help while seeing how this ship keeps sinking.
Today I spent most of the day upgrading the key points in the Game Design Document. Basic stuff like influences or elevator pitch were change to reflect a traditional chess video game. Even so, I searched for suitable references like the old classic Battle Chess. I guess our main focus should make nice animation because there is not enough time to develop a complex IA for the game. When I was done, I asked Mike if it was possible to incorporate some of my ideas as game modes but told me that he doesn't think we have enough time for that... I am feeling pretty frustrated right now with the current situation and team attitude. I probably could have done a little more for the project but honestly, I don't know what else to do, how push the team forward?
After the hard desition of changing the whole project (or rather reduce it) to only Augment Reality simple chess, I felt real frustration. I mean is a classic in this industry. I have read thousands of times cancellations of massive AAA games, it is sadly common. But it's going to be always harder when you experience it in the first person. I lost at least 3 weeks of work with this desition. It's not like my time is so precious to me (that also), what really make me angry is I knew it all along. In one of the first discussions, I expressed my concern regarding the inherent complexity of this idea. Nobody pays attention to me, nothing new. So I ended trying to find some new ideas to add unique features to our dull AR chess game. After a little research, I surprisingly find countless variations of the old chess (How I never thought about that? It is the historic chess, after all). I gathered a bunch of them (which I thought it would be easiest to program) to show the team and see what they think about it.
After double check Nate's units numbers I had a few questions. First at all, is okay giving the king defensive power even if the main goal of every match it supposes to defend that piece? As I am a grand ignorant regarding strategic games I preferred to ask the team what they think about this. The people stuck with King's defense so I gave it a minimal fire capacity not too far away, this should be the last resort for the players. Besides this, I was concern about all units range of vision. I know the will move straight always in enemy king direction. But, How long can detect other units? Nate overlooked this details so I started working on this. Mike explain to me that most range vision has a certain angle of detection, he also gave me a standard example. Starting from this, I design a tentative range of vision to 4 of our units. Before completing the all 6 I want to discuss with Nate in person (He wasn't in this class) to make sure all these make sense to him (he should as the final word here as the lead mechanic designer).
I have been working with Nate on a few design ideas for games modes. First, we discuss a little regarding the size of the battlefield. I wanna know if the player could have the chance to actually edit the numbers of squares on the grid before each match. After discuss a few minutes we decided that it would be easier to programming team just have one preset size. The players then can only expand the relative size of the hologram just like a normal software window. Even so, I really wanted to add more games modes just in case we have enough time. The obvious idea which immediately came to my mind was to make some kind fo "tiny" battle with only 3 units by side. Of course, this will let us do the opposite: a giant battle with a maximum of 10 units on each side of the field. As Mike told me that he didn't think we would have technical limitations. Also, I was playing with the "facing the unknown" idea: you will never actually see your opponents units. the only thing you could do is figure their position by animations, sounds, and projectiles. I don't know is any of these will be possible but as Emil told me: my job is to come with ideas.
As leader designer, I believe the Game Design Document is always very important in order to establish a clear vision of the project to the each member of the team. So, I want to fill out at least the crucial parts for this project. Probably we won't need to fill every single gap of it because here we only have to develop the game and that it but still. So I continue with the work Andrew and Nate have already begun. They wrote basic stuff like the theme, genre, targeted platform, core gameplay and mechanics. So this class I continued working on project scope and determining the role of each person on the team. There was also a list of influences with 2 entries already done but I really want to complete it. Because influences (as references) are very important to have a concrete idea about what we are actually doing. As I didn't really know anything about this kind of games I asked Nuhi and Nate fill out the last 2 influences.
Nate started a document sketching the basics numbers to the 5 main units we decided in the previous class. I helped him balancing those numbers and turn out it was way more difficult than it seems. The respawn problem (how to control how many units each player can have on the battlefield at the same time) was hard to solve. In the end (after so many HearthStone match) I came out with the idea of having a "mana" bar and each unit will have a specific cost to produce. Nate renamed to production bar, sounds good but we will have to see how it works testing it. Also, I felt (even being leader design) kind lost because I never liked this kind of strategic games so I have no references to support the designing ideas. After struggling a few minutes with the following problem: how to recover this production bar? I decided (with Nate help) to try 2 solutions at the same time: every time a unit destroys an enemy you will recover the half of that unit cost and the bar also will recover by itself: 1% per 1 second. Again we will have to test all this and we will probably have to do a lot of changes.
|
AuthorI want to study Video Games in a theoretical way. Archivos
May 2018
Categories
All
|