Hi!
I've finished my project proposal. It is written up. Unformatted, it comes to just over 5 pages. Formatted, it comes to 8.
If there are any changes or improvements, let me know!
The project proposal is temporarily hosted on my website.
Clicky.
Ian
Sunday, January 29, 2012
Tuesday, January 24, 2012
Project Timeline
Hi,
So, here's a preliminary timeline for the project based on a 12-week schedule.
The general idea is to frontload the project as much as possible. This will allow room for pushing the schedule, unforeseen difficulties, and will take some pressure off the end of the year.
There are several different areas: graphics, ai, game logic, content, miscellaneous, and possibly, networking. I write of these as entities, but in practice they will likely be duties shared by all group members, with some members specializing in one most, as applicable.
Without further ado, the schedule:
So, here's a preliminary timeline for the project based on a 12-week schedule.
The general idea is to frontload the project as much as possible. This will allow room for pushing the schedule, unforeseen difficulties, and will take some pressure off the end of the year.
There are several different areas: graphics, ai, game logic, content, miscellaneous, and possibly, networking. I write of these as entities, but in practice they will likely be duties shared by all group members, with some members specializing in one most, as applicable.
- Graphics comprises making the renderer of the project. Additionally, the graphics lead will handle setting up the windowing environment and the main loop.
- AI comprises the creation of the enemies tactics (particularly airplanes').
- Game logic is the area concerned with defining objects (airplanes, bullets, zeppelins, trees, etc.), creating interfaces for their movement, and defining user interaction with the game and menus.
- Content will handle procuring FOSS resources to draw and use (airplane models, tree models, menu graphics, sounds, etc.) and writing the storyline. Content and Game Logic should share level design.
- Miscellaneous will handle patching everything together and smaller tasks (file system, proofreading, etc.).
- Networking would concern making a client-server interaction to allow multiplayer. The easiest way would be with a deathmatch-type thing. Collaborative missions are another possibility if time allows.
Without further ado, the schedule:
-Week 1:Ian
The group will assemble for the first time. Bureaucracies are sorted out (times to meet, communication, etc.). This document will be reviewed, and, if necessary, altered. Discussion of underlying technologies (OpenGL, graphics library, C++, etc.). An SVN repository will be created somewhere. Perhaps some preliminary coding.-Week 2-3:
Coding begins in earnest. Code will be written fast. We should have developed a basic framework for the game (graphics has basic renderer, game logic has passable controls and vehicle classes, content has produced some models to use). Everyone will work on these important parts before anything else happens.-Week 4:
Work begins on AI. Collaboration with game logic to ensure that a decent API can be used for the player and for the AIs. Higher-order structures to allow complex, abstract shapes from base movements (turn right, etc.) to help AI planning. Miscellaneous should be working with all other areas from here to completion.-Week 5:
Graphics should have a solid renderer supporting terrain and objects, rendered decently. AI will have rudimentary functionality (flying in a straight line, maybe attacking stationary targets). Core game logic should be complete. Extra classes may be being added to broaden possibilities. General storyline established; brainstorm level ideas. Work on menuing system commences. Content should have most of the assets procured.-Week 6:
Project mid-re-evaluation. Game should be basically playable. Game logic's collision detection is complete. Renderer is solid, nearly complete; perhaps supports some pretty features (shadows, reflections, waves/splashes, etc.). Menuing system is usable (although not necessarily for all tasks). Content has nearly all assets procured. AI is more advanced; basic functionality is in-place. Decide whether to include networking.-Week 7:
Renderer complete except for advanced features. Storyline finished. Level design in-progress. Game logic turns toward supporting any additional needs of levels. Menuing system nearly complete. Content has procured all assets except perhaps a few required by various levels. AI can attack each other and humans and not look horrible at it. If networking is included, basic client-server interaction set up.-Week 8:
All levels have been planned and are being implemented. Menuing system effectively complete. Content continues to support level design. AI has improved. A decent human player will likely still beat them easily, but at least bots should put up a fight. If networking is included, begin integration of game into network. Servers should support a game state, and changes should be visible to clients.-Week 9:
Renderer finished. Menuing system complete. Levels nearly complete or complete. Content should be complete except for final, unexpected assets for some level. AI has improved further, and should put up a better fight. Playtesting begins with focus groups. If networking is included, players should be able to attack/fly with each other over a network, and send messages to each other.-Week 10:
Levels complete. Content complete. AI may or may not be (practically) improvable. Playtesting continues. General focus shift to bugsquishing and testing. Marketing begins (website?). If networking is included, all network traffic is established. Consider adding in co-op play for levels. Note that this might include reworking some levels (or having different level modes) to maintain constant difficulty.-Week 11:
All functionality completed. All work focuses on fixing bugs, testing, writing documentation, and generally tidying up the project. Playtesting feedback thoroughly considered. Marketing of project.-Week 12:
Final (play)testing/bugfixes, final marketing, buffer time in case of problems, and presentation to the world.
Sunday, January 22, 2012
Project Proposal 1
Righto, project ideas to implement for this semester's project!
Idea #1: WWI Shoot 'Em Up Game
That's all for now,
Ian
Idea #1: WWI Shoot 'Em Up Game
Like a flight simulator, but you blow stuff up! Fly WWI aircraft through a series of missions, with 3D graphics and great gameplay! There would be some sort of insanely surreal story; I feel like modern games take themselves far too seriously; it should be more mixed up and fun. It can go as far as having alternate universes, care-bear invasions, pirates, differential equations exams--anything we dream up.
The game would be playable by anyone (and would of course be family friendly), but would likely appeal mostly to a young adult market. It would value being light-hearted, easy to learn, and fun, above being serious and violent. Support-wise, the game would be either open source or commerical--in the latter case fairly cheaply, perhaps some form of shareware.
To do list:
-Aircraft (various WWI airplanes to be modeled or downloaded)
-Landscapes (various terrains to be created)
-Flight modeling (this can be much simpler than what's is actually realistic, for ease of both implementation and use)
-Menu system
-Quirky and original storyline, and level/mission designs
-AI for players
-Game logic
-Various resources (sounds, airplanes, menu assets, etc.)
-Miscellaneous things (hp, player stats, etc.)
-Multiplayer support? (Can use networking library)
In terms of project development, I would really like to work in C++ (Ackley permitting). Don't get scared y'all: C++ is a beautiful language--not as bloated or restricted as Java, and faster. Yet, the syntax is very similar. Plus, by using C++, I will be able to use a graphics library I have been developing (note that the graphics system for Java is broken, particularly for 3D, and I doubt making a 3D game of any scope in Java is possible in the time provided). Networking would also be simpler and more robust than Java's.
That's all for now,
Ian
Saturday, January 21, 2012
Concerning a Bit of Philosophy
Hi,
In class on 1/20/2012, engineering and science were contrasted in the context of comparing software engineering and computer science.
Ackley presents a view of the humans: imagine a square, tilted 45 degrees sideways, so it's a diamond. On the left corner is an eye, representing the sensory array with which humans are endowed. On the right corner is a hand, representing everything humans are capable of doing. On the bottom corner is "A->B", representing our causal judgement. On the top corner is "+/-", representing our moral judgement. In the middle is us, being a conglomeration of all four corners.
Science, Ackley contends, is the side of the square between the eye and "A->B". This is because science takes what we observe, and tells us what will happen in the future (arguably, the hand is somewhat part of it too, because science can predict what happens when we interact with a system, though this may be reduced down to the casual). Science does not care about "+/-"--that is, whether we like what we see in a developing system. Nor, in the basic sense, does it care what we do (hand) about it.
On the other hand, engineering is just the hand, because it concerns only getting things done. Doesn't matter if it's moral, really--engineering just concerns "get 'er done".
Hence, science and engineering are duals. I for one, think this is a very useful view. However, with respect to software engineering and computer science, I'm not so sure. Software engineering clearly deals with the process of making code, but computer science I think isn't really a science. Sure, sometimes computer scientists make experiments--but ultimately, I think, computer science is a broad term covering the field of computing.
For example, "Computer Architecture" and "Algorithmic Analysis" I think are best described as being subdisciplines of "Computer Science". But, "Algorithmic Analysis" involves logical proofs; finding truth a priori. And "Computer Architecture" involves studying best practices to "get 'er done".
Similarly, I think "Software Engineering" is a subdiscipline of "Computer Science". This is because the latter is not truly a science, but an encompassing term of all subdisciplines pertaining to computers.
To return to a Wikipedia definition, "Computer Science" is "the study of the theoretical foundations of information and computation. It also includes practical techniques for their implementation and application in computer systems." So it's really not only theory, but also some practice.
Ian
In class on 1/20/2012, engineering and science were contrasted in the context of comparing software engineering and computer science.
Ackley presents a view of the humans: imagine a square, tilted 45 degrees sideways, so it's a diamond. On the left corner is an eye, representing the sensory array with which humans are endowed. On the right corner is a hand, representing everything humans are capable of doing. On the bottom corner is "A->B", representing our causal judgement. On the top corner is "+/-", representing our moral judgement. In the middle is us, being a conglomeration of all four corners.
Science, Ackley contends, is the side of the square between the eye and "A->B". This is because science takes what we observe, and tells us what will happen in the future (arguably, the hand is somewhat part of it too, because science can predict what happens when we interact with a system, though this may be reduced down to the casual). Science does not care about "+/-"--that is, whether we like what we see in a developing system. Nor, in the basic sense, does it care what we do (hand) about it.
On the other hand, engineering is just the hand, because it concerns only getting things done. Doesn't matter if it's moral, really--engineering just concerns "get 'er done".
Hence, science and engineering are duals. I for one, think this is a very useful view. However, with respect to software engineering and computer science, I'm not so sure. Software engineering clearly deals with the process of making code, but computer science I think isn't really a science. Sure, sometimes computer scientists make experiments--but ultimately, I think, computer science is a broad term covering the field of computing.
For example, "Computer Architecture" and "Algorithmic Analysis" I think are best described as being subdisciplines of "Computer Science". But, "Algorithmic Analysis" involves logical proofs; finding truth a priori. And "Computer Architecture" involves studying best practices to "get 'er done".
Similarly, I think "Software Engineering" is a subdiscipline of "Computer Science". This is because the latter is not truly a science, but an encompassing term of all subdisciplines pertaining to computers.
To return to a Wikipedia definition, "Computer Science" is "the study of the theoretical foundations of information and computation. It also includes practical techniques for their implementation and application in computer systems." So it's really not only theory, but also some practice.
Ian
Thursday, January 19, 2012
Post the Second
Hi,
Although this is the second post, it is the first substantive one. This blog should concern CS 460. As this is my first time blogging, I shall presume that the action entails dumping here any and all that goes through my mind pertaining to the topic at hand. Evidently, this is a popular undertaking, though I scarcely discern why. At any rate, the intention is to document my exploits in this, which is to be a software engineering class; I am sure it will serve the purpose, and anyway writing often helps one organize one's thoughts.
The first (and only) item on the agenda concerns my impressions of the Wikipedia article "Software engineering". I think this is best divided into parts, broken down logically below.
My understanding of software engineering involved the design and some aspects of creating large software. It was my understanding that software engineering involved designing a project to be robust, suited to the topic at hand, and modular. Further, when constructing software, tests are built into additional modules developed parallel to the code itself. I have some criticisms concerning some of these aspects, but for now I shall hold my peace.
Most of these perceptions developed from CS 351, which I took Fall 2011. The salient Wikipedia definition calls software engineering the "systematic approach to the analysis, design, assessment, implementation, test[ing], maintenance and reengineering of software". This appears to be a complete definition of the term. The rest of the article is not divided into describing each of these sections. Instead, the topic is approached and viewed from different perspectives (historical, comparative, etc.), all mostly agreeing with my assessments from CS 351. In light of this, I would like to select the points that add to my definition provided in the previous paragraph.
1. Software engineering emerged out of necessity; apparently, programmers couldn't keep track of their increasingly complex programs. Although the article is somewhat vague, I assume the creation of the field emerged as a formalization of various tricks of the trade (for example: putting-code-in-objects-like-functions-and-data-structures-to-avoid-code-reuse becomes "encapsulation"). Also presumably, coders needed an assumed system for how things are done (well of course you store you put all the polygon data in a VBO class--how else would I know how to use it?!). This latter point expands on introductory material presented in CS 351.
2. The profession of being a software engineer is rather roughly defined in the Wikipedia article, but there are at least varying standards and certifications around the world. Also, apparently, fatal on-the-job accidents are rare. Just in case, retrofit your computer with airbags. Outsourcing is less of a problem. From what I have heard from my friends in industry, contract programmers in other countries habitually write very bad code. Perhaps this is why software engineering isn't outsourced--because it can't be. Maybe I'm just being uncharacteristically nationalistic.
3. Software engineering is often bundled with computer science in popular impression and in curricula. While they are in fact similar and related, they are different fields of study. It is my opinion that UNM's computer science program mixes the two rather too much.
4. There is a helpful list of subdisciplines which I found instructive. As of today, they are software requirements, design, construction, testing, maintenance, configuration management, engineering management, process, tools and methods, and quality. Descriptions thereof may be found at the article.
That's all for now. Farewell,
Ian
Although this is the second post, it is the first substantive one. This blog should concern CS 460. As this is my first time blogging, I shall presume that the action entails dumping here any and all that goes through my mind pertaining to the topic at hand. Evidently, this is a popular undertaking, though I scarcely discern why. At any rate, the intention is to document my exploits in this, which is to be a software engineering class; I am sure it will serve the purpose, and anyway writing often helps one organize one's thoughts.
The first (and only) item on the agenda concerns my impressions of the Wikipedia article "Software engineering". I think this is best divided into parts, broken down logically below.
My understanding of software engineering involved the design and some aspects of creating large software. It was my understanding that software engineering involved designing a project to be robust, suited to the topic at hand, and modular. Further, when constructing software, tests are built into additional modules developed parallel to the code itself. I have some criticisms concerning some of these aspects, but for now I shall hold my peace.
Most of these perceptions developed from CS 351, which I took Fall 2011. The salient Wikipedia definition calls software engineering the "systematic approach to the analysis, design, assessment, implementation, test[ing], maintenance and reengineering of software". This appears to be a complete definition of the term. The rest of the article is not divided into describing each of these sections. Instead, the topic is approached and viewed from different perspectives (historical, comparative, etc.), all mostly agreeing with my assessments from CS 351. In light of this, I would like to select the points that add to my definition provided in the previous paragraph.
1. Software engineering emerged out of necessity; apparently, programmers couldn't keep track of their increasingly complex programs. Although the article is somewhat vague, I assume the creation of the field emerged as a formalization of various tricks of the trade (for example: putting-code-in-objects-like-functions-and-data-structures-to-avoid-code-reuse becomes "encapsulation"). Also presumably, coders needed an assumed system for how things are done (well of course you store you put all the polygon data in a VBO class--how else would I know how to use it?!). This latter point expands on introductory material presented in CS 351.
2. The profession of being a software engineer is rather roughly defined in the Wikipedia article, but there are at least varying standards and certifications around the world. Also, apparently, fatal on-the-job accidents are rare. Just in case, retrofit your computer with airbags. Outsourcing is less of a problem. From what I have heard from my friends in industry, contract programmers in other countries habitually write very bad code. Perhaps this is why software engineering isn't outsourced--because it can't be. Maybe I'm just being uncharacteristically nationalistic.
3. Software engineering is often bundled with computer science in popular impression and in curricula. While they are in fact similar and related, they are different fields of study. It is my opinion that UNM's computer science program mixes the two rather too much.
4. There is a helpful list of subdisciplines which I found instructive. As of today, they are software requirements, design, construction, testing, maintenance, configuration management, engineering management, process, tools and methods, and quality. Descriptions thereof may be found at the article.
That's all for now. Farewell,
Ian
Wednesday, January 18, 2012
First Post!
Should have gotten the blogging website up and running, through "blogger". Posts will be available here in the future. Additional material may be linked to my other websites.
Subscribe to:
Posts (Atom)