Search bar scripting

With the allocation of tasks to do set out for the break, I was left to create a search bar within Unity, that is able to search various churches and display its information on the same screen. I've researched many ways of how I would approach this, finding how to do a script I can understand, and the aesthetics of it. At first, I researched a search bar that is able to function as a search bar, which was great. I would input the variables to the search bar, and it would be able to show them up when a corresponding letter or group of letters are typed.

The problem with this script (shown below) was with my limited knowledge of scripting. I wasn't able to create a box of information that would link up to the search bar, the results wasn't clickable and was not able to hide the results from the search bar. This means that as soon as I entered Play Mode in Unity, the results would instantly be right there, with nothing typed into the search bar.

After attempting to solve the problems of the previous search bar, I tried to look for another example of a search bar I could use, that is more friendlier to scripting. I then came across a drop-down sort of search bar. It suited my needs of being able to select results, and doesn't show results when in play mode. Looking at the script, I was able to change a few things around to add an individual box that would contain information and also be linked up to its corresponding search variable.

With a few minor changes around the script, I had to add the variable "ListInfo", to create a box for information to satisfy the needs the group set out.

The end result of an example of what it should look like once in game is shown below. This isn't the final design of the search bar, as minor details will be added in the future, with the option of hiding the search bar, and adding some sort of shadow or background colour to make it more visible ingame.

Communication Critical Reflection

Group 1 - Gothic Architecture Group

The first presentation presented by the other group doing the Gothic architecture project provided clear definitions of communication and the various aspects of it. These aspects include describing the forms of communication, such as synchronous (verbal) and asynchronous (non verbal). They also identified different target groups of communication. The overall presentation of their topic was very on topic, well structured and informative. The primary problem of the presentation is that their slides were too text based, less visuals and mainly reading off the slides. Also there are minor details of it not having references where it should be. They talked about what forms of communication they are and will be using throughout their project. This included communication within programs (e.g. SketchUp, unity), with the client, and through social media such as Facebook. For my group and its project, I noticed that we mainly communicate to each other verbally (synchronous) rather than non verbally (asynchronous). This was because we held many group meetings to do our work and found that face to face interaction is the quickest way in developing our project rather wait replies through emailing or social media networks. We mainly used these social media networks, such as Facebook as a storage location where we constantly update and share our work among our group.

Group 2 - the Last Suprematist

The second presentation of communication who is working on the suprematist project, mainly talked about how they communicated with each other due to the small number of only having 2 people in their group. With this, they discussed how they would coordinate their work accordingly, to avoid confusion in the future and clearly defining their roles and responsibilities. I think how they clearly outline what each of them has to do, helps with a better communication among the two, thus never having one person do most of the work. They also talked about their main line of communication is through the internet and they worked along the idea of a navigator-driver style of working. This style of work, particular aimed up pair group work, allows them to help each other when in need of help and puts one person doing work ahead of time, with the other following up from previous work. This style to me, helps them strengthen their communication with one another and works great with their project. For my group's project though, it wouldn't work that well as it's a team of six and its not easy to help each other as the line of work differs (coding, interface, shaders, etc.).

Group 3 - the Bus Stop of the Future

The last group for communication, doing the bus stop project, presented their information through a work cloud, outlining areas they use to communicate. They talked about in their presentation of what communication areas they used, which included emailing and listening. Listening as in talking with the person in front, and listening back to their response. This communication area may be obvious and simple, but is still one of the biggest factors to communication is what I think. This is because the person you want to talk to, is right there, meaning you can ask any question you have or answer any questions. This would also be done without the hassle of waiting for a response from the person (e.g. emailing, waiting for a response you don't know when you'll receive). They talked about the 10 levels of intimacy of communication, mainly based around emailing and Facebook messaging. Overall, their presentation was very informative towards their topic, and I found the listening tool of communication a great addition to their presentation.

Database files - Naming convention and Planning Critical Reflection

This week looking at the information contained of FileMaker file for the church database in more detail, the information or naming convention doesn't match to the ones shown in the sketchup model. I've exported the information into 2 excel files to be translate its information better and be more accessible to the group. 1 file for the description of components within the church, its date, cost, campaign and location. The other excel file is for the sketchup model file, as it lists every component within the church with its corresponding campaign ID, code, label, level, sequence and label. This file will be a base for renaming the components within the sketchup model to match its naming convention of the database so that it'll link up once we reach that stage of our work.

The naming convention would be the building name, campaign ID then course ID. e.g. CERSE_2a_BAS With the information given from the database, this style of naming the components is more efficient because the components are basically divided into campaigns and courses (2a, 2b, 2c, etc.) Trying to get a good understanding of what certain categories mean in the database, I've taken a look into each and every category, and I've noticed the categories LABEL_ACTION and SEQ will help us greatly in developing our interface, in terms of displaying the information and connecting them. LABEL_ACTION relates to the LABEL category. LABEL is the description of the element while LABEL_ACTION is an action of how to represent that LABEL. E.g. these actions can be graphic or text or others. Knowing this, the interface can be developed in displaying a graphical image of an element or related using the information of LABEL_ACTION and LABEL given. Also, SEQ is the order of information to be displayed in a searching pane, when the user wants to search something specific.

The group presentation done for planning by the Bus stop group looked very detailed and planned out. They included many types of management systems and plans that would relate to their project and plan out each stage of the process of their project. It included a project plan, giving concise and planned out information of the goals set out for the project, a risk management plan, time management plan and cost management plan. For our group (Gothic architecture), we didn't create a cost management plan as it didn't really relate to our work, but creating a time management and project plan (which we did) really does organise the group in its goals and decisions which is important in the long run. The risk management plan is like for backups and plans in case of emergencies, and I find this very useful to have because things don't always go the way you want it to in a project, especially working under a client where things are constantly changing. Since this group is doing the bus stop project, having a cost management plan is very useful for them, as it allows you to have a controlled amount of what areas you are spending on, while also knowing you have the right amount for other expenditures in the future.

As for the presentation done by the Aerial rope way project, they presented a strategic and tactical planning towards their project. They planned out various stages of their project, allocating each of their members specific tasks that needs to be done in a certain time frame. So it's pretty much focused primarily on Gantt charts and project planning. I see this as very advantageous to them in relation to the project they're doing. There are many different tasks involved such as modelling, animation, environment creation, etc., and by creating stages of goals to reach, it motivates the team members to reach them.

Java scripting and Unity

For this week, I've looked into tutorials of java scripting within Unity and tried to grasp my head around it. This would be useful in creating a script where it can connect the database info of the church to the model and the interface. I intend to study more on java scripting in Unity in order to create a way to connect the Filemaker file that contains the database information to Unity.

So far I've looked into the basics of java scripting in Unity. This script involves creating a button that is able to be clicked and respond with a message.

This shows the information contained in the database in FileMaker Pro. Looking at it, the information can be easily categorised into Location and Campaign which we could use as an option in connecting this info to the model itself.