Sunday, June 23, 2013

Epic Blog Post

Tonight I am going to post about some of the feedback I have received about my game and the changes that I have decided to make to it.

Level Changes


First, there was one room in particular that has received criticism as being awkward and difficult by play testers. It is room 6 in the first level of the game. This map begins with the player falling from the room above it into a center area surrounded with enemies. Originally the map was designed with a turret on each top corner that players had to ride a platform to and kill in order to advance to the next area. However, this was very confusing, because there wasn't a clear link from the turrets to the doors, so players had trouble navigating the room.



To fix this, I initially put buttons in place of the turrets. This gave players a clear location for where they should be going and trying to get to. However, the number of enemies in the area was still too high, so I reduced the total number of enemies in the room, and added an enemy spawner, so that there is a steady stream of enemies in the room, providing a more consistent challenge. The current version of this map area is shown below.

Art Changes


This change is a work in progress and is not in the current beta build for this game. In the feedback, I often see that players are unsure of what button, switch, or level activates what. I have decided to add a new art function that will visually link a switch and an activator.

In the game Portal, there are very similar puzzle elements that use a similar mechanic. In this game, they solved the same problem by adding a line connecting the two. 


Below is a screenshot of one such room, which contains a confusing switch activator system.



I have included below a sketch of how a line connection system in the game could look, as it is currently planned to be implemented.


The second version makes it much more clear what the player needs to do in order to proceed.

Character Changes


The last change that I plan on implementing, deals with complaints about the characters themselves. In general, players felt that the two playable characters were too similar, and that Mike (blue) was clearly superior to Tom (Red).

The main complaint I got with Tom, was that his shield didn’t feel responsive enough. In order to use it, your character must be still, and there is a delay associated with the player attack that can sometimes keep players from deploying the shield when they want.

I have decided to make the following changes to Tom, although they have not yet been implemented:
  •        Remove delay in deploying the shield after firing.
  •          Allow the player to shift the direction they are facing while blocking
  •         Allow the player to block while in the air, but not while accelerating upward (jumping)

I am also considering allowing the player to move while blocking at half speed, and possibly to fire at a slower rate while block and stationary. These changes will be considered after the above changes are implemented and more feedback is gathered.

In addition, I want to make gameplay as Mike feel more unique. So, I have decided to change the way that mike attacks his enemies.


First, I am going to change the condition on when Mike attacks. Currently, players can hold the attack button down to attack at full speed. However, this will be changed, so that players can still hold the attack button to attack a specific speed, but also have the option of tapping the attack button to attack even faster. This will give Mike the more agile, attack focused gameplay in contrast to Tom’s more defensive focused gameplay.

Friday, June 21, 2013

Well, it is kinda playable

Today, I am distributing a rough playable build. This build includes one playable level (Normal) and half of another (High Winds). I have been working on this game for a class of mine so I have been able to get a lot of work done on it, but with the move to Austin I have been very busy.

In this build I have a completely original art style, except for the sprite used for the main characters. I got this sprite from a Google search and I have reached out to the owner for permission to use it. Here is a link to the animation panel.

http://artofgame.wordpress.com/2009/03/25/project-little-robo-climber-controls-animation-model/

All credit to the animation goes to the creator, @GregPXL

In this build are several new concepts and bug fixes. Mobile platforms now almost work perfectly, with few enough bugs that I'm taking a break on them for now. I have also introduced some new puzzle elements and I have all the level elements fully functional, like high winds, acid rain, and high gravity.



There is still a couple pieces of placeholder art in there, such as the level icons, and the menu system needs an artistic overhaul. However, I am pretty sure I won't be able to get to those by the end of my class, and to be honest I'm not sure I am going to continue this project after that. It has been a ton of fun working on this and I have learned a ton, but I also don't want to get bogged down into a single project for my entire academic career. The more I have to show as my work the better.

Anyway, below is the current build of the game. Like I said before, there is one full level, Normal, and one half level, High Winds. The others are testing areas that don't take you anywhere.

https://docs.google.com/file/d/0B-PWPsdVYXH6VjhaMFBmZDd2VzQ/edit?usp=sharing

Saturday, June 8, 2013

Pardon the Dust

Sorry for the lack of posts, I have been very busy getting prepared for a move to Austin, Texas. I have been very busy preparing for it, and I haven't had as much time as usual to work on my game.

That being said, this week I am working on overhauling the artwork. I decided to change the game to a much simpler art design, looking at things like old Atari games and Geometry Wars for inspiration. Artwork is something I have pretty much no talent at whatsoever, so it is unlikely that I would ever get far enough doing pixel art in any reasonable amount of time to have for this game, so I opted for something similar.

In addition to new, simpler sprites for everything, I am going to add particle effects to more objects to give everything a better sense of cohesion and action. So far I have completely some of the very basic enemies and projectiles, but I am having a very difficult time with the player characters and bosses. At first, my original thinking was making Tron like entities, but I haven't been able to make anything worthwhile so far, so I may have to look at simpler options.

Below is a screenshot of a testing level, showing what I have done so far with the new art style.


Saturday, May 25, 2013

This week, I managed to overhaul the way the game saves and loads tilesheets for the editor and the game. I have made it so that new tilesheets can be loaded in to the editor and saved on a per map basis. This allows for separate development of the art side of the game from the programming side and allows the user to see changes to the tilesheets pretty much immediately. Unfortunately, this programming change means that the old maps I had saved no longer function, so I had to rebuild some new ones. That means in the build that I am publishing tonight, only the first few maps of the Earth level are functional.

Also, I created and implemented a new AI type this week, called the AITurret. This AI type is stationary and fires projectiles in a specific direction. Also, I linked in the switch - activator system into the AI turret, so I can now make it so that the death of the AI turret triggers an activator elsewhere in the level. This allows for new puzzle mechanics based on this premise. I am considering adding this functionality to the AIBase class, which all enemies are based on, so that any enemy can trigger the system, but at this time I haven't.



I am still working on the physics for mobile platforms. They have collision correctly, but for some reason, standing on top of one doesn't always trigger for the player to allow them to jump again and to shoot and use the shield.

I also discovered this past week that I don't have to compile to one_click applications to publish my game, I can just build it and upload the debug folder. So, any build from here on out shouldn't need any installs, just unzip to a folder and play. I'll edit once the sync is complete with google docs :)

Edit: And the link is up :)
https://docs.google.com/file/d/0B-PWPsdVYXH6NWVjNDR1RHdBMDQ/edit?usp=sharing

Tuesday, May 14, 2013

Last week, I read an article about tools for game related purposes and it really inspired me to work on my level editor some.

http://www.gamedev.net/blog/1562/entry-2256353-tools-dev-whats-it-do/

As my game has been getting more complex, so has been working with the editor. Some of the new entities I have made, such as mobile platforms, require as many as 5 arguments in their constructors for determining their properties. Previously to make those in my level editor, you would have to select the base entity, platform, and then type each individual argument with a space between each one, with the argument order memorized.

So the first thing I have done is simplify the entity creation portion of the editor. I change it from requiring manual entry to a small system of drop boxes and input parameters.

This should make it much easier to make levels, since you won't have to memorize the parameter order. You still have to have some knowledge of the game though. For instance, in this case, the destination is two coordinates with a space separating them. In this case, the platform would move 10 tiles down. Also, the platform type is a simple enum, in this case with 2 being fully automatic.

Later this week, I hope to add new options for the tile map, such as being able to load one in dynamically, instead of having to hard code each one. However, I have a feeling that won't be as easy as adding a "load tilemap" button with the tools at the top. I am considering something along the lines of a C# Dictionary that it uses during a loading phase, which the tile engine can then copy a specific entry from each time it loads a new map.

However I do it, it isn't something that is covered in the book I have on XNA game development so I am going to have to do some research. It might be a good time to change the way level files are saved and loaded, since currently it is the only thing that keeps it from completely compatible with Xbox Indie Games.

Thursday, May 9, 2013

Tonight, I was able to get a ton done on my game, thanks to beginning my new class at DeVry, a cup of coffee, and some good planning. I implemented the previously mentioned unblocking entity, which allows me the change the shape of the levels based on which game type is selected. I also created a switch and activator system, which allows me to begin some very basic puzzle elements in my game. I also added, finally, Mike's special ability, the double jump.

I am publishing a new build, which I am uploading as I write this. I will update this post once it gets done. I have also fleshed out the game's opening level, Earth. The Earth level now consists of 4 small maps and one boss encounter. I left myself plenty of room in the editor, however, to go back and add more maps to the Earth level as I add more game play elements, such as moving platforms, levers, and enemy types.

I'll finish with a couple of screenshots of my switch - activator system in action.



EDIT: Here is a link to the latest version of the game https://docs.google.com/file/d/0BxShUEdw7OSlbzhWNnI0LURqSnM/edit?usp=sharing

Sunday, May 5, 2013

Well, today I pulled one over on myself by not working at all on the entities I had told myself I would work on this week, and instead I added a new function to my level editor and game to implement different tile sheets for the game to run off of. Before I had been limited to a single tile sheet, which I had hard coded. Now, users can select which tile map to use for each level that is created. This opens up an easy method for loading in different tile sets without having to change one big one with all the different levels in it.

The loader is flexible and can load up whatever size sets that are input, as long as it can be divided neatly into 48x48 pixel squares.