Blog 18 Evaluation

Overall myself and Scott are convinced that this design and prototype stage has been reasonably well for us. The project has come along nicely and we have both learned a lot of things and looked into a range of different areas that we hadn't before. Personally I delved into areas of C# that I hadn't before and implemented things for the first time across any programming language. I'll go through a few points that I feel are worse going through with regards to the progression and outcome of our project.

The first thing that came up was our limitations with the development platform. We could only realistically choose XNA C# for the project, but having done just the one project in it beforehand, we knew we would run into a lot of challenges which would be hard to gauge. Though overall I think we were able to move past most of these within reasonable time.

Our decision to go with a mini game style approach to the game instead of a single stand alone game based on an event of the Highland games had its ups and downs. It was good that it meant we could think about the design of more than just one game, and since we were in a group of two it meant we could have a good chunk more to write about and think about for our design document. We were able to come up with five ranging mini games for the Highland games theme that would engage different aspects of a player. The one real problem that came from deciding to do it with a mini game style, was that a key feature of collection of mini games is a menu system that allows the user to go between the different games, and in our case we wanted them to be able to look up the controls and high scores without having to be in the respective game to see it. I quickly learned that a lot of work needed to go into setting up a menu system properly and fully as to not cause any problems later on down the line. Effectively what this has meant is that a lot of time has been spent making a good deal of code that there isn't a lot to show for in the screen and video caps. I think there is actually more code in this prototype than there was in the previous project I made in C# but not as much happens when the project is run. It's not something worth getting to hung up on hopefully since it means the foundation is set to put the mini games on later on.

Something that has been a problem in previous projects is unreliable team members or poor communication, but since we have the benefit of living together, we didn't run into any of these prior problems in other groups and were able to work well together often. A smaller issue I would note on is our poor art skills for the graphics used in the game, but this is something I've mentioned in previous blogs and it would be something we come back to and improve later down the line.

In conclusion it has been a worthwhile project that we have both been able to take away something from and feel the output will reflect that. With a good framework laid down, this project has a positive future once we move it forward from this design stage.

Blog 17

Just really using this as a checklist as we package everything up for submission. The design and technical documents are completed, as well as the project plan which includes the two gantt charts for the proposed and actual progress of the tasks. The project plan also contains the statement of risks for the project. Bar the evaluation entry which is shortly to follow, the blog entries have been completed to what we hope is an acceptable degree. We will link to these blogs as well as put them onto pdf format as well. The screen-caps and the game-play video are finished as well and just need put on the disk with everything.

Blog 16

Just a short entry to say that the video cap has been taken which to be honest is a little bit lacking since it really only goes through the menu which shows the same as the screen shots, thought the title screen music can be heard as well. Not much else to really say at this point. We'll be packaging up the project in a day or two and will do an evaluation blog to sum everything up.

Blog 15

The screen caps have been taken and saved. They pretty much just go through the different pages of the menu and shows the information that is available on each of them, as well as showing the different lists and selections that can be made in the game for choosing events. Just need to take the video cap and then package everything up for handing in on CD.  Will be getting about that shortly.

Blog 14

Doing a second round of testing with Scott to make sure it's working properly before we start taking the screen and video caps of the prototype project. We weren't able to find any program breaking problems when we tested it. Only things to really note would be some changes we would make to the page layout of a couple of the screens, namely the control page which is a bit cluttered. Though we will fix that at a later date when we move past the prototype stage. The menu system is working well and executes a gameplay screen, though it doesn't currently have a game to execute but that will be added when we push forward from the prototype stage. The foundation seems to be set for the mini games to be put on.

Scott will start taking some of the screen caps and video caps after I just tidy up some of the code.

Blog 13

Really just spending a lot of time effectively debugging the code and have been making progress fixing some of the problems I mentioned beforehand. The issue with going back to previous states has been rectified and had to do with me trying to create the state again when I tried to move back to it when I had to be popping the current game state off the stack which returned me to the desired screen state. The graphics problem got fixed as well and was pretty much just down to an error with some of the coordinates I had set them in and put some of the initializing code in the wrong game state classes. Will do a second round of tests with Scott to make sure everything is working properly before moving on.

Blog 12

We're both just starting to test the menu code and see what the main problems are. The issue with it being a bit strange regarding going back to previous states is still there, and there are a couple of issues with the background graphics as well not being aligned properly that need fixed. The title music seems to be working after a silly error had me stuck for a couple of hours. I'll need to go back and look from the beginning to see if I can figure out why I'm getting some of these errors and start trying to fix them.

Other than that Scott finalized the design document, though I don't think there was to many major changes required at this stage.

Blog 11

I've just been shifting my efforts back to moving the menu system along. I've been trying to put in the graphics that Scott came up with and cleaning up the code a bit. We will start running a brief testing period on it soon and decide what we need to focus on for it. Having some minor problems with getting proper navigation backwards from one gamestate to a previous gamestate.

Scott has been finishing off a few more of the backgrounds and has been looking for some suitable music and sound FX that we can put into the games. We will have some bag pipe music playing in the menu ideally, and then each game will have it's own song.

Blog 10

I've been trying to put in some physics code into C# based off older projects I did in C++ but not had very much success. I don't think I really know enough about C# to convert the code over and have probably spent a bit to much time trying to get it to work than I should have considering I've basically not gotten anything out of it that can get put into the project. I'll be moving back to trying to finish off the menu system and add in some of the graphics and music for it. It's making me think that it would probably be worth spending the time to learn how to use the Farseer physics engine later on rather than trying to hack and slash it my way. Though this is something I can come back to later on in the project.

Scott was giving was working with me quite a bit on the physics since we both worked on the original C++ physics project from last year. He has also been making some background graphics for us to pretty much work as placeholders at the moment. Art and graphics is probably our combined weakest aspect, since neither of us have drawn since we were forced to in early high school. Our bad computer art will be what we are stuck with for now. This could be an area that when we go past the prototype stage we could consider trying to find someone who could do better art for us, or consider looking into some alternatives.

Blog 9

Moved away from focusing on the menu system since that has come along quite well so far. Looked more so into the physics engine side of XNA C# for later on down the line in the project. Both myself and Scott looked into different physics based engines and in particular looking at one called 'Farseer' which seems to be the box2d engine converted into C#. We used a different version of box2d before in a previous module called jbox2d which was  java version of the engine. Though we only worked on a few basic examples with it, we could see from different demo programs that it had a strong capability and could potentially be something we incorporated into our mini games later on.

Since the games that would require physics are fairly small, integrating a whole physics engine into the project might be a little bit too much, but it's hard to know at the moment. We decided I'll have a grind at trying to get some basic physics hard coded into a separate project using some of the things I learned over a year ago in C++. Though I'm a bit unsure of how they will translate over into C# but it's worth testing out at this point.

Blog 8

Not much to really write about in thus entry, really much of the same since the last time. Continuing to code away on the project and making some steady progress on the menu functionality. Got a lot of code into the project at this point though not a lot actually happens but that's the way it goes since this is all a foundation for the games to be put on top of later on.

Scott drafted out a technical specification from brief notes we took earlier on, so the design and technical documents are pretty much completed, I think one final draft of the design document will be made to bring everything in line.

Blog 7

Just been continue to study up on C#  mostly. I'm going into a lot of new territory since I've only made one game in C# before but I think I'm getting on not to bad so far. The early bones of the menu system are up and running, made a library with the state manager and an initial starting title screen. No graphics or anything yet, but that can come later on.

Scott is working on the design document, and he had also written up a statement of risks a while ago which I forgot to post about. It pretty much covered a few areas that stuck out to us that could be problems, like potential data loss, the dependent layers of functionality and so on. Things like communication won't really be a huge problem since unlike a lot of other student groups we live together so this isn't a problem.

Blog 6

Starting to get a better idea of what I'm going to need to code for the projects menu system. At the moment I'm looking at making a stack of game states that are linked together and can be switch between the states by pushing and popping the states on and off the stack. I'm going to make a rough plan of attack for the code to keep on schedule. I'll try set some goals which I think will be reasonable and use them as a gauge for timekeeping purposes.  I've briefly been looking into the situation with physics based engines for the game later down the line past the prototype stage and it looks like there are definitely some good options available, but at the moment I can't say if I will be using them in this early design and alpha build of the project.

I believe Scott has drafted up the designs for the different game ideas. It's definitely the kind of thing that we could continue to expand or add more games into after this design stage. We will keep it as the five we have so far but could potentially add some more.

Blog 5

With the ideas for the games starting to get put into motion, I need to start focusing on learning some C#. The concepts that we want to implement are things that I'm unfamiliar with coding, so I'll need to start studying up on different resources. I recall there are a fair number of helpful tutorials and sites which I can learn these areas of C# from. My primary focus at the beginning will be on how to build up the menu system which will be the foundation for the mini games and will also be the main focus of the prototype required for the specification.

Since the game concepts need a lot of fleshing out, Scott is focusing on filling out the designs of the different games and he is going to be looking into some games across different platforms to see what has and hasn't been done before in these styles of games.

Blog 4

After looking into the various games that could be made from the range of events and activities at the Highland games, we have settled on trying to combine a bunch of these into one game. A mini games collection style package, were the player can choose between a group of events to play. At the moment we are going to design a stone put, hammer throw, high jump, bag-piping, and sword dancing themed mini games. Being mini games, we will want to keep easy and simple to undersand control schemes, but still capture the core mechanics of the events.

The rough concepts for each one are as follows. The stone put will be based on building as much power before releasing the stone, via rapid keyboard button presses. The hammer throw will use the mouse to spin the hammer and generate momentum to throw it. The high jump will involve timing a run up with the keyboard and executing a jump at the perfect spacing. The bag pipes will follow a guitar hero style game where notes fall down columns to a song and the player must time button presses which relate to each of the columns and press the keys as the notes reach the sweet spot. The sword dancing game will be a reactions based rhythm game where keys will come up and the player must press them as fast as they can.

The foundation for this mini game collection will be a menu system that allows the player to choose between the different games and view the various instructions and controls for them. As well as be able to view personal best scores in the individual games.

Blog 3

After looking into some of the more athletics style events that we could make our game around, we definitely see potential in the various kinds of games we could make. It's either going to be one of the heavy events where we could make the games quite physics based, or go with one of the athletics style games where there won't be such an emphasis on getting physics. The events which we would definitely most consider at this point are the hammer throw, stone put and high jump. It has also came to our attention that there is a third style of game we could do as well, which would be a more music based approach to the game.

The specification also listed bag-piping and sword dancing as potential game concepts as well. We discussed these as well, and this definitely gives us another avenue that we could implement for the game. A sort of guitar hero style game based on bag pipes or a rhythm game for the sword dancing. We will be finalizing our ideas in the next couple of days.

Blog 2

We brainstormed some initial ideas for our game. As well as just generally looking into the Highland games to understand what else is involved with the games. It was clear from looking at the specification and drawing on our small knowledge of the Highland games, was that there would be an obvious opportunity for a game involving one of the heavy events. Which I think it is fair to say the Highland games is probably most known for. So a bunch of our initial ideas looked at the potential in the caber toss, stone put and hammer throw. These games would be quite simple in concept since they are also very simple as a sporting event. On the other hand, there are also more common sporting events such as running and the high jump which also take place at the Highland games which we could do instead of one of the heavy events. There are definitely athletics style games out there but none particularly come to mind at the moment. So we will look into these a bit more before deciding which type of game to go with.

Blog 1

To make a start on the project, we first looked into the highland games since we would be basing the game on an aspect of the highland games. Looking over the specification there is a range of different sports and events that take place at the Highland games. So we will need to look into these and draft some initial concepts. We will be using XNA C# to implement this game. It will be made in 2D and I'm currently looking into possible physics engines to use for the game if we decide to go for a heavily physics based game, since a lot of the events are games involving throwing big weights around. At this point I'm not sure if we will require a physics engine but will keep it in mind.

We are working on this project as a two and will be working on the various components though I will be working more so on the coding for the project since out of the two of us I fair better with programming. Scott will be working more so in the design area of the project and is going to be starting with the game design document and then the technical specification. We will still be working on the different areas together, but these are the general roles that we will use and adjust them where we see fit later down the line if need be.