The Show

The game is finished. We had our Senior Show this weekend. The presentation went off flawlessly and the crowd really seemed to enjoy the game. While there is always something you wish you could add in hindsight, our build was as close to complete as we could have hoped.

After the show it was time for the demos. Our demo was a huge hit. The president of the college was the first to come over and play it. He really seemed to enjoy playing. We also had a couple industry recruiters who were very impressed with the game and our progress. We were easily one of the most popular demos at the event and there wasn't a single person who played that did not enjoy it.

The game also ran beautifully throughout the demo session. There were a couple bugs we were afraid might show up given the difficulty we had getting the controllers to work on the computer earlier in the week, but they never did.

It was a fun ride. Many of the team members have expressed interest in continuing development, myself included, should we be able to. For now, this chapter of Dan Shredder has closed. Hopefully the next will open for it in the near future.

The Home Stretch

It was the last week of development. More polish was necessary and the designers wanted a couple additions added for clarity.

The one problem the game has had for the longest time, is that when using a controller or the arrow keys on a game menu, you only had this tiny dashed border to figure out which button was currently selected. We had previously tried to fix it by making the buttons swap out for a different color version when selected, but it wasn't working. Instead, I made an invisible image next to each button that revealed itself when the button was selected. This worked perfectly and game the game a little more flavor.

I also finally figured out the puzzle of making the video quit out by pressing any key. It was such a simple solution, I was kicking myself for not finding it sooner.

PAX was also this weekend, and while we did not bring the game to PAX many of the members attended the convention, myself included. We ended up putting a build lock on the game before the convention since half the team would not be available over the weekend and our build was due the day after. The whole team did a fantastic job and we are all happy with where the game ended up going into the weekend.

Now We Polish

Feature lock has come and gone and we are entering the final weeks of development. Everyone's main focus is finishing their last tasks and polishing what is already in the game.

Kiosk mode is pretty much done but we have been having some issues getting the video to actually link correctly. We also got a real video now instead of my temporary one. I also ended up finding a couple random bugs while checking over my implemented features.

When the boss battle was added it added sets of notes that would be hit at the same time. In the keyboard controls, this would cause you to either miss one of the notes or over strum. It was an unforeseen problem since we didn't have those notes at the time, but it was a simple enough fix once I found it.

I also discovered a bug in the pause menu, where the kiosk mode timer was not actually stopping when you left the menu. Again, another easy fix but something that would have been game breaking if left in.

The last bug was with the main menu again. My fix for the second main menu accidentally made it impossible to use the guitar to navigate the main menu. I just swapped around how the game dealt with the extra menu and guitar functionality was restored.

Menu Bugs and Kiosk Mode

With controls mostly done, it was time to work on my next feature, kiosk mode. We wanted the game to play a video from the main menu if you idled for too long, and if you idled in a game menu it would return you to the main menu.

The pause menu portion was surprisingly easy. However, I did need to create my own timer system since the one present in Unreal does not run when the game is paused. The tough part was running a video from the main menu. Unreal barely supports videos in 4.10, but there was enough present to make it work to what we needed. By turning a video into a texture and applying that texture to a material, you can create a menu widget with an image displaying the video. Then you play the video's sound file in time with the material. This has it's own host of problems associated with it and getting them synced, but it works most of the time. It's the best in engine option currently available though.

The rest of my time was spent on bug fixes. The game had been plagued by a bug for a long time now, where if you used the guitar and returned to the main menu, choosing the medium difficulty would close the game. It turns out that there was no bug breaking the game, but somehow a second version of the main menu was being created. For some reason the guitar controller was hitting both the difficulty button and the quit button on the second menu, causing the game to close. I removed the second menu, fixing that strange bug. 

Control Success

My keyboard controls from last week were a huge success. We took them to QA testing and they performed very well, with some players preferring that option over the guitar and pad. It also made testing the game significantly easier going forward for the other team members, because now anyone can simply load up the game and use the keyboard instead of having to go to the labs and plug in the guitar and dance pad to test a simple change.

This week I made the toggle system. I had to work through it a bit since the challenge was sending the players choice to the player class from the menu widget. Since the widget is destroyed before the player is even created, I had to create a variable in the game instance that can be edited, tracked, and retrieved from anywhere. This variable is passed into a simple switch statement the turns on and off the different controls. I also added a kill button for easy testing for the team, so they can just kill the enemies they target instead of playing each riff.

Unfortunately, it does not look like keybinds will be possible. Blueprints just do not support that option. It could be done in C++ but we already moved away from that.

My challenge for this week if to make the gamepad controls. They are different from the keyboard controls in that, where the keyboard binding are completely different, the guitar is already considered a gamepad. I need to make sure they not only work separately from the guitar, but that they do not conflict.

Back to Business

After a week long break, the team is back in action and ready to finish up strong in the coming weeks. This week was lighter on work as everyone gets back to normal after our week long break.

I was at a bit of a loss for work this week, so I decided to finally officially tackle a task the team has talked about a lot but never committed to, alternate controls. Starting with keyboard controls, my main goal is to get multiple sets of controls working nicely together and be able to toggle which ones you would like to use. I will continue making bug fixes as well since that is the bulk of what we need to finish in the game as we go into feature lock at the end of next week.

The keyboard controls themselves are pretty simple but also flavorful. 1-5 on the keyboard correspond to the order of the colors on the fret bar. The arrow keys are how you target enemies. There is no button for strumming, simply hitting the correct note will also simulate the strumming on the guitar controller. Having a strum button was just too clunky. Now, the flavorful part of this, is due to the location of the buttons on most keyboards, you can actually pick up your keyboard if possible, and hold it like a guitar to play the game. A nice little touch that matches the nature of our game, but it's not at all required and a player can just play like normal.

Going forward I want to make a toggle system so only one set of controls is active at one time. Then I will look in to making a set of controls for use with a Xbox or Playstation controller. Finally, time permitting I will try to create a keybind system for the player to customize the alternate controls if they don;;t like them.

Bug Fixing Round One

This week was a big change in direction. As I mentioned in my previous post, the team has decided to abandon the C++ port. It was taking too long and we were getting too far behind on the new features. Every one working on it was reassigned, and I moved to bug fixes.

I focused on one main bug, the Skizzard spell disappearing if any enemy was killed in a pack. I was happy to be working in blueprints again, so I started by looking through the enemy ones to find where the state changes happen. Finding the spot, I went through and setup a conditional statement to check if the creature that died was a Skizzard if it's spell was active. As I went to test, I discovered a completely different bug. Sometime earlier in the week a targeting bug had been introduced and it was impossible to actually beat the Skizzard and test the changes. This bug was given to a different team member to fix.

The other bug I looked into was the random game crash. It only seems to happen when playing on medium and restarting after you play through the level once. I looked through the blueprints to see if I could find the culprit, but I'm still not sure what could be causing it. Unfortunately I wasn't able to test any potential fixes because of the Skizzard bug, but looking them over they wouldn't have had the intended effect anyway.

I also looked into adding keyboard controls so I could test the game without needing access to the peripherals. The Guitar portions work as intended, but I didn't get the dance pad controls to work yet. I think it has something to do with the fact that the dance pad is considered player two. I'll have to get it to recognize my keyboard presses somehow or just turn off targeting when the dance pad is not connected.

Change in Direction

This week has been much more productive than those previous. I finally cracked the problem of a function I've been working on the past couple weeks. I stumbled a bit with forward declarations because I've rarely used them in previous projects. I usually just avoid situations were they are needed. I worked my way through it though and came to a working solution.

Then there are the quirks of Unreal. Unreal is not very consistent with how you access member variables, with some being behind a get function while others are just free to call directly. In blueprints these all look the same, further increasing my confusion. Once I figured them out though it was easy to slot all the pieces in where they belong.

I then moved on to the next unclaimed function that needed to be moved over to C++ from blueprints. Using my new found knowledge, this was much easier to go about and I completed it in short order, which the code necessary to expand it's functionality commented out until the necessary class was also moved into C++.

However, after all this was done, we have decided to scrap the C++ re-write. The team realized it would be a constant uphill battle to not only move over the current code base, but also keep up with the new features. It is better for everyone to go forward with what we have, optimize the game in other ways, and stick to blueprints and scripting.

Problems and Pause Menus

This week was an interesting one. I was tasked to make a pause menu. So far I had only edited existing menus, not made one from scratch, so it proved to be a fun application of what I had learned. The pause menu itself wasn't too difficult, but the logic to get it working and switch between menus was new ground. I was able to get it in and working as intended, but getting it to return the game to the main menu proved to be much more difficult. Not only that, but my second task interfered with this one, causing myself and my team mates to lose valuable time.

Now, my second task was to move one of the blueprint functions on out fretboard to the C++ class. I picked it up fairly quickly, but ran into trouble finding out how to retrieve the target enemy. After I was pointed into the right direction, I set about making the needed function to use it in the fretboard. It was at this time I was asked to make the pause menu return to the main menu instead of closing the game when you hit the quit button. Not seeing any errors in my build, I commented out the changes just in case and committed the build so I could pull the changes our designers made before changing the pause menu logic. I thought I had it figured out and went to build, only to run into a very vague and useless error message. Somehow during my commit or the merge, I'm still not sure which, this very nasty bug appeared. It completely broke the build for myself and others. We spent a couple hours trying to fix it, each of us who were effected testing where it could have appeared and possible solutions. Kyle was the one to finally figure it out and fix the issue, but by then the damage was done and we all lost a lot of valuable work time. Neither of my tasks were able to be completed for the new build, putting us behind when we are already trying to pull it all together in the C++ classes.

Fortunately there should not be much left to either task, so they can be completed quickly barring unforeseen issues. I'll have to work harder this coming week, and hopefully we will be ready to move onto new content by the end of next week.

UI Shenanigans: Week Three

This week I had a change in focus. Being weak in Unreal I moved to a slightly easier task, changing over to the new UI assets and fixing any bugs that were there. For something so simple however, I had the hardest time just getting the assets in. Turns out I was going it the completely wrong way, so once I was set back on the right path it was easy to get everything in.

Now, in proper Unreal fashion, it couldn't be simply left at that. In Unreal's menu widgets, there is a display option for buttons called hover. When your hovering over a button it will change to a different asset, which we have so you know the button is selected. However, this only works with a mouse, and not the controller. The controller selection is not considered hovering, so another workaround is needed.

To do this, I had to manually change the default image to our selected image and back again when your on another button. This is done in blueprints with a function that breaks apart the button style and rebuilds it using the desired image. However, we ran into another couple problems. The first, and most important bug is that the game completely locks up due to the button constantly switching every frame. We need to either find an event that will rarely be fired, or set it up related to inputs. The other bug, is that it's not actually using the images correctly, and just setting the button back to default values. This is less important though because it doesn't break the game, like the previous bug.

Hopefully next week we will have these bugs squashed. I am also going to start trying to combine some of the separate menu widgets into one.

New Semester, New Game: Week One and Two

An new semester, and a new game. After the end of last semester, unfortunately the game my team was working on wasn't chosen to continue development and we were moved onto other teams. The team I ended up on was Legitimate Studios, and their game is Dan Shredder in Hellzone. It's a game that uses a Guitar Hero controller alongside a DDR Dance Pad to fight and defeat enemies. Fairly innovative and very fun, they chose to make the game in Unreal 4, an engine I had little experience with up until now.

The first week was very low key. We had our first couple official team meetings, where everyone got to meet each other and we began planning what we would need to do within our disciplines. Myself and the the other programmers decided the most important thing to do was to move all the blueprints into C++ classes. Blueprints are significantly slower and use up a lot of resources, so this switch would improve the game's performance by leaps and bounds. We also decided on the various roles each programmer would cover. Dan and Kyle would work on systems, Cody would work mainly on gameplay, and I would fill in where needed with a current focus on the gameplay side.

As I mentioned at the beginning, I had not worked much in Unreal 4 before joining the team. Much of my time these past few weeks has been learning not only about the systems in the project, but also learning how to use Unreal. My current two tasks are focused around the blueprints, which gives me ample time to learn how to use them and how to move the game away from relying solely on them. It hasn't been easy at first, but very rewarding. This is a great first step for myself and the team, and I cant wait to see where our efforts will take us.

Postmortem: Wands and Warheads

The project has come to a close. We nailed our pitch and did the best we could for the playtesting session, but at the end of the day, Wands and Warheads was not chosen to go forward into the next semester. It's unfortunate. All that work we did to setup the game for success, and have it stopped before it can truly manifest. It was a long, fun trip, but it's one that ended before it was finished.

Wands and Warheads was originally made by accident. When the semester began our two potential games were a Guild Management Game and a Hardcore 2D Survival Game. As placeholder for the ranged weapons in the survival game our designer used a fireball effect, which was an unexpectedly huge hit in class. This led us to rethink our options and games, and from that came Wands and Warheads, which replaced the Guild Management Game.

For me this jump was a big switch. The Guild Management Game had been my piece of the conception phase, so it was hard to let go of. However, it would have been much harder to make work than Wands and Warheads, so it was ultimately the right decision, Once we chose Wands and Warheads to be our game going forward, I took over the map and navigation systems as my main focus, with little additions to other systems based on time and need. I also contributed to the art in the game in the form of spells and a few items.

Working on the map was an interesting graphical challenge. I had very few issues and bugs pop up that weren't graphical in nature, which is unfortunately my weakest area. I couldn't add a new feature to the map without the graphics bugging out in some way. It was also an interesting design challenge. I was left mostly alone to make the map as I please. As the game world was updated, so to was the map. However, I had to constantly reference John's plans to make sure I revealed enough info for the map to be useful, but not so much it was trivial to navigate and showed all the world's secrets. This eventually led to the balance of towns being marked while single houses were not. Since the map was so closely tied to John's work, I created the map with the intent of being easily adaptable. This worked well in the long run, since there was one week were the map was changed in some way almost everyday, and updating the map was simple since most it had handled most of it automatically.

There were certain key decisions we made this semester that pushed the game the direction it did. The biggest one was our decision to drop the Guild Manager and double down on the Survival Game with Wands and Warheads. Without that one decision, we would have ended up in a much different place, and I don't think the whole team would have been as happy with it as we are with Wands and Warheads. The next big decision is our switch from Fantasy Survival to Survival RPG. Originally Wands and Warheads was just a less punishing version of the Hardcore Survival Game with fantasy elements. This was a quick change in focus and a very easy one, but one that worked out very well and without it we could of had a very different game. It also helped differentiate the games and gave us a much more defined goal for Wands and Warheads. The last was our choice to move away from a most standard progression system and switch to an option based system. Instead of having certain weapons be better than others, they are balanced around specific playstyles. The high damage weapons carry much more risk compared to the lower damage weapons, in the form of resource use and how much you expose yourself to danger. This gave our combat a much more refined focus and made the game more fun. Being contained to a single level did make this choice easier and stronger weapons would have shown up down the line, but it would be sets of weapons instead of single ones, to keep that balance of playstyles.

Going forward into next semester, I've been placed on the team Superfluous Amounts of Spectacular. They're making Dan Shredder. While I plan to try and avoid the graphics side of things, I learned plenty about Unity shaders during the creation of my map that I could maybe apply to one of my tasks in the new team. I also learned plenty about working better with a team. We of Chimera Inc worked very well together, possibly the best team I've had in any production class, and as such I feel I learned more of what is the right way to work with others as opposed to other teams were I learned what not to do more than anything. I hope I can be a valuable asset to SAoS going forward and we make a damn good game.

Week 10: Final Progress

We have entered the final week. No more major changes are being added by the team to minimize risk. Everyone is focusing on polish and bug fixes, myself included.

To start off the week, I found a multitude of tracks for the team to pick from to replace our current game music. Our placeholder music has been replaced with something more official and rights free. Should we choose to do so in the future we can compose our own score, but this music will keep us from running into any legal trouble.

I made a few more fixes related to the marker system. The text on the markers is finally working, however a new bug has popped up related to the shader. It is incompatible with the text and only renders the text as a black box. Currently I have not been able to pinpoint a fix so the text is currently disabled. If a fix can be found before the final pitch then it shall be applied, but only if it does not break anything further.

I also worked on a quality of life change of being able to delete specific markers using the marker menu. I almost had a solution within the current system, but it would not find the markers it was supposed to. However, it is applicable under a new, marker specific system that can be done should our game go forward. The backend work required means this needs to be put on hold for now to minimize the risk at this point in development.

Should anything new pop up that is game breaking I shall work toward fixing it in these last few days, but for now all looks well from my end and I can lend more assistance to my team in their endeavors should they require it.

Week 9: End in Sight

The game is starting to wrap up in preparation for our final pitch in a few weeks. We have brought together all our necessary features and the bugs are being squashed.

One particularly stubborn bug on my end, lighting showing up on the map, has finally been fixed. Last week I got a shader to remove the lighting, but it distorted the colors of various props. Nothing seemed to work. Fixing the colors caused the lighting to return while removing the lighting would just re-break the colors. At one point I had even removed some colors and rendered them as just white with a black outline. My final solution ended up being a simple one, instead of trying to keep the map's normal colors I applied a color filter to the whole thing. I gave it a sepia tone to look more like an old, faded paper map. The color issues were masked and the lighting was completely removed.

I also fixed another bugs related to entering buildings, where the mask applied to the player camera also applied to the map. My last change directly to the map was adding and removing specific structures from the map. This is to give the player something to find and keep track of with their markers.

Onto the markers themselves, I have completed their final iteration for the time being. I would have liked to do more, but fixing the maps bugs was more important since the markers at least worked as intended, they just lacked extra functionality. Some of my original goals are in place, but the rest has been put on hold. If was are chosen to continue development after our final pitch, I will give the markers the full functionality they deserve.

Week 8: Unity Documentation Woes

This week, I was pretty much going in blind for all my tasks. Having done very little with Unity's UI, I needed to learn a lot from scratch. What I couldn't have predicted is how little Unity 5 seems to have out there. I've spent up to an hour just to find the replacement for a method found in every Unity answer and tutorial. Others are so vague it takes incredibly specific searches to finally find that single answer that actually explains what is happening. Unity 5 seems to have shaken up more than I expected, and I lost a decent amount of time to searching in circles.

The marker system is finally resembling what I envisioned it as. Markers are limited on the map. They are given a unique color to be easily differentiated on the map. They still require names and I'm considering a warning popup to let the player know a marker is going to be removed when they hit the cap. Choosing which marker to remove would be the ideal situation, but this simpler system works for now.

Lighting bug is still a problem, though now for different reasons. I was able to get replacement shaders working, but all the ones I have tried so far distort the colors of the objects that are visible on the map. I've tried a few different edits to fix the colors but they make no difference, so I'm probably missing something in relation to how these shaders are working. As soon as I figure out the color issue I will probably use it to apply a "map" look. Just having them working as mostly intended is a great start though, and it can be easily tinkered with going forward.

Week 7: Adventures in Unity UI

A new week, a new task. This week the team decided it would be a good idea to add the finial systems and refine those we have already completed to be in a more complete state. I was to look back at the map and refine the markers system. The way they work now is a rough implementation, and it makes it too easy to navigate. The bug with lighting also needs to be removed so the player can no longer cheat with the flashlight to find their position on the map.

First, the markers. Current implementation lets you spam markers while also placing an infinite amount of them on the map. If you spam placed them while moving you can create a trail that lets you know the exact path between different points. You still have to remember the general landmarks along the path, but it's a power that can be abused. Under the new system, you would have a limit on the markers you can place, but the markers would be nameable so you know exactly what each was for. This requires a lot of UI work, something I'm not very good or familiar with. The marker keybind needs to open a menu instead of just placing the button. The menu will have the name of each marker with a second way to identify it on the map, probably by color. It will also have a button to add a new color and a box to enter the name for that marker. This is all new ground for me, and still requires a lot of work to complete.

Next, the lighting bug. I've looked around a lot, but something I did not anticipate was that almost all my searches would turn up outdated info. In the switch to Unity 5, Unity also made drastic changes to its shader system. None of the previous solutions exist in Unity 5, so I need to create my own solution. I have the advantage of not know shaders in previous versions of Unity so it's all new for me, but I still have a bit to learn and tinker with. If I can't come up with a working solution through shaders, I can fall back on the pre-render/post-render functions for the map's camera.

Going into next week I will continue working on these problems and have them complete in time for our next stage challenge.

Week 6: Onto the Next Step

We have successfully completed our first stage and begun to work toward stage two. We have gone forward with out Magical, more RPG oriented survival game; Wizards and Warheads. The team is all incredibly excited to turn our full attention on this game. We have great plans and we can't wait to see them all implemented and functioning.

Last week I made a map. This week I made a better one. The previous map worked as a proof of concept, but was ultimately useless for what we wanted it to achieve. This new map is much more robust and adaptable to our level. It's easily editable by the designer as he makes changes to the overall map. It was done using the layer system in Unity, a system I have never used before and honestly did not know existed. By creating and setting layers, the camera used to display the map can ignore specific objects in the playspace that should not be shown on the map. The same applies to the player camera, map specific objects are ignored while the rest are displayed.

I added a marker system to the map to take advantage of the layer system. Players can place these on their map to mark important landmarks they might find along their travels. This can be used to help a player navigate the level and keep track of their target, the large boss monster terrorizing the towns. I had planned on using a different marking system that allowed the player to draw directly on the map, which would have made tracking the monster easier but much more fun as well. Unfortunately it was buggy, imprecise, and ultimately did not work with the way I was creating the map.

I also did some more rune art. Two runes made it in based on the style of the current fire rune, but I have decided to remake all the runes in a new style to work better with our magic system. The current rune style is not easily expandable beyond those we have now, but my new concepts will allow for a much greater number of spell runes.

Week 5: Plans in Motion

The prototypes are finally coming together. We have completed our discipline reviews and are on track to enter the next stage of development with one of our games. The team is in full agreement on which we will take forward starting tomorrow as we bring in the finishing touches for both games.

This week I had a goal that seemed simple on the outside but in reality was much more complicated, especially in a 2D space. I was tasked with making a map for the player to reference during gameplay. The map itself was simple. However, the hard part comes with our secondary goal, making the map slowly reveal itself as you explore. For 3D games this is easy since you can use multiple layers and remove a mask using ray casting. In 2D this is not possible in the same way, though perhaps it can be done off screen using relative coordinates. This will be a goal for next week.

I've also volunteered my non-existent art skills to help with some assets for the game. Having no artist we have to work with what we have, and I'm confident enough in the little ability I have to make a few assets for the game.

I think we are finally not only on the right path but a unified one, and I can't wait to see where we will take our game in the coming weeks.

Week 4: Switching Gears

The team has spoken, and the guild manager has been shelved. Progress was not moving along fast enough for any of us and we have decided to focus on a branch of the Survival Game for our second prototype.

This branch will contain magic. Various spells can be used at the cost of health and resources. It will be a more fantastical take on the survival game we already had. The other branch will continue along a more standard survival game path.

For me, I've spent most of my time becoming familiar with the prototype and learning how to change and add to it's systems. I'll be tweaking the systems and added some extra complexity to them as I learn where all the turning points are. We will soon be making our final decision on which branch to move forward with, so both must be in the best condition we can get them in.

Week 2 and 3: Delays and Complications

The game has gotten off to a rough start. None of this is the team's fault, this squarely falls on me and my troubles these past few weeks. Programming wise, what has been done in the game hasn't been too difficult. Marquee selection ended up being incredibly simple after I did all the necessary research and at that point selecting single units was a few extra lines of code. Swapping between scenes worked without a hitch. Much of the time spent wasn't even in the code, it was tweaking the camera speed and angle to best suit each scene and its controls.

Now, in to the issues the problems that have gotten this game off to a rough start. First would be communication. In week two this was a big issue because Andrew was unsure how to talk with me about what he should do on the project, and as such we lost any potential work he could have added programming wise. He did get all the documentation done though so not all was lost. We fixed this in week 3, starting with our first meeting where we outlined which pieces of the current project each person would work on, and during the week when we used our slack group to ask each other questions about the specific direction the game was going.

Second would be a mix of time management and life just getting in the way. Between work and classes, I have a fairly busy schedule week to week. As such, I try to set aside time to work on homework for class and on programming this game. Last week I was behind on both and with the class happening earlier in the week than the week two deadline, I put my attention on that first. All fine and dandy, except I was so tired from lack of sleep that I was unable to finish the work I had started on the game in time for the team's review. The next day I made sure everything was done and ready for our team meeting, but it was still technically late. This week was another monster all together. During the week my roommate seriously injured himself and needed to be taken to the Emergency Room. The time was 2 am. I did not sleep that night which was immediately followed by one of my most exhausting days at work yet. I fell asleep as soon as I got home and lost the entire day's worth of free time, time I had planned to use on the game.

Now, both these situations could have been mitigated is I set aside time earlier in the week. I need to work a lot on my time management in these coming weeks for not only this game but whichever we choose to go forward with. Right now it's not looking good for this one even though I personally feel it has a stronger and more manageable direction. By the end of next week though both games should be in the spot we want them and we will choose from there.