Với các dạng đề tài khác giải pháp, nghiên cứu, phần mềmđặc thù, v.v., sinh viên dựa trên cấu trúc và hướng dẫn của báo cáo này để đềxuất và trao đổi với giáo viên hướng dẫn để thiết kế
GIỚI THIỆU ĐỀ TÀI
Đặt vấn đề
Khi đặt vấn đề, sinh viên cần làm nổi bật mức độ cấp thiết, tầm quan trọng và/hoặc quy mô của bài toán của mình.
Gợi ý cách trình bày cho sinh viên: Xuất phát từ tình hình thực tế gì, dẫn đến vấn đề hoặc bài toán gì Vấn đề hoặc bài toán đó, nếu được giải quyết, đem lại lợi ích gì, cho những ai, còn có thể được áp dụng vào các lĩnh vực khác nữa không. Sinh viên cần lưu ý phần này chỉ trình bày vấn đề, tuyệt đối không trình bày giải pháp.
CHƯƠNG 1 GIỚI THIỆU ĐỀ TÀI
Mục tiêu đề tài
Sinh viên trước tiên cần trình bày tổng quan về các sản phẩm hiện tại/về nhu cầu của người dùng (đối với đề tài ứng dụng) Tiếp đến, sinh viên tiến hành so sánh và đánh giá tổng quan các sản phẩm/nghiên cứu này.
Dựa trên các phân tích và đánh giá ở trên, sinh viên khái quát lại các hạn chế hiện tại đang gặp phải Trên cơ sở đó, sinh viên sẽ hướng tới giải quyết vấn đề cụ thể gì, khắc phục hạn chế gì, phát triển phần mềm có các chức năng chính gì, tạo nên đột phá gì, v.v.
Trong phần này, sinh viên lưu ý chỉ trình bày tổng quan, không đi vào chi tiết của vấn đề hoặc giải pháp Nội dung chi tiết sẽ được trình bày trong các chương tiếp theo, đặc biệt là trong Chương 5.
Sinh viên lưu ý không giải thích hoặc phân tích chi tiết công nghệ/thuật toán trong phần này Sinh viên chỉ cần nêu tên định hướng công nghệ/thuật toán, mô tả ngắn gọn trong một đến hai câu và giải thích nhanh lý do lựa chọn.
Phạm vi và đối tượng người chơi
Về phạm vi (scope) và đối tượng người chơi hướng đến (target audiences), đối với đề tài trò chơi, sinh viên cần chỉ ra được trò chơi của mình hướng đến đối tượng người chơi như thế nào Ví dụ, giữa một trò chơi dạy về sinh học cho một đứa trẻ mầm non và một trò chơi tương tự dành cho sinh viên đại học có sự khác biệt to lớn.
Who will play it? This is no ordinary section, so don’t settle for a simple “for children” description, for example There are endless ways to "classify" gamers, and you must explore this Comment on how it will appeal to each category and try not to leave anyone out; they might share little in common with your product, but they still share something.
For example Right: Turret Defense will appeal to male gamers of ages 15 – 25 who typically play FPS and RTS PC titles In particular, fans of Sci-Fi themed games, movies, and books will be immediately attracted to Turret Defense’s space adventure setting and theme Turret Defense will have an ESRB rating of T (Teen) for ESRB Content Descriptor of Violence, suitable for ages 13 or older To conform to the wishes of the publisher, Turret Defense will not use blood or any other content that would lead to further ESRB Content Descriptors related to violence Wrong: Turret Defense will appeal to a large audience Based on the experience of similar games, it should be a huge financial success in the video games market We plan to advertise it heavily with ads on games-related websites with huge traffic (“A large
CHƯƠNG 1 GIỚI THIỆU ĐỀ TÀI audience” isn’t a valid fanbase, and it doesn’t explain why they would enjoy it.
No mention of the ERSB rating or whether the game has any age-restricted material.)
Another good example: OrBlitz is expected to receive an ESRB rating of Every- one The main target market will be puzzle game fans, but the game’s many original aspects will attract a wider audience, including people that prefer to buy action- based games Real time strategy game fans could also be interested in the game for its tweakability and other similarities with RTS games. Because of the lack of graphic violence and the intuitive interfaces, this game can target women as well as men The game is relatively cute and colorful, and is expected to appeal to both American and Japanese audiences due to the content in it.
Notice all the classifications in the example: gender, age, nationality, and genre Keep in mind that many more categories may arise depending on your game Pre- dictions on the ESRB rating are also welcomed, so some restrictions regarding violence, sexual content and language should be addressed if needed.
Định hướng giải pháp
Từ việc xác định rõ nhiệm vụ cần giải quyết ở phần 1.2, sinh viên đề xuất định hướng giải pháp của mình theo trình tự sau: (i) Sinh viên trước tiên trình bày sẽ giải quyết vấn đề theo định hướng, phương pháp, thuật toán, kỹ thuật, hay công nghệ nào; Đối với đề tài trò chơi thì bổ sung thêm thể loại của trò chơi là gì;
Tiếp theo, (ii) sinh viên mô tả ngắn gọn giải pháp của mình là gì (khi đi theo định hướng/phương pháp nêu trên); và sau cùng, (iii) sinh viên trình bày đóng góp chính của đồ án là gì, kết quả đạt được là gì.
Sinh viên lưu ý không giải thích hoặc phân tích chi tiết công nghệ/thuật toán trong phần này Sinh viên chỉ cần nêu tên định hướng công nghệ/thuật toán, mô tả ngắn gọn trong một đến hai câu và giải thích nhanh lý do lựa chọn.
Bố cục đồ án
Phần còn lại của báo cáo đồ án tốt nghiệp này được tổ chức như sau Chương 2 trình bày về v.v.
Trong Chương 3, em/tôi giới thiệu về v.v.
Chú ý: Sinh viên cần viết mô tả thành đoạn văn đầy đủ về nội dung chương.
Tuyệt đối không viết ý hay gạch đầu dòng Chương 1 không cần mô tả trong phần này.
Ví dụ tham khảo mô tả chương trong phần bố cục đồ án tốt nghiệp: Chương
*** trình bày đóng góp chính của đồ án, đó là một nền tảng ABC cho phép khai phá và
CHƯƠNG 1 GIỚI THIỆU ĐỀ TÀI
4 tích hợp nhiều nguồn dữ liệu, trong đó mỗi nguồn dữ liệu lại có định dạng đặc thù riêng Nền tảng ABC được phát triển dựa trên khái niệm DEF, là các module ngữ nghĩa trợ giúp người dùng tìm kiếm, tích hợp và hiển thị trực quan dữ liệu theo mô hình cộng tác và mô hình phân tán.
Chú ý: Trong phần nội dung chính, mỗi chương của đồ án nên có phần Tổng quan và Kết chương Hai phần này đều có định dạng văn bản “Normal”, sinh viên không cần tạo định dạng riêng, ví dụ như không in đậm/in nghiêng, không đóng khung, v.v.
Trong phần Tổng quan của chương N, sinh viên nên có sự liên kết với chương N-1 rồi trình bày sơ qua lý do có mặt của chương N và sự cần thiết của chương này trong đồ án Sau đó giới thiệu những vấn đề sẽ trình bày trong chương này là gì, trong các đề mục lớn nào.
Ví dụ về phần Tổng quan: Chương 3 đã thảo luận về nguồn gốc ra đời, cơ sở lý thuyết và các nhiệm vụ chính của bài toán tích hợp dữ liệu Chương 4 này sẽ trình bày chi tiết các công cụ tích hợp dữ liệu theo hướng tiếp cận “mashup” Với mục đích và phạm vi của đề tài, sáu nhóm công cụ tích hợp dữ liệu chính được trình bày bao gồm: (i) nhóm công cụ ABC trong phần 4.1, (ii) nhóm công cụ DEF trong phần 4.2, nhóm công cụ GHK trong phần 4.3, v.v.
Trong phần Kết chương, sinh viên đưa ra một số kết luận quan trọng của chương Những vấn đề mở ra trong Tổng quan cần được tóm tắt lại nội dung và cách giải quyết/thực hiện như thế nào Sinh viên lưu ý không viết Kết chương giống hệt Tổng quan Sau khi đọc phần Kết chương, người đọc sẽ nắm được sơ bộ nội dung và giải pháp cho các vấn đề đã trình bày trong chương Trong Kết chương, Sinh viên nên có thêm câu liên kết tới chương tiếp theo.
Ví dụ về phần Kết chương: Chương này đã phân tích chi tiết sáu nhóm công cụ tích hợp dữ liệu Nhóm công cụ ABC và DEF thích hợp với những bài toán tích hợp dữ liệu phạm vi nhỏ Trong khi đó, nhóm công cụ GHK lại chứng tỏ thế mạnh của mình với những bài toán cần độ chính xác cao, v.v Từ kết quả nghiên cứu và phân tích về sáu nhóm công cụ tích hợp dữ liệu này, tôi đã thực hiện phát triển phần mềm tự động bóc tách và tích hợp dữ liệu sử dụng nhóm công cụGHK Phần này được trình bày trong chương tiếp theo – Chương 5.
KHẢO SÁT VÀ PHÂN TÍCH YÊU CẦU
Khảo sát hiện trạng
Thông thường, khảo sát chi tiết về hiện trạng và yêu cầu của phần mềm sẽ được lấy từ ba nguồn chính, đó là (i) người dùng/khách hàng, (ii) các hệ thống đã có,
(iii) và các ứng dụng tương tự Sinh viên cần tiến hành phân tích, so sánh, đánh giá chi tiết ưu nhược điểm của các sản phẩm/nghiên cứu hiện có Sinh viên có thể lập bảng so sánh nếu cần thiết Kết hợp với khảo sát người dùng/khách hàng (nếu có), sinh viên nêu và mô tả sơ lược các tính năng phần mềm quan trọng cần phát triển. Đối với đề tài game This is a key subsection of your document Here you must compare your game to others already developed It is important to give a small description of the game being compared to, and point out the similarities between both This is an excellent opportunity to expand the comparisons that were already made across the GDD and give the reader a better picture of what the game will actually be.
At the end, summarise your product’s strong points and convince the reader why your product would sell despite its competitors This is the trickiest part,because you must pick good opponents, otherwise the reader just won’t know what you are talking about, and still keep your game’s image shining; therefore good writing is crucial Your ‘adversaries’ also help with the notion of how big your market can be.
Mục đích của trò chơi
Pedagogical objective(s) for educational games, training goal, or intended social impact If it is addressing a problem, explain what that problem is (for example, students have a hard time )
Định hướng sử dụng
How the game is to be inserted into a pedagogical scenario or how will it be
6 used in training, therapy, rehabilitation, etc You should distinguish between a game that is stand alone, a supplement to a class, or working with an instructor
CHƯƠNG 2 KHẢO SÁT VÀ PHÂN TÍCH YÊU CẦU
Cơ sở của định hướng sử dụng
Is there research that shows that this is apt to be successful? Are there are other games or applications that take a similar approach? If this is an experiment to see if it will work, why does the researcher believe that it might?
CÔNG NGHỆ SỬ DỤNG
(optional) Tùy chọn Sinh viên có thể bỏ qua Chương này nếu ứng dung/trò chơi của sinh viên không sử dụng công nghệ/thuật toán gì nổi bật.
Chương này có độ dài không quá 10 trang Nếu cần trình bày dài hơn, sinh viên đưa vào phần phụ lục Chú ý đây là kiến thức đã có sẵn; SV sau khi tìm hiểu được thì phân tích và tóm tắt lại Sinh viên không trình bày dài dòng, chi tiết. Lưu ý: Sinh viên tuyệt đối không trình bày các hướng dẫn sử dụng công cụ, hướng dẫn lập trình với API trong mục này Nếu muốn, sinh viên có thể đưa các hướng dẫn lập trình, thiết lập hoặc sử dụng công cụ này vào phần Phụ lục.
Với đồ án ứng dụng, sinh viên để tên chương là “Công nghệ sử dụng” Trong chương này, sinh viên giới thiệu về các công nghệ, nền tảng sử dụng trong đồ án. Sinh viên cũng có thể trình bày thêm nền tảng lý thuyết nào đó nếu cần dùng tới.
Lưu ý đối với đề tài game: Sinh viên không trình bày về các công cụ lập trình như Unity, hay các công cụ thiết kế như 3DS Max, Photoshop trong chương này.
Với đồ án nghiên cứu, sinh viên đổi tên chương thành “Cơ sở lý thuyết” Khi đó, nội dung cần trình bày bao gồm: Kiến thức nền tảng, cơ sở lý thuyết, các thuật toán, phương pháp nghiên cứu, v.v.
Với từng công nghệ/nền tảng/lý thuyết được trình bày, sinh viên phải phân tích rõ công nghệ/nền tảng/lý thuyết đó dùng để để giải quyết vấn đề/yêu cầu cụ thể nào ở Chương 2 Hơn nữa, với từng vấn đề/yêu cầu, sinh viên phải liệt kê danh sách các công nghệ/hướng tiếp cận tương tự có thể dùng làm lựa chọn thay thế, rồi giải thích rõ sự lựa chọn của mình.
Lưu ý: Nội dung ĐATN phải có tính chất liên kết, liền mạch, và nhất quán Vì vậy, các công nghệ/thuật toán trình bày trong chương này phải khớp với nội dung giới thiệu của sinh viên ở phần trước đó.
Trong chương này, để tăng tính khoa học và độ tin cậy, sinh viên nên chỉ rõ nguồn kiến thức mình thu thập được ở tài liệu nào, đồng thời đưa tài liệu đó vào trong danh sách tài liệu tham khảo rồi tạo các tham chiếu chéo (xem hướng dẫn ở phụ lục A.7)
THIẾT KẾ TRÒ CHƠI
Tổng quan trò chơi
•Tên trò chơi – This is more important than you think even in a non- commercial environment It sets the tone for the game’s use and gives it an identity.
•Bản sắc của trò chơi - Game Identity/Mantra: List your single sentence de- scription of the game that you will use to guide design decisions (Example: Stylized action platformer about a meatball fighting the dinner table.)
•Trụ cột trò chơi - Game Pillars: List up to 3 words/phrases that convey the feeling or emotion you want the player to experience (Example: Fast. Action- packed Mayhem.)
•Khẩu hiệu – tag line: is a statement or phrase that brands your game. Famous tag lines are “Just do it! “Got milk?” “The King of Beers” Or from the video game world: Dark Souls: “Prepare to Die”, Dead Space: “Only the Dead Sur- vive”, Deus Ex “Trust no one Question Everything”, Pokémon:
•Phong cách đồ họa - Once you’ve explained how to play your game, it’s im- portant to show what your game will look like and what kind of art is behind it, since that will influence how the elements of your game’s universe will coex- ist, affecting the emotions of the players This is a crucial point in the game’s marketing because it shows the appearance of the game and the feelings it will pass to the player.
Lối chơi
This section would tell a player what to expect Not a lot of detail (that comes later).
•Ấn tượng ban đầu - (First minutes) This is a subsection of the Gameplay sec- tion, and it exposes what the player will see in the game when it has just fin- ished loading It exposes the actions and reactions between the game and the players during this interval, helping readers understand the game’s progress throughout the gameplay and giving a better idea of how to play it. It’s also an important subsection, since it will determine whether or not the game is fun.
•Mục tiêu – What are the objectives of the game? Is it to reach a destination, retrieve the chalice, accrue the most money, or solve a puzzle in the fastest
CHƯƠNG 4 THIẾT KẾ TRÒ CHƠI
•Diễn tiến và luồng trò chơi – (Progression and game flow) How does the game flow for the game player? Is there an overall scoring and objective for the game or is it a progression of levels? This is a more detailed subsection of the Gameplay than the First Minutes It describes all the options that players can choose while they’re playing It’s a kind of flowchart that shows which reaction each option has, giving a picture of the game as a whole. Generally it shows a flow of screens (e.g from the “Main menu” screen it goes to the “Select level” screen), but you can also put actions and consequences in it (e.g if the player chooses the “Mage” character, all the backgrounds will have a “magical” feeling) It literally explains the way that the game flows, as the name suggests.
•Nhiệm vụ, thử thách hoặc cấu trúc puzzle
(Hướng dẫn viết và ví dụ) First minute example It’s interesting for you to de- scribe what the player’s reaction is going to be like as soon as the game loads, such as describing whether they can start playing right away or if they can navigate through menus to change some options beforehand, whether the player will have to learn the controls by trial and error or a tutorial will be presented, whether all stages will be available at the get-go or if they will have to unlock them in pro- gression, and so on Given you have already planned some stages ahead, you could narrate a short run of the player clearing a stage, describing the enemies and/or puzzles they had to go through in said stage Right: After the title screen the player is presented with a list of games they can join and an option to create a new one After selecting the option to create a new game, a list of predefined levels appears on the right of the screen ( ) After the settings are adjusted, three other players join, and the game begins A timer counts down from five while the players get ready, using the small amount of money they start with to place a few blocks As a simple beat plays in the background, the board rotates around the middle of the screen, revealing the layout of the level ( ) The player’s goals are on each corner of the board ( ) As soon as the countdown reaches zero, ‘Go!’ is displayed in the middle of the screen and the orbs start falling from the cloud, creating havoc in their path ( ) The player quickly places a stone corner block on the edge of the level and the orb bounces off it,only to end up in the player’s goal followed by a familiar cashier sound The player’s score and cash are updated to 200, and they start going through the blocks they can now place ( ) Wrong: The game begins with the players facing each other in opposite corners Player 1 decides to use all his money from the get-go and wins the game by using well-placed stone blocks to earn points.
CHƯƠNG 4 THIẾT KẾ TRÒ CHƠI
Gameflow Example A nice complement to the “First minute” would be the
“Game Flow” or a game design flowchart, which is usually represented as a flowchart or game flow summary In contrast to the previous subsection, this one won’t focus on the first impression but rather give an overview of the whole picture, showing step-by-step which actions the player can take from the moment the game is loaded to when the player hits the “exit button”, i.e ends the gaming session—including the gameplay itself in a somewhat high concept Remember to be as specific as possible when creating your game design flowchart.
(Example from Drexel Game Design’s Scavenger Hunt GDD.) Creating a very simple game design flowchart like the one below will not help the creation of the game.
(Nothing THIS simple Include, at least, all the screens that the player will run
CHƯƠNG 4 THIẾT KẾ TRÒ CHƠI
Cơ chế của trò chơi
(Key Section) - These are topics that should be covered if relevant All games are different and not everything applies Consider this a checklist to help you capture all that is important It should be complete enough that someone could build a clone of your game based on this detail.
•Luật – Rules: include both implicit and explicit rules.
•Mô hình thế giới của trò chơi Think of it as a simulation of a world, how do all the pieces interact? If it is a puzzle game, there may be no universe to discuss, but there is the layout and the structure of the puzzle Included in the universe are
– Physics – How does the physical universe work? If there are no physics, do not try to create them.
– Economy – What is the economy of the game? How does it work? The economy incudes the items that the player is trying to collect as well as a world economy How does a player earn or lose these items?
•Các hành động của nhân vật These include
– Character movement – How does the character move?
– Objects – how to pick them up and move them Are there key objects of importance that should be identified here? Is there an inventory that the player maintains or are all interactions transitory?
– Actions – What else can the player (or character) do? Include any in- game switches and buttons that are used, interacting with objects, and what means of communication are used
– Combat – If there is combat or even conflict, how is this specifically mod- eled? What are the differences in weapons?
•Luồng màn hình – How each screen is related to every other and a description of the purpose of each screen
•Các tùy chọn trò chơi - What are the options and how do they affect game play? - Replaying and saving - Cheats and Easter Eggs if there are any
•Phản hồi cho người chơi– How can the player tell if they are doing well? Is there mechanisms to tell them what they are doing wrong?
CHƯƠNG 4 THIẾT KẾ TRÒ CHƠI
Điều khiển
Stating which buttons/keys do what can be troublesome in the case where a single button performs more than one action (e.g the ‘A’ button in any 3D Zelda) Start by including a simple picture of a controller or a keyboard with each button highlighted with their function in a more general sense After that, if your game has advanced combos or something similar to that, explain them carefully, stating under which conditions each combo is “activated”.
Hình 4.3: Image from CrunchTime Games Inc’s Shred Nebula document
Cốt truyện
(optional) If you have a puzzle game, there is probably no backstory or story.
As soon as you add an avatar of any sort, you have a story It may be as simple as who the character is.
•Backstory If there is no plot or narrative in the story but you need to under- stand the background, that is a backstory The backstory can also be setting the stage for the story that is going to unfold.
•Plot elements There are multiple patterns of a plot: the 3-act play, the hero’s journey, episodic, Use one of the models to describe the story of the game.
•Game story progression Explain how the progression of the plot is
CHƯƠNG 4 THIẾT KẾ TRÒ CHƠI
13 exposed to the player Remember that there are different approaches to the narrative:
CHƯƠNG 4 THIẾT KẾ TRÒ CHƠI
14 how it is exposed, who is telling it and the sequence that things happen If you are using cut scenes to progress the story, describe the cut scenes in detail.
Thế giới game
(optional) Describe the general look and feel of world Of particular importance is whether the world is broken up into different areas that are relevant to the game If it is, describe how they are connected, how the player moves between them, and how they relate to levels.
Nhân vật và kẻ địch
Player avatar Indicate if the user has the ability to define their own avatar and what options they are able to define List of characters in the game: identify which are playable and which are not If there are characters that are relevant to the game but never seen, be sure to include them Include enemies and opponents If the ene- mies are classes only, that is fine Identify the class and if there is a specific number of them, etc For each character, give their backstory,personality, appearance and abilities Explain the relevance of each player to the story and their relationship to other characters If certain of the characters only appear in certain levels or areas, explain that as well This is also the place to describe any AI that is used for these characters.
Màn chơi
General description of how levels are used If they are very similar, the detailed level descriptions need not be very long For each level, describe what additional skills or information they are learning? For each level, give a synopsis of the level and the objectives of that level If there is introductory material that is required, how is it provided? There are two key aspects to cover in each level: the game play changes and the content changes In some cases, both change; in other cases, only one does For example, as levels progress, you may give the player less hints so that they learn the content better and you may increase the frequency of enemies For each level, describe how the map changes and whether it is a crafted or proce- durally generated map If it is procedurally generated, what are the constraints or requirements that put on it? Is there a training level or a playable tutorial? How is the player’s progress assessed at the end of the level? Are they allowed to replay levels? Does progression through the levels require a specific level of accomplish- ment (that is are subsequent levels being unlocked)?
Now let’s pretend we have a typical 2D platformer One of the core elements of the game is the stages the player has to go through It’s important that each stage feels unique so the player won’t feel as if they’re just repeating the same
CHƯƠNG 4 THIẾT KẾ TRÒ CHƠI
CHƯƠNG 4 THIẾT KẾ TRÒ CHƠI
16 and over again On the other hand, the player should still be familiar with the flow of the stage, e.g if there’s always a checkpoint somewhere halfway through it, or some collectible items along the way.
What are the different types of enemies, terrains, doodads, and power-ups, and do they allow the level designers to come up with many different stages? You could present some beta stage diagrams to illustrate how will they be carried out. Example:
UI
What is the visual system? Specifically, If there is a HUD, what is on it, how is it displayed and how is it accessed? What menus are included and how are they navigated? What is the camera model?
Control System – How does the game player control the game? What are the specific commands? Audio, music, sound effects Game Art – intended style HelpSystem Settings – what can the user change? Feedback for the Player – How can the player tell if they are doing well? Is there mechanisms to tell them what they are doing wrong?
CHƯƠNG 4 THIẾT KẾ TRÒ CHƠI
The head-up-display (HUD) is the in-game interface the player will have when playing the game Rather than in-game menus like settings or inventory screens, this refers specifically to the floating windows and bars which don’t normally in- teract with the game and serve an information-only purpose This includes health bars, mini-maps, time counters, equipped items and their amounts, money, etc. Al- though the size of the HUD will vary according to the game type (MMORPGs and RTSs will have big HUDs, while side-scrollers and puzzles will have very small ones), keep in mind that an HUD shouldn’t occupy too much of the screen.
THỰC NGHIỆM VÀ ĐÁNH GIÁ
Tổng quan kỹ thuật
Technical aspects of the game These consist of a series of game data, such as the system requirements on which it will play, the framework in which it was developed, the method or algorithm it was based on, and the maximum number of elements that can be rendered on screen The graphical technical aspects consist of software used, modeling type, art style and others according to these topics.
The system requirements are the necessary computer settings for the game to be played, like the size it occupies on the computer’s HD and how much RAM is needed.
Thiết kế kiến trúc
5.2.1 Lựa chọn kiến trúc phần mềm
Mục này có độ dài từ một đến ba trang Sinh viên cần lựa chọn kiến trúc phần mềm cho ứng dụng của mình như: kiến trúc ba lớp MVC, MVP, SOA, Microser- vice, v.v rồi giải thích sơ bộ về kiến trúc đó (không giải thích chi tiết/dài dòng).
Sử dụng kiến trúc phần mềm đã chọn ở trên, sinh viên mô tả kiến trúc cụ thể cho ứng dụng của mình Gợi ý: sinh viên áp dụng lý thuyết chung vào hệ thống/sản phẩm của mình như thế nào, có thay đổi, bổ sung hoặc cải tiến gì không Ví dụ, thành phần M trong kiến trúc lý thuyết MVC sẽ là những thành phần cụ thể nào (ví dụ: là interface I + class C1 + class C2, v.v.) trong kiến trúc phần mềm của sinh viên.
Sinh viên vẽ biểu đồ gói UML (UML package diagram), nêu rõ sự phụ thuộc giữa các gói (package) SV cần vẽ các gói sao cho chúng được phân theo các tầng rõ ràng, không được sắp đặt package lộn xộn trong hình vẽ Sinh viên chú ý các quy tắc thiết kế (Các gói không phụ thuộc lẫn nhau, gói tầng dưới không phụ thuộc gói tầng trên, không phụ thuộc bỏ qua tầng, v.v.) và cần giải thích sơ lược về mục đích/nhiệm vụ của từng package SV tham khảo ví dụ minh họa trongHình 5.1
CHƯƠNG 5 THỰC NGHIỆM VÀ ĐÁNH GIÁ
Hình 5.1: Ví dụ biểu đồ phụ thuộc gói
5.2.3 Thiết kế chi tiết gói
Sinh viên thiết kế và lần lượt vẽ biểu đồ thiết kế cho từng package, hoặc một nhóm các package liên quan để giải quyết một vấn đề gì đó Khi vẽ thiết kế gói, sinh viên chỉ cần đưa tên lớp, không cần chỉ ra các thành viên phương thức và thuộc tính SV tham khảo ví dụ minh họa trong Hình 5.2.
Sinh viên cần vẽ rõ ràng quan hệ giữa các lớp trong biểu đồ Các quan hệ bao gồm: phụ thuộc (dependency), kết hợp (association), kết tập (aggregation), hợp thành (composition), kế thừa (inheritance), và thực thi (implementation) Các quan hệ này đều đã được minh họa trong 5.2.
Sau khi vẽ hình minh họa, sinh viên cần giải thích ngắn gọn về thiết kế của mình.
CHƯƠNG 5 THỰC NGHIỆM VÀ ĐÁNH GIÁ
Hình 5.2: Ví dụ thiết kế gói
Thiết kế chi tiết
Phần này có độ dài từ hai đến ba trang Sinh viên đặc tả thông tin về màn hình mà ứng dụng của mình hướng tới, bao gồm độ phân giải màn hình, kích thước màn hình, số lượng màu sắc hỗ trợ, v.v Tiếp đến, sinh viên đưa ra các thống nhất/chuẩn hóa của mình khi thiết kế giao diện như thiết kế nút, điều khiển, vị trí hiển thị thông điệp phản hồi, phối màu, v.v Sau cùng sinh viên đưa ra một số hình ảnh minh họa thiết kế giao diện cho các chức năng quan trọng nhất Lưu ý, sinh viên không nhầm lẫn giao diện thiết kế với giao diện của sản phẩm sau cùng.
Phần này có độ dài từ ba đến bốn trang Sinh viên trình bày thiết kế chi tiết các thuộc tính và phương thức cho một số lớp chủ đạo/quan trọng nhất của ứng dụng (từ 2-4 lớp) Thiết kế chi tiết cho các lớp khác, nếu muốn trình bày, sinh viên đưa vào phần phụ lục. Để minh họa thiết kế lớp, sinh viên thiết kế luồng truyền thông điệp giữa các đối tượng tham gia cho 2 đến 3 use case quan trọng nào đó bằng biểu đồ trình tự(hoặc biểu đồ giao tiếp).
CHƯƠNG 5 THỰC NGHIỆM VÀ ĐÁNH GIÁ
5.3.3 Thiết kế cơ sở dữ liệu
Phần này có độ dài từ hai đến bốn trang Sinh viên thiết kế, vẽ và giải thích biểu đồ thực thể liên kết (E-R diagram) Từ đó, sinh viên thiết kế cơ sở dữ liệu tùy theo hệ quản trị cơ sở dữ liệu mà mình sử dụng (SQL, NoSQL, Firebase,v.v.)
Xây dựng ứng dụng
5.4.1 Thư viện và công cụ sử dụng
Sinh viên liệt kê các công cụ, ngôn ngữ lập trình, API, thư viện, IDE, công cụ kiểm thử, v.v mà mình sử dụng để phát triển ứng dụng Mỗi công cụ phải được chỉ rõ phiên bản sử dụng SV nên kẻ bảng mô tả tương tự như Bảng ?? Nếu có nhiều nội dung trình bày, sinh viên cần xoay ngang bảng.
Mục đích Công cụ Địa chỉ URL
IDE lập trình Eclipse Oxygen a64 bit http://www.eclipse.org/ v.v v.v v.v.
Bảng 5.1: Danh sách thư viện và công cụ sử dụng
Sinh viên trước tiên mô tả kết quả đạt được của mình là gì, ví dụ như các sản phẩm được đóng gói là gì, bao gồm những thành phần nào, ý nghĩa, vai trò?
Sinh viên cần thống kê các thông tin về ứng dụng của mình như: số dòng code, số lớp, số gói, dung lượng toàn bộ mã nguồn, dung lượng của từng sản phẩm đóng gói, v.v Tương tự như phần liệt kê về công cụ sử dụng, sinh viên cũng nên dùng bảng để mô tả phần thông tin thống kê này.
Sản phẩm
Sinh viên lựa chọn và đưa ra màn hình cho các chức năng chính, quan trọng, và thú vị nhất Mỗi giao diện cần phải có lời giải thích ngắn gọn Khi giải thích, sinh viên có thể kết hợp với các chú thích ở trong hình ảnh giao diện. Đối với đề tài game, sinh viên cần đưa ra các screenshot liên quan đến các chức năng khác nhau của trò chơi (ví dụ combat, tương tác với NPC, di chuyển, bị tấn công, sử dụng kỹ năng ) chứ không phải chỉ đưa ra 1 màn hình "in game" duy nhất Các màn hình có giao diện quá giống nhau (ví dụ các màn hình inventory, equipment ) thì có thể bỏ qua.
Quan trọng nhất là, sinh viên phải hình dung viết mục này làm sao để người đọc luận văn của các bạn, có thể không cần down game của bạn về hay xem
CHƯƠNG 5 THỰC NGHIỆM VÀ ĐÁNH
20 video quảng cáo vẫn có thể hình dung ra được trò chơi của các bạn như thế nào.
CHƯƠNG 5 THỰC NGHIỆM VÀ ĐÁNH GIÁ
Kiểm thử
Phần này có độ dài từ hai đến ba trang Sinh viên thiết kế các trường hợp kiểm thử cho hai đến ba chức năng quan trọng nhất Sinh viên cần chỉ rõ các kỹ thuật kiểm thử đã sử dụng Chi tiết các trường hợp kiểm thử khác, nếu muốn trình bày,sinh viên đưa vào phần phụ lục Sinh viên sau cùng tổng kết về số lượng các trường hợp kiểm thử và kết quả kiểm thử Sinh viên cần phân tích lý do nếu kết quả kiểm thử không đạt.
Triển khai
Sinh viên trình bày mô hình và/hoặc cách thức triển khai thử nghiệm/thực tế. Ứng dụng của sinh viên được triển khai trên server/thiết bị gì, cấu hình như thế nào Kết quả triển khai thử nghiệm nếu có (số lượng người dùng, số lượng truy cập, thời gian phản hồi, phản hồi người dùng, khả năng chịu tải, các thống kê, v.v.)
•How can they recreate it?
•What information is needed to get it started? Do not, however, include an passwords in this document!
•What systems are required to run the game?
•If it is a game that runs on local devices, deployment includes how to rebuild it and where it needs to be stored for users to be able to download it
•What configurations and settings are required to get the game working?
CÁC GIẢI PHÁP VÀ ĐÓNG GÓP NỔI BẬT
Chương này có độ dài tối thiểu 5 trang, tối đa không giới hạn 1 Sinh viên cần trình bày tất cả những nội dung đóng góp mà mình thấy tâm đắc nhất trong suốt quá trình làm ĐATN Đó có thể là một loạt các vấn đề khó khăn mà sinh viên đã từng bước giải quyết được, là giải thuật cho một bài toán cụ thể, là giải pháp tổng quát cho một lớp bài toán, hoặc là mô hình/kiến trúc hữu hiệu nào đó được sinh viên thiết kế.
Chương này là cơ sở quan trọng để các thầy cô đánh giá sinh viên Vì vậy, sinh viên cần phát huy tính sáng tạo, khả năng phân tích, phản biện, lập luận, tổng quát hóa vấn đề và tập trung viết cho thật tốt Mỗi giải pháp hoặc đóng góp của sinh viên cần được trình bày trong một mục độc lập bao gồm ba mục con: (i) dẫn dắt/giới thiệu về bài toán/vấn đề, (ii) giải pháp, và (iii) kết quả đạt được (nếu có).
Sinh viên lưu ý không trình bày lặp lại nội dung Những nội dung đã trình bày chi tiết trong các chương trước không được trình bày lại trong chương này.
Vì vậy, với nội dung hay, mang tính đóng góp/giải pháp, sinh viên chỉ nên tóm lược/mô tả sơ bộ trong các chương trước, đồng thời tạo tham chiếu chéo tới đề mục tương ứng trong Chương 5 này Chi tiết thông tin về đóng góp/giải pháp được trình bày trong mục đó.
Ví dụ, trong Chương 4, sinh viên có thiết kế được kiến trúc đáng lưu ý gì đó, là sự kết hợp của các kiến trúc MVC, MVP, SOA, v.v Khi đó, sinh viên sẽ chỉ mô tả ngắn gọn kiến trúc đó ở Chương 4, rồi thêm các câu có dạng: “Chi tiết về kiến trúc này sẽ được trình bày trong phần 5.1".
1 Trong trường hợp phần này dưới 5 trang thì sinh viên nên gộp vào phần kết luận, không tách ra
CHƯƠNG 5 THỰC NGHIỆM VÀ ĐÁNH GIÁ một chương riêng rẽ nữa.
