Commit 418cdae2 authored by 魔法少女赵志辉's avatar 魔法少女赵志辉 🍊
Browse files

Update draft for project2-tower_defence

parent 2a67821b
\documentclass{dreamClass}
\def\CC{ {C\nolinebreak[4]\hspace{-.05em}\raisebox{.4ex}{\small\bf ++}} }
\tikzset{
1/.style={insert path={edge[->] ++ (-0.5,-0.5) (-0.5,-0.5)}},
2/.style={insert path={edge[->] ++ (0,-0.5) ++(0,-0.5)}},
3/.style={insert path={edge[->] ++ (0.5,-0.5) ++(0.5,-0.5)}},
4/.style={insert path={edge[->] ++ (-0.5,0) ++(-0.5,0)}},
6/.style={insert path={edge[->] ++ (0.5,0) ++(0.5,0)}},
7/.style={insert path={edge[->] ++ (-0.5,0.5)++ (-0.5,0.5)}},
8/.style={insert path={edge[->] ++ (0,0.5) ++(0,0.5)}},
9/.style={insert path={edge[->] ++ (0.5,0.5)++ (0.5,0.5)}},
*/.style 2 args={insert path={foreach \X in {1,...,#1} {[#2]}}}
}
\title{
\vspace{-50pt}
\textbf{\Huge Project2}\\
\textbf{\huge 塔防游戏}\\
\small Version 0.1.0
}
\author{刘添翼\thanks{\href{mailto:tyi.liu@outlook.com}{tyi.liu@outlook.com}}}
\affil{计算机科学与技术系,南京大学}
\date{\today}
\begin{document}
\maketitle
\thispagestyle{empty}
\section{最后期限}
Project2的最后期限是\textbf{北京时间2021年11月14日23时59分}
在此之前,每位同学需要提交课程项目的源码、可执行文件和项目报告到Github Classroom的对应于Project2的assignment中去。
\section{概述}
我们已经完成了一个塔防游戏!
这听上去棒极了!
所以,让我们为这个游戏添加更多的内容吧!
\section{原则}
游戏必须是从第一行代码开始写成的,符合面向对象和泛型程序设计范式的,\CC{}程序。推荐使用第三方的\CC{}图形库来完成图形的绘制,键盘鼠标事件的捕获和处理等等内容,这样可以集中精力设计和实现游戏的架构。
游戏应当基于Project1中已经完成的部分,只在确实有必要的情况下重构已有的代码。
\section{技术指标}
我们参考《明日方舟》和《植物大战僵尸》,制订了这份技术指标。本节是Project2的基本要求,其中描述的所有内容,除了显式说明成\emph{可以自由发挥}的之外,都需要完成。
\subsection{地图的导入与导出}
在Project1中,我们可能硬编码(Hard Code)了若干张地图。现在,我们要能让游戏支持地图的导入和导出。
\begin{problem}
什么是一张\textbf{地图}
\end{problem}
回顾Project1中的约定:\textbf{地图}(的画布部分)在逻辑上是一个\(m \times n\)的矩形,每个\(1 \times 1\)的矩形是一个格子;(地图的)\textbf{格子}可能有不同的类型,但这些类型也是可枚举的;(地图的)\textbf{路径}是格子的有穷序列,并且路径的数量是有穷的。
在Project2中,我们把这三个概念统一起来,称为\textbf{地图}
即有:
\begin{equation}\label{eq:map}
\text{Project2中的地图} = \text{Project1中的地图} + \text{Project2中的格子} + \text{Project2中的路径。}
\end{equation}
\cref{eq:map}\emph{Project2中的格子}\emph{Project2中的路径}的定义分别见\cref{pro:block}\cref{pro:path}
\begin{problem}
游戏需要多少地图?
\end{problem}
游戏需要内置有至少一张地图,玩家可以在游戏中导入和导出更多自定义的地图。
\begin{problem}
什么是\textbf{被导出和等待导入的地图}?
\end{problem}
被导出和等待导入的地图应当是具有特定语法的文本文件(可以理解成一种配置文件)。
这样,玩家可以:
\begin{enumerate}
\item 首先导出默认的地图;
\item 然后可以参考其格式,对其进行修改后成为新的地图;
\item 最后将新的地图导入到游戏中并正常游玩。
\end{enumerate}
各位同学可以自由设计自己的地图的语法。
在这个语法下,一个合法的文本文件就唯一对应于一张地图。
游戏需要能读取所有尺寸合理的(换言之,对于超大的地图的处理可以自由发挥),合法的地图。
\begin{problem}
一张地图需要包含什么信息?
\end{problem}
至少需要包含:
\begin{enumerate}
\item 地图的尺寸,
\item 和地图中每个格子的类别,
\item 地图中的所有路径。
\end{enumerate}
其他的部分可以自由发挥,比如可以:
\begin{enumerate}
\item 指定不同路径上可以生成的敌方单位的种类,
\item 指定不同格子上可以部署的我方单位的种类,
\item 为某些格子增加特殊的效果。
\end{enumerate}
\subsection{更多的我方单位}
在Project1中,对我方和地方的单位没有做特别要求。
现在,我们要让游戏有更多种类的单位:我方的近战单位,我方的远程单位,地方的地面单位,地方的飞行单位。
为了适应这个变化,我们要拓展在Project1中对格子、路径、阻拦数和攻击范围的定义。
\begin{problem}\label{pro:block}
什么是\textbf{Project2中的格子}
\end{problem}
Project2中,格子的类别至少需要以下几种:
\begin{enumerate}
\item 我方的近战单位可以部署的格子,简称\textbf{近战格子}
\item 我方的远程单位可以部署的格子,简称\textbf{远程格子}
\item 我方的所有单位都不能部署的格子。
\end{enumerate}
其他的格子可以自由发挥。
\begin{problem}\label{pro:path}
什么是\textbf{Project2中的路径}
\end{problem}
Project2中,路径的类别至少需要以下几种:
\begin{enumerate}
\item 敌方的飞行单位使用的路径,简称\textbf{飞行路径}
\item 敌方的地面单位使用的路径,简称\textbf{地面路径}
\end{enumerate}
只需保证地面路径中所有的格子都是我方的近战格子即可,其他可以自由发挥。
\begin{problem}
什么是\textbf{Project2中的阻拦数}
\end{problem}
阻拦数是我方的近战单位能阻拦敌方的地面单位的数量。
我方的近战单位默认无法阻拦敌方的飞行单位;我方的远程单位默认无法阻拦敌方的单位。
\begin{problem}
什么是\textbf{Project2中的攻击范围}
\end{problem}
攻击范围是单位可以攻击到敌方的范围。我们为单位引入一个\textbf{朝向},则攻击范围也成为带有方向的。当然,如果所有单位的攻击范围都是对称的,朝向也就等于不存在了。
\begin{problem}
什么是\textbf{我方的近战单位}?
\end{problem}
我方的近战单位需要有至少三种:
\begin{description}
\item[地刺类单位] 阻拦数为0,有攻击能力,攻击范围多于一格,可以被特定的(而不是全部)敌方单位攻击的单位。
\item[坚果类单位] 阻拦数严格大于0,无攻击能力或者攻击能力可以忽略不记的,血量相对较高的单位。
\item[防空步兵类单位] 阻拦数严格大于0,可以攻击范围内的敌方地面和飞行单位(两个的攻击范围可以不同也可以相同),有(不是特别高的)血量的单位。
\item[一般近战单位] 阻拦数严格大于0,攻击范围为自己所在格子,有(不是特别高的)血量的单位。
\end{description}
\begin{problem}
什么是\textbf{我方的远程单位}?
\end{problem}
我方的远程单位需要有至少三种:
\begin{description}
\item[兵营类单位] 无攻击能力,但是可以自动(或者手动)放置坚果类单位在攻击范围内的合法位置。
\item[箭塔类单位] 有攻击能力,会主动攻击攻击范围内的一个(而不是全部)敌方地面单位。
\item[爱国者导弹类单位] 有攻击能力,会主动攻击攻击范围内的一个(而不是全部)敌方飞行单位。
\end{description}
\begin{problem}
什么是\textbf{敌方的地面单位}?
\end{problem}
敌方的地面单位需要有至少四种:
\begin{description}
\item[一般地面单位] 移动并攻击我方的近战单位。攻击范围为自己所在格子。
\item[攻击距离远的敌方单位] 移动并攻击我方的近战单位,攻击范围严格大于一格。
\item[能拆塔的地面单位] 移动并攻击我方的近战单位和远程单位。对两种单位的攻击范围可以相同或者不同。
\item[萨满类单位] 无攻击能力,但可以给攻击范围内的敌方单位加buff。
\end{description}
\begin{problem}
什么是\textbf{敌方的飞行单位}?
\end{problem}
敌方的飞行单位需要有至少两种:
\begin{description}
\item[恋战的一般飞行单位] 移动并攻击我方的单位。攻击范围内有我方单位时,不会前进。
\item[畏战的一般飞行单位] 移动并攻击我方的单位。 攻击范围内有我方单位时,也会前进。
\end{description}
\section{Q\&A}
\begin{problem}
我可以使用EasyX、Unreal Engine、NoesisGUI之类的库吗?
\end{problem}
可以,只要它们为程序的开发者提供的API是\CC{}的即可。
过于复杂和高级的库可能并不容易学习掌握,打包和发布程序或许也会相对困难;过于简单的库则缺乏一些必要的基础设施,会不必要地加大任务量。
一般来说,我们会推荐初学者使用一些成熟的、有良好文档的、容易上手的库,这样的库不必是Qt,或许某些(不为我们所熟悉的)专为游戏开发设计的库是最适合这个项目的。如果有同学对此有心得,欢迎联系我们。
\begin{problem}
我必须在Project2中实现一个GUI吗?
\end{problem}
并非如此。我们只要求项目在最终有一个可用的GUI,并不强求各位同学在Project2就实现它的部分或者全部。
不过为了避免不必要的重构,思考如何设计程序的核心逻辑使其能在各种UI(包括\textbf{G}raphical \textbf{U}ser \textbf{I}nterface和\textbf{C}ommand \textbf{L}ine \textbf{I}nterface)上展示是有必要的。
\begin{problem}\label{pro:new_idea}
我不喜欢这个游戏,我有一个新的想法。
\end{problem}
请带上新项目的文档来联系我们,我们很欢迎新的想法。
不过考虑到这是一门程序设计课的课程项目,我们可能会对新项目的扩展性有比较高的要求,因此可能难免会提出一些(或许看起来和这个项目并不搭的)要求。总体来说新的项目是被允许的,但是如果新的项目不能很好地体现这门课程的宗旨,或许项目的最高分数会打一些轻微的折扣。
\begin{problem}
我不喜欢某些规定动作,我可以改变/简化/删去它们吗?
\end{problem}
参见\cref{pro:new_idea}。请带上你的新想法的文档来联系我们。
如果经过我们评估,认为新的想法的难度适中,可以体现本课程的宗旨,那么是可以的;如果新的想法显然弱化了项目的难度或者和项目的根本宗旨不合,可能会轻微地影响项目的得分。
\begin{problem}
我没有美术天赋,我是不是需要自己硬着头皮画地图/单位/动画/…?
\end{problem}
完全不需要。
参见\cref{sec:map},只要能够达意,不论是自制的美术素材,还是经授权使用的其他人的美术素材,或者只是简单的文本和字符,都是可以的。
\end{document}
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment