This section will present the Breiny application’s user interface and the available interactions with it, features which will be evaluated by the users. Following the requirements for extensibility, modularity and flexibility, the subsequent visible objects were separated into several user controls.
Category: DIS 2 Lab
26 posts
Be careful when copying information from this article! The paper is already published and you will be charged with plagiarism! My thesis proposes several approaches as result of the research questions. Their validity of each approach should be verified by allowing users to interact with a prototype built to fulfill all the proposed solutions. Hence, the final users will prove the correctness of this thesis approaches. The implemented prototype will be a brainstorming supporting application. Because my thesis studies brainstorming on a tabletop, I will choose the Microsoft Surface as the underlying hardware because it supports multitouch and multiuser experience. […]
is article presents the system architecture and the underlying decisions that were taken to achieve the above requirements. The system requires a repository for sessions, a repository for Brainstorming items and a native Windows application for achieving the baseline of desired features. Thus, a distributed client – server architecture is considered, exemplified here.
In this section the application requirements will be presented. They are split into functional and non-functional ones. The first refers to all the features needed to be implemented, while the second category refers to performance, extensibility and scalability of the system.
There are two sets of features that must or can be implemented: the first ones which regulate the brainstorming activity as a set of rules; the second ones add productivity to the process, enabling additional scenarios that improve the user experience.
Latest additions :sounds in our application, allowing user to get auditive feedback, background and confirmation for hit sounds for improving the User Experience, creating an immersive experience who tries to transpose the user into the real wood atmosphere, self generating levels, allowing users to improve themselves beyond our ideas about their possibilities: the user gets 60 seconds levels in which he has to hit more and more animals as he becomes better in targeting ( and in ball retrieval :-) ), changed the aspect ratio of the game from 4:3 to 16:9 to bette use the whiteboard's surface
Since last week the Flash application changed- I added support for numerical keys for hitting. We mapped the numerical keys 1 to 6 to the 6 animals positions that can be hit. This way, it is enough to press a key to simulate the throw of a ball.The reason behind this application architectural change is that we needed an smart way to simulate the sensors that were hit, without actually having the entire setup in our workplace.
This week we work also on the User Interface - the Flash GUI. It was challenging sinceI haven't previous experience in creating games in Flash. The application creates 4 spots in the bottom of the scene and 2 in the top to show randomly an new animal each time one is hit. This areas are hit areas designed to respond to phisical sensors placed on the back of the board on which the Flash Game will be projected.
A game should not have only a great idea, but also nice graphical interface. For this, we created an immersive forest environment where the user to be able to ‘hunt’ some animals. Underneath is the background of the application:
From the last lab we had a week of accomplishments: we set our hardware to Arduino platform completed on Monday a little programming and testing of the hardware platform decided the final idea of the game and also set Adobe Flash as our interface and display application The idea of the game remains as presented a week ago. We will have a screen acting as a pressure sensor (composed from at least 9 sensors to be more precise about the user’s hit point).The Arduino board will be linked with the sensors and will provide via USB the signals to the […]
In a previous post I explained the facts that forced us to re-think our project idea. Basically, our cool idea of an iPhone tied to a skateboard to create a exertion game require too much programming time. So we searched another idea who is required to be simpler and easy to be implemented in the remaining time. So we got us a round table (the ones in BIT cafeteria are the best!) and put our minds to work. First step : Use the Initial Design Techniques – Brainstorming (as learned in DIS I) Our goal: collect as many ideas of […]
In the last meeting, our tutors, Mr. Heller and Mr. Karrer, shared with us some of their experience using the sensors which made us reconsider the project idea. The ideaBecause of the new introduction in iPhone programming and the rich set of sensors of this device, our project envisioned an iPhone attached to the board in order to track the skateboard movements. The data pulled out by the iPhone is the initial acceleration (the one when the user starts riding with the board), and lateral or up-down acceleration when he does turns or jumps with the board. First, the iPhone […]