Monday, January 30, 2012

Proposal Review 1

Hi,

I've agreed to review two proposals.  The first is entitled "Healthy People".

The gist of the proposal appears to be to create an app for the iPhone, iPod, and iPad that gives lifestyle suggestions given user data, with the intention of helping people lose weight.

My overall reaction is that the proposal might be a good idea, but that the quality of the presentation . . . needs work.  The proposal lacks structure and is at times redundant or incoherent.  The author only really addresses one of the issues and does not present a clear plan for project execution.  Overall, the project seems like a simple enough idea, but the proposal remains unconvincing.

Format: 3.0/10.0 => 1.5/5.0
There are no marked sections; the entire proposal appears to be a single stream-of-consciousness rant.  Upon closer examination, the proposal does possess a loosely delineated structure, with discussion of various aspects of the project being in generally related areas.

Writing: 2.0/10.0 => 1.0/5.0
I don't really think judging on this is fair.  From the way the paper was written, it is clear that the author is an ESL speaker.  Consequently, I don't hold faults in this area against the proposal.

Goals and Tasks: 4.0/10.0 => 2.0/5.0
The project is roughly defined.  By the end of the proposal, it is clear what the project would entail, even if it is not completely stated.  There is only a very limited breakdown of what would be required, but the goal is present.

Scope: 6.0/10.0 => 3.0/5.0
The project has a decently defined boundary, in the sense that the entire project idea was stated, and boundaries can be inferred from that.  However, the description is somewhat vague, and only some aspects of implementation can be inferred.  There's not really a concrete sense of what to do, with scope only arising from a description of what the application's behavior would be.

Plausibility: 8.0/10.0 => 4.0/5.0
The project appears to be simple enough to implement within 12 weeks.  However, the author admits that he has no knowledge of development on any Apple platforms, nor equipment to test it on.  Programming for Apple mobile devices typically requires Objective-C, which is a huge pain to work with, especially if you never have before.  It is only because the project is reasonably simple that I think it is still doable.

Novelty: 7.0/10.0 => 3.5/5.0
Exercise programs aren't really new.  The author acknowledges this.  The differentiating factor according to the author is that the proposed project would not give confusing data that would confound the user (heart rate, calories used, etc.).  Instead, the author suggests making the UI simple, with only lifestyle suggestions and weight loss being reported.  This isn't really novel, but it has merit in that many people don't really care about numbers and statistics, and just want some suggestions, and it is not an approach that is typically used.

Stakeholder Identification: 9.0/10.0 => 4.5/5.0
The product is clearly intended for those overweight or concerned about their health.  It does not explicitly list these as the target audience, but the intention is nevertheless quite clear from context and remarks within the proposal.

Support and Impact: 4.0/10.0 => 2.0/5.0
There is no mention of anything about supporting the project.  As close as it comes is "it will not have cost"--so, open source?  Free?   No support mechanism is proposed.  However, the author consistently alludes to the notion of helping people and making a difference in their lives, so there is some implicit notion of making an impact.

Evidence: 9.0/10.0 => 4.5/5.0
Actually, the proposal opens with a statistic concerning the amount of overweight people in industrialized nations.  The impact is fairly obvious by the project description.

Challenges and Risks: 4.0/10.0 => 2.0/5.0
The author acknowledges the main issue: that he knows nothing about application development on Apple platforms and currently has no resources to do so.  Unfortunately, there is no apparent realization that any research (which would have shown that this may be harder than first imagined) was conducted.

So, overall, weight loss programs aren't really my thing, but I can see the idea having some use to some people.  However, as presented, the proposal does not effectively sell itself.

Ian

Sunday, January 29, 2012

Project Proposal Document

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

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.
  • 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.
In order of highest priority to lowest priority: Graphics, Content, Game Logic, AI, Miscellaneous, Networking.

Without further ado, the schedule:
-Week 1:
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.
Ian

Sunday, January 22, 2012

Project Proposal 1

Righto, project ideas to implement for this semester's project!

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

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

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.