Final Post Review Attempt Etc.

I attempted to review a game last night, but we got an error stating that our account was associated with another account. Perhaps someone else was using the account at the time, since people said they got it to work later. Anyway, I'll try again later.

Today is presentation day, so my team's been working on getting a level set up for the demo and completing some really basic AI. I wasn't really able to get anything done, but I did close some items from the sprint last week that I had finished.

Nothing New But Update For Last Week

So due to end of semester craziness, I wasn't able to do anything this past week; however, I missed telling ya'll what I finished last week. We have the target box drawing, though it's huge and only partially drawing opaquely. For now, we have it set up so that there is a "begin targeting" button, which gets a list of all the enemy ships in range and targets the closest one. From there, you can use different buttons to toggle through the list. The list is not refreshed until you push the "begin targeting" button again. This we can keep the implementation simple. We may change it in the future, but we may not.

Lock On!

For our latest sprint, I've been tasked with implementing the target lock and pod tracking system for our game, and it's turning out to be a doozy. We were initially thinking that we would allow the player to toggle between the five targets nearest to her, but what I've implemented of that do far seems a little impractical. It would involve a huge amount of iteration, cross-checking, and updating of player history, and I'm just not sure it will be practical. Jason suggested that, for now, we just target between the nearest and next nearest ships. This will move the number of iterations through ships down to one, and will take a lot less time to implement. Now we've just got to sell the rest of the team on it. Perhaps we'll flesh it out next semester when we have more time.

More Pos Screen

The pause screen is fairly near working at this point, but there is an odd error that occurs when you enter the Options Screen through the Pause Screen and then exit back to the Pause Screen. It's display a large, brown... graphic. Anyway, once we figure that out, we're going to make the sound options functional - so you can turn the music and the sound effect up and down. We probably need to take out the screen resolution changes too, since those don't make much sense for a console game.

Controller Screen

On Tuesday Jason and I focused on implementing the control customization screen. As it stands, we are going to have several per-made control schemes that the player can choose from. We made it so they can change the scheme along the bottom of the screen, and the controls mapped to the buttons update according to the scheme. Next we are going to put some finishing touches on the screen, decreasing the font and fine-tuning the layout of the button labels, as well as making the options chosen there and in the option screen actually holding throughout the rest of the game. I fell like we have a direction now, and we're getting stuff done. I initially felt like a slacker because I wasn't doing anything, but since I have specific tasks assigned I feel much more comfortable in the team.

Options Screen

We finally got to work this weekend, with some fairly satisfying results. Jason and I were made responsible for implementing the options screen, including control customization. We still need to implement the latter, but the general option screen is fairly well done - though we do still need to discuss with the group how to handle the option variables (we'll probably want them held in the screen manager). The option screen needs both sliders (for sound) and the ability to scroll left-right through 3 options (low, med, high), resolutions, etc. The graphics are preliminary, but we set the layout up in such a fashion that it will be easy to modify as the graphics change.

Space fighter game ho!

So we've been a little slow getting programming going, but this week we're planning on starting our meetings. We're planning on doing 4 meetings per week, with it required that you come to at least two. I may try to put in more time now so I will have less to do around the end of the semester. The structure we've drawn up for the programming looks good, and though I'm sure a lot of the nitty-gritty will change, I think that will mainly stay the same.

Our main contentions and decisions to be mad at the moment concern how we are going to set up our levels. Since it may be a little out of reach to create a 3d level editor, we'll need to pretty much create each piece of each level separately. That may limit the number of levels we are able to build, but will also allow us greater flexibility in how we use those pieces.

Final Presentation and Voting

Well, the presentations are over and I'm both relieved and disappointed. What started out looking like solid progress ended up looking pretty lame next to what other groups had to show. In the end our game just didn't stand up against the others. Part of me is a little bitter, because while we wrote all the code for our prototype, it's fairly clear that many of the other teams basically just used stuff that was already created. Not that I can blame them, since that was the point of the prototype.

I just hate feeling like our game got a short schrifft - having a team with only three people in it to beginning with, but ending up with only two people actually working on it just wasn't enough. CP said he had some family stuff come up, but he ended up not even coming to the presentation - which I guess I'm fine with since he didn't do anything for it.

Anyway, after this post I'm moving on. I find myself being way too emotional about this whole thing, and I don't want that to cause me to put less than my all into the next project. I'm not expecting ours to be chosen, so I'm putting it behind me.

One more weekend

And I have no idea how we're going to do it. I suppose that the random level generation is nearly good enough to present, and the equip screen is nearly perfect for the presentation, but then there are the battle scenes showing the unique character spells - something that I'm supposed to do this weekend. Thing is, I have a big homework assignment(I finished the other big one early) due the same day, as well as a test the day after and another presentation for a class(same day) and a super-urgent project I have to spend time on for work. I guess this is what I signed up for, but what a perfect storm. I hope that I can make something good enough to get our game through to full production though - it deserves it.

Arguing about gameplay

I started this post last week, but it wouldn't let me do more than write the headline on my phone. We argued for a while last Tuesday about adding a "hook" to the game, and I played my standard role of contrarion. Oh well. I got my point across. C.p. suggested that we add in a crafting system and gave us a demonstration of some mining game with a really intense crafting system. From the beginning I didn't feel very comfortable with the idea of implementing something similar in our game, but it took me a while to get around to the "why."

Eventually I figured out that I was uncomfortable because I felt adding something like that would take away from what the game was about - gear acquisition and levelling. I felt that adding an intense crafting element would make the game something else altogether. Mainly this is because there are two options with the crafting - if you make it so that nearly everything must be crafted, our game would force players to craft hundreds of items each trip down into the dungeon, making the same weapons on each trip. The other possibility would be that it would be so rare that there'd be no point in adding it in.

In the end, we came to a compromise though: now players can craft items, but they don't actually touch the materials to do so - the game lets them disassemble items and then just tells them what they can make and they can select what they'd like to make. This keeps the crafting system useful but more cleanly integrated into the game.

For Today, the 18th:
Jason and I are doing another marathon day at the lab, getting the equip screen "working". It's just hacked left and right, but ingeniously so. I'm doing most of the graphic work for the screen, since we haven't seen CP since Tuesday and haven't received anything from him yet. I really hope that we can get some nice artwork in here.

We are trying to make it so we can show of the spell individualization, the combination spells, and eventually the combat - which we're likely just going to have to fake in a video editing software. Anyway, we're getting closer and closer. I really hope our game gets chosen because I want to play it!

First Steps

Jason and I started in on the game this morning and worked from about 10am to 6.5pm. We got the random generation of the level set up, and got a bunch of placeholder graphics in. CP says he's got some graphics, so I'll see about adding them in on Monday if he gets them to me. We had the strangest bug with updating the monsters' random movement. Perhaps we had too many monsters on, or perhaps we're just missing something small, but we worked on it for a good amount of time.

We'll be working on more next weekend on getting the equipment screen set up and fixing the movement. Then, hopefully, we'll get the combat going the final weekend. Otherwise, we'll just have to fake something.

Getting the Ball Rolling

So I wound up on Jason's team, which is nice because not only to we work really well together, but I also like the game idea. Our other partner is C...P? I think his name is? I'll have to ask. Anyway, we discussed a lot of things on Tuesday. We were trying to work on the prototype, but we kept getting sidetracked by the vision of the whole.

Regardless, CP is'a be working on getting some placeholder art to populate our prototype(stairs, chests, monsters, and a player character. Jason and I will be working on the programming this weekend (should take 5-10 hrs). For the prototype we are keeping each "level" fairly non-descript, and they will just fill the screen. We're just going to try and get functionality for spawning mobs and chests randomly within the grid of the level, get the stairs working to populate new levels, and get some sort of battle system and equipment going on. (Okay, maybe 15-20hrs).

Game Ideas

I'm working today on coming up with a pitch to make to the class tomorrow. I'm finding that my main problem is with keeping the scope small. Every time I think of some cool idea and run with it for a while, it seems to end up practically turning into a game of its own. Anyway, I'd like to do an educational game for kids using addition, subtraction, and multiplication. Of course there are already games like this, but they aren't necessarily the most fun. I'd like to make something where the math is there and is still intrinsic to the gameplay, but is perhaps not thrown in your face so bluntly. I'm thinking along the lines of using equations to fight monsters. The character will start out only able to load one operation into his "gun" at a time, and will only possess the number "1" as ammo. As he grows and/or neutralizes monsters, the gun will level up, accept higher numbers, and will gain the ability to chain more operations. An added element will be the ability to upgrade your weapon with rare pieces gained from monsters by dispatching them with fewer operations. We could do something fun with prime monsters. :)