%% bare_jrnl.tex
%% V1.4b
%% 2015/08/26
%% by Michael Shell
%% see http://www.michaelshell.org/
%% for current contact information.
%%
%% This is a skeleton file demonstrating the use of IEEEtran.cls
%% (requires IEEEtran.cls version 1.8b or later) with an IEEE
%% journal paper.
%%
%% Support sites:
%% http://www.michaelshell.org/tex/ieeetran/
%% http://www.ctan.org/pkg/ieeetran
%% and
%% http://www.ieee.org/
%%*************************************************************************
%% Legal Notice:
%% This code is offered as-is without any warranty either expressed or
%% implied; without even the implied warranty of MERCHANTABILITY or
%% FITNESS FOR A PARTICULAR PURPOSE!
%% User assumes all risk.
%% In no event shall the IEEE or any contributor to this code be liable for
%% any damages or losses, including, but not limited to, incidental,
%% consequential, or any other damages, resulting from the use or misuse
%% of any information contained here.
%%
%% All comments are the opinions of their respective authors and are not
%% necessarily endorsed by the IEEE.
%%
%% This work is distributed under the LaTeX Project Public License (LPPL)
%% ( http://www.latex-project.org/ ) version 1.3, and may be freely used,
%% distributed and modified. A copy of the LPPL, version 1.3, is included
%% in the base LaTeX documentation of all distributions of LaTeX released
%% 2003/12/01 or later.
%% Retain all contribution notices and credits.
%% ** Modified files should be clearly indicated as such, including **
%% ** renaming them and changing author support contact information. **
%%*************************************************************************
% *** Authors should verify (and, if needed, correct) their LaTeX system ***
% *** with the testflow diagnostic prior to trusting their LaTeX platform ***
% *** with production work. The IEEE's font choices and paper sizes can ***
% *** trigger bugs that do not appear when using other class files. *** ***
% The testflow support page is at:
% http://www.michaelshell.org/tex/testflow/
\documentclass[journal]{IEEEtran}
%
% If IEEEtran.cls has not been installed into the LaTeX system files,
% manually specify the path to it like:
% \documentclass[journal]{../sty/IEEEtran}
% Some very useful LaTeX packages include:
% (uncomment the ones you want to load)
% *** MISC UTILITY PACKAGES ***
%
%\usepackage{ifpdf}
% Heiko Oberdiek's ifpdf.sty is very useful if you need conditional
% compilation based on whether the output is pdf or dvi.
% usage:
% \ifpdf
% % pdf code
% \else
% % dvi code
% \fi
% The latest version of ifpdf.sty can be obtained from:
% http://www.ctan.org/pkg/ifpdf
% Also, note that IEEEtran.cls V1.7 and later provides a builtin
% \ifCLASSINFOpdf conditional that works the same way.
% When switching from latex to pdflatex and vice-versa, the compiler may
% have to be run twice to clear warning/error messages.
% *** CITATION PACKAGES ***
%
%\usepackage{cite}
% cite.sty was written by Donald Arseneau
% V1.6 and later of IEEEtran pre-defines the format of the cite.sty package
% \cite{} output to follow that of the IEEE. Loading the cite package will
% result in citation numbers being automatically sorted and properly
% "compressed/ranged". e.g., [1], [9], [2], [7], [5], [6] without using
% cite.sty will become [1], [2], [5]--[7], [9] using cite.sty. cite.sty's
% \cite will automatically add leading space, if needed. Use cite.sty's
% noadjust option (cite.sty V3.8 and later) if you want to turn this off
% such as if a citation ever needs to be enclosed in parenthesis.
% cite.sty is already installed on most LaTeX systems. Be sure and use
% version 5.0 (2009-03-20) and later if using hyperref.sty.
% The latest version can be obtained at:
% http://www.ctan.org/pkg/cite
% The documentation is contained in the cite.sty file itself.
% *** GRAPHICS RELATED PACKAGES ***
%
\ifCLASSINFOpdf
\usepackage[pdftex]{graphicx}
% declare the path(s) where your graphic files are
% \graphicspath{{../pdf/}{../jpeg/}}
% and their extensions so you won't have to specify these with
% every instance of \includegraphics
% \DeclareGraphicsExtensions{.pdf,.jpeg,.png}
\else
% or other class option (dvipsone, dvipdf, if not using dvips). graphicx
% will default to the driver specified in the system graphics.cfg if no
% driver is specified.
% \usepackage[dvips]{graphicx}
% declare the path(s) where your graphic files are
% \graphicspath{{../eps/}}
% and their extensions so you won't have to specify these with
% every instance of \includegraphics
% \DeclareGraphicsExtensions{.eps}
\fi
% correct bad hyphenation here
\hyphenation{op-tical net-works semi-conduc-tor}
\begin{document}
%
% paper title
% Titles are generally capitalized except for words such as a, an, and, as,
% at, but, by, for, in, nor, of, on, or, the, to and up, which are usually
% not capitalized unless they are the first or last word of the title.
% Linebreaks \\ can be used within to get better formatting as desired.
% Do not put math or special symbols in the title.
\title{Keith's GD document template}
\author{Your name, student number \\ Course code, Lecturer Title. Lecturer Initial, Surname}
\maketitle
\begin{abstract}
Summarize the entire document without any reference to specific bibliographies, images or tables only semi substantiated and focus on the intro, process and then conclusion. This should give enough information that the reader doesn't encounter anything surprising within the document but should NOT give any kind of information about the flow of the document which is left to the introduction. The abstract should be almost exactly this long.
\end{abstract}
\section{Introduction}
\IEEEPARstart{T}{he} introduction sets the scene for the rest of the document, building a context that allows you to continue without redressing the paradigm multiple times. One you've done that, write the rest of the document and come back here later to outline the way in which the document is formatted. Example: "Sections 2 discusses the original design goals, section 3 will introduce the implementation of the goals" etc.
\hfill Put the date OF WRITING in here in the format: June 02, 2018
\section{Design}
Explain what you are designing because at this point the reader doesn't know what you're talking about yet. Explain what you're making and how you intend to achieve it. Under every section heading you MUST say what subsections are contained within it, think of it as a baby introduction. Write the subheadings first tho.
\subsection{Inspirations}
\subsection{Goals}
\subsection{Software Design}
Use a flow diagram to explain how you intend for your design to be implemented programatically \ref{fig:FlowC}. This goes before aesthetic because your design (while you must substantiate it to yourself) need not be fully substantiated in this document while your aesthetic decisions must be substantiated. In this section you'll need to explain the overarching design, not small details which come later.
\begin{figure}[h]
\centering
\includegraphics[scale=.45]{FlowChartForGinti.png}
\caption{Tower combination algorithm}
\label{fig:FlowC}
\end{figure}
\subsection{Aesthetic}
If your game is Aesthetic heavy, then make this into an entirely new section. Aesthetic is visual, auditory and sensory but not narrative. Narrative goes into the DESIGN section above.
\section{Mechanics}
Explain the main mechanics here and how you intend to express them in the game as well as any challenges. Order them in order of importance but also be aware that some depend on other mechanics. For example, don't discuss level design before you explain that you're making a platformer with gravity controlled movement.
\subsection{Rounds}
If you have something that needs to be broken up into parts, then you can break it up into subsubsections. If you do this, then the subsection acts as an introduction and contains minimal information except to introduce the concept that the subsubs will explain.
\subsubsection*{Phase 1}
\subsubsection*{Phase 2}
\subsubsection*{Phase 3}
\subsection{New mechanic name}
\subsection{Level design}
The level design subsection is a safe way to introduce images of the game to show off your assets and any kind of metrics that you're setting up. Clearly define the challenges that you'll give the player, the emergent mechanics and how you intend to avoid game breaking
\section{Development}
Here you divide the mechanics that you mentioned above and explain how they will be developed.
\section{Pipeline}
Explain how the subs from DEVELOPMENT will be integrated, not how you'll code them but how you'll tie them in and the order in which you'll do them.
\section{Asset Development}
Same as pipeline but for assets and how you'll tie the game together with your aesthetic.
\section{Analysis}
Be critical of your work and what you could have done differently and what you will be doing differently. You can include other things here like external issues such as group communication or roles.
\section{Conclusion}
Think of this as a much more substantive abstract. Tie your previous points together. "The careful design of the aesthetic connects the player to the environment and it is implemented in such a way as to enhance the mechanic." A statement like this can only be made if you have shown that you carefully designed the aesthetic and that it somehow connected the player to the environment (a point which would have had to be substantiated earlier and not in the conclusion) and then you would have had to have mentioned how it is that your implementation contributed to the mechanic which similarly to the earlier point must be substantiated within the document but not here. You also should not reference any images, bib items or arbitrary points that were not conclusive. Don't make throwaway comments here, anything mentioned must be something that you already concluded earlier in the document.
You should also learn how to do references and use literature to substantiate decisions as well as literature that challenges your decisions.
\end{document}
