Creative Jam

    We started off quite strong. Everyone had something to do and new features were being added and bugs were getting fixed every hour. The first roadblock we came to was due to networking. The first time we tried to build was about three hours in and the project packaged without any errors but many warnings, so as far as I was concerned it had succeed 100%. We noticed the problem though when we tried to open the .exe in order to test the game. It didn't. You could run the program and we could see on Task Manager that it would open then immediately close with no errors or messages or anything. We had nothing to go off and no starting point. About an hour later we had came to the conclusion  that the project had somehow messed up (based off several answers from the ue4 answer hub) and to fix it we would have to create a new one and migrate everything over. No one wanted to do this but it seemed it was our only option. Midway through migrating the project, Austen realized that one of the first warning messages when we tried to package the project had something to to with a multiplayer plugin that I had added to add extra settings to multiplayer sessions. We turned the plugin off and it worked fine. In retrospect I totally should have seen this as a problem, yet again because of engine updates. This time it was only a patch from 4.24.1 to 4.24.2 so I thought it would be fine, but from now on I can never trust any engine update without making a copy and testing it first.
    Things went back to normal for a while and we went to bed with a functional but not complete game. On Saturday we tried to tackle the long time problem of being able to drag multiple cards with multiple fingers on the table. The solution we found was very exciting. We learned about the Map container type in unreal and found that it would be perfect for our situation. Basically it stores a variable of one type and has another corresponding variable of another type. So in this way we were able to connect a finger index to a specific card object.
    Another major hiccup we faced was differing knowledge about networking and replication. Out of the three programmers I had the most knowledge about how multiplayer works going into the project. However, almost every feature would require knowledge of what should be replicated and how and when events should be triggered on the client vs the server. This difference in knowledge hindered my production somewhat as I was required to help other programmers with their features instead of working on my own stuff. In the future it will be necessary for everyone to be on the same page for major features so that production can go smoother and less interrupted.
    We had agreed that all programming should be complete at least 4 hours before the deadline. Had this actually happened we would have been fine and able to spend the remaining time implementing art, sound, and fixing anything that was found while play-testing. Instead, by our predetermined deadline we were still implementing new features and trying to fix their implementation with old ones. This pushed us until 20 minutes away from the deadline when we actually got a working build. Had we stuck to our original plan we would have had one less feature (that being the key puzzle) but we would have had time to get art and sound in as well as fix the glaring issues we later found with the navmesh (being that it didn't actually build). A better way of going about this would have been to stick to the deadline with no exceptions, building right then and there, scrapping any new features that would have been added in favor of having a fully working game with less features as opposed to a broken mess with many features that don't work together.