-The second week of the prototyping phase is over!This week’s goal was to have the core mechanics of the prototype working and playtested  in order to judge whether they are fun and the whole concept of the game seems promising.On the art side of things our team had to make one main character model and also at the same time see how the art style we decided fits inside the engine.

-Unfortunately enough some of the problems we had due to inexperience with Unreal engine blueprints  took us more time than we wanted to be solved.The aforementioned problems were collision detection and applying damage through teams in a less buggy way.Due to the frustration the team decided also to give a shot to the Unity engine while trying to tackle with the problems in the Unreal Engine Prototype.This brought the first and maybe most important question in our team.

1)Should we use Unity or Unreal for the main version of our game?

JIJI : Well, after trying to implement everything, I have concluded that unity is much simpler to implement than unreal thanks to the robust scripting language and documentation.

This proves to be a tricky question since blueprints and the scripting c# version of Unity are , provided the experience ,user friendly and give lots of ways to implement mechanics in a fast manner.After weighing down our options and the pluses ,minuses of both engines we made the choice to use the Unity engine.The reason being the ease  and speed of scripting in Unity  compared to Unreal's intellisense ,slower compilation time and  the more alien to us blueprints make it a better choice for the programmers mainly.On the other hand that means more work for the artists of the team who aren't that familiar with Unity and won't have the shader/material editor of Unreal.

2)Is the game complete as is?Does it show promise of being a fun game?

Having all of the above problems while making the prototype meant that we didn't have the time to playtest our game and think what kind of adjustments we could make to our mechanics.If we should change some of them partially/remove them completely or add extra one’s to spice our mechanics up.

Of Course these preceding questions  bring up the question about the planning and time management among the team’s programmers.

3)How many of the problems above could have been solved easier and faster by having better communication and planning between the team’s programmers?

-Most of our team’s woes came from inexperience with the Unreal engine but also because of bad communication/planning and the underestimation of the task’s difficulty.This is something that already is being taken care of but late nonetheless.

Last but not least on the art design part of the prototyping phase the artist’s of the team wanted test if the texturing type fits the overall style and mood of the game but also checking if :

4)Will our workflow work with our self-imposed  restrictions in terms of polycount, texture size and style?

During the process of  creating a character for our prototype , everything regarding the question above , worked perfectly and smoothly.Meaning that at this moment, the team has a good idea on how it will approach the creation of future assets.

Onwards to the 1st spring review!

From this week on our team has to finalize the main mechanics of the game,through any unnecessary parts and begin anew.There are a lot of decisions to be made so this week things are going to be tricky and challenging.Till the next post!