I. Overview

The game is about fighting against pathogen using immunity mechanism.

The pathogen and immunity mechanism are represented by towers and enemies.

II. Purpose

The reason why this game is created is to educate people in general how immunity inside body fought against pathogen in simple representation.

III. Mechanism

Build towers to counter pathogen.

There is life system. Once it reached zero, it is game over, and the game will be restarted from the beginning  .

Towers are upgradeable in order to to face more enemies.

Every wave increase the number of enemies.

Enemies are divided into 3:

– Bacteria (Weakness: Neutrophil)

– Parasite (Weakness: Eosinophil)

– Virus (Weakness: B-Cell)

IV. Screenshot

Link

Felix Anggara:

Mechanism & Artwork

I. Overview

In current era, video games have become one of the main commodity of digital media products. Many people with his/her laptop, smartphones, PCs, and consoles play games almost anywhere, anytime, and anyhow. Despite of this, many of the currently available games are not actually educative, especially for kids. It is competitive, but unsuitable for kids because kids needs to learn about reality, not fantasy. But, how about combine the essence of knowledge from reality with video games? Maybe it sounds boring because many of the games that adopts both of the concepts are either in form of quiz or with boring game play. So, We’ve come up with the idea of doing it, but with more gamer style. So, we’ve come up with the idea about teaching about body immune by using tower defence game. Hopefully, by combining tower defence game and knowledge about body immune, the players will not only enjoy just for the game play, but also it can increase their understanding about how body immune system counters pathogen.

II. Goal

• Create a game that can be enjoyed both as a game and educational media
• Designs game sprites and UI that is friendly for every ages
• Educate people about ‘how body immune system counters pathogen’ in the form of tower defence game

III. Team

1. Felix
2. Handy
3. Alfi

Introduction & Purpose

Database is already integrated in our lifestyle. When we store something, we rely on database so we can retrieve it when we needed through internet. In business, database is used for customer service, market analysis, transactions, etc.. But, can we use database for pharmacy shop? The answer is yes. But, pharmacy business is a bit more complicated than regular business because pharmacy business is positioned at the boundary between legal and illegal business. But can it (transaction through database) actually be controlled so the business still inside the legal boundary? Actually, yes for system, but not really for reality. But, the data and the restriction system inside the database can prevent them from happen by accountability feature that database offered that can prove if something illegal happened (even though it still need investigation to check that). Because of that reason, we created the Pharmacy Transaction System to control and record the transaction to ensure accountability and prevent the illegal transaction for the medicine that distribution supposed to be tightly restricted.

Final ER Diagram

Explanation

Before I explained the changes from the concept ER from the proposal, I should give tell one part of the value that is actually unnecessary (only for testing):

1. Comment part at shopkeeper is actually for debug testing

Now, I will explain the changes that our group made regarding the database design:

1. We added branch to meet the requirement of multiple store. Because of that, we modified ‘pharmasist’, ‘shopkeeper’, and ‘product’ to meet the requirement. For product, we forced to add redundancy to anticipate the case where there are similar product but at different branch. If these product are counted as one type, there will be a problem when the real item stock is empty at certain branch, because the product stock data is the sum of stock of every branches, not per branch, which is leads to inconsistency of product availability.

2. To accommodate the detailed automatic transaction record (‘invoice’ and ‘cart’) to ensure accountability, we added a boolean switch just in case if the product is no longer available, but there are already transaction that involved the product, or if the shopkeeper or the pharmacist that involved in the transaction no longer work at the pharmacy shop. If that happened, we can’t just delete it. But, we’ve got another option to disable it for good to prevent sabotage if the former staff wants to tamper with the system.

But still, there are things that we should change:

1. We should add total price in cart just in case of price changes, so the actual total price won’t be affected by the changes (ensure the data consistency)
2. In terms of security, we should add countermeasure just in case if there is a SQL injection attack
3. Find the way to reduce redundancy

App Picture (Non-Admin)

Team:

Felix Anggara – 2101693851

Alfi Redzwan – 2101693574

Karuna – 1901520233

Responsiblility (Felix Anggara):

• Project Lead
• Logical
• Debugging
• Apps (Non-Admin)

Download

FULL REPORT

Overview :

A database design for managing the transaction that occur in a pharmacy. The purpose is to make the management become easier, more accountable, and up-to-date in term of information. Also, the control of the drug transaction become more strict due to the restriction level of the drug is managed in digital form and harder to be modified.

Goal :

• Database that can handle transaction and item stock management
• Easy to be used UI for most people

Early DB Concept :

Team :

• Karuna
• Alfi Mohamed Redzwan
• Felix Anggara

Role (Felix Anggara) :

• Coding (UI)
• Logic Solving

Link :

https://docs.google.com/document/d/1UrMqIU0K7OtVFmFV58T3gn_SU4AEseHgs-BSp4s5QQs