Friday, July 29, 2011

Tutorial: Unique Weapon Skills In RM2K(3)

Instead of just blabbing on about other people's attempts at amateur development all the time, I figured I would start posting some tutorials for anyone out there who's considering using something like RPGMaker to create a game. Since most of my experience is with the RPGMaker programs, I'm going to focus a lot of these tutorials on those engines, but I hope the general concepts carry across and that people can also use these tutorials to work out how to make things in other programs too!

Without further ado, here is another entry in this series of tutorials: How To Create Unique Weapon Skills In RPGMaker 2K(3)!

-------------------
 
This is a tutorial that will let you create skills that are only usable whilst the character has a certain weapon equipped. This system is heavily used in Sore Losers because I think it brings another dimension to the slightly zany, non-standard weapons you could place in a game; weapons like Paintball Guns and Hockey Sticks. It also adds a little strategy to item selection, meaning that this is a simple way to add a little depth to your game. 

The first step is to make the weapon and the skill respectively. You do not need to do anything special here, just make the weapon and the skill as you normally would any other weapon or skill. Ideally, the skill/weapon combination should be as unique as possible so that the skill needing the weapon makes sense. For instance, using paint to blind enemies would be a good idea for a Paintball Gun skill.

The second and final step is actually coding the event. In the example here, the character "Markus" is going to learn the skill "Hooking" when he equips a "Hockey Stick". If the "Hockey Stick" is unequipped then he will forget the skill. The code is relatively simple and should be placed into the maker as a "Common Event". The event should be set as a "Parallel Process" so that it is always actively checking the equipment the character has on. 

You can see the code here: 


That's it. A simple system that lets you add a slight element of strategy to equipment selection.
 

Thursday, July 28, 2011

Hype: Forever's End

Forever's End is a traditional JRPG that seems to have been in development for as long as its title suggests. In fact, it's been in development for so long that I've reviewed it twice, the most recent of which you can read here. For an RPGMaker game it has overwhelmingly good press, having being reviewed 15+ times with an average rating of ~8/10. It is also an award winning title, being the winner of the RPGMaker.net's "Most Promising Demo" award in 2010 (an award that it beat my own game, Sore Losers: Riot Grrrl, to win) and the winner of RPG-Atelier.net's "Project of the Month" award for June 2011. When you stack all this data up, it's easy to see why I'm hyped about this game, even if I haven't got a clue when the final version will be released!

 Forever's End is a highly acclaimed JRPG being developed by NicoB.

The game itself is pretty standard as far as JRPG games go. You fight battles, solve puzzles, uncover plot details, fight more battles etc. What makes the game so good is how polished all of these gameplay aspects are. Even in the very first demos released for this game, it was obvious that the final product was going to play incredibly smoothly and with the latest release - the entirety of the "first episode" - it's clear that this is the case. The battles are well-balanced and never feel like a chore to play through, and additions such as the monster capture system (capturing all of the monsters in a certan area will unlock rewards from an NPC) spice up even the most mundane of encounters. The maps themselves are well worked, especially those that contain puzzles, and since the battles aren't encountered randomly you are able to fully enjoy each puzzle without having to worry about getting stuck in a battle half-way through trying to figure it out. The encounter system itself is pretty clever, since you're able to sneak up on enemies to gain an advantage in battle if you're careful enough. It's a system that's been used to great effect in other games, games like the Grandia series, so it is hardly ground-breaking... but that doesn't stop it from working!

Unfortunately, some of the graphical polish doesn't match up to that provided by the gameplay, although this has never stopped me from enjoying a game before. The graphics are competent but there are a lot of little flaws that you will notice the more you play. Passability is a big issue as there is a lot of weird passability - you can quite often get to places you're clearly not meant to be able to and, although this is never advantageous or disadvantageous, it is pretty irking. Other little things, such as the battle animations not reacting to the tinting that is being used in a battle, will be easily spotted and noted as you play through the game. It's hard to deny that the cutscenes look amazing, though:

The game features impressive, comic-book style cutscenes that look truly amazing.

Forever's End, along with Feldschlacht IV's Chronology of the Last Era, is one of those RPGMaker games that seems to have been in development for ages. I don't want the developers to rush what they're doing because it might make the games worse, but sometimes I want the finished games now!

You can check out the homepage for Forever's End here: http://rpgmaker.net/games/650/ 
 

Tuesday, July 26, 2011

Tutorial: RPGMaker Lingo

Ben_Random over at RPGMaker.net posted a useful guide to the phrases we use in the RPGMaker community that might be useful for people who are new to amateur gaming. I was going to write something like this myself, but Ben has done a pretty decent job so it seems a waste not to credit his efforts. I have made some edits to the original so, if you wish, you can find the original guide here

----------

When I first got to RPGMaker.net, I simply wanted to play a game. In order to play a game, someone said that I needed the "2K3 RTP". I had no idea what the "2K3 RTP" was! I imagine other people have had similar problems, so this tutorial is to help people new to the RPGMaking world understand what the heck is being said:

ENGINES:
An engine is a piece of software. RPGMaker is an engine used to make games. To look at RPGMaker.net's full engine run-down, click here. Let's go through a run-down of the more common engines used:

The RPGMaker Series:
This is a series of engines that was designed by a company called Enterbrain. These engines are the ones commonly referred to as RPGMakers, or RM for short. There are many RM engines in this series, some of which are new and some outdated.
  • RPGMaker 95 - This first engine is one you will probably never use. This was the first RM software and was originally designed for Windows 95. Chances are you won't come across this one.
  • RPGMaker 2000 - The next RM engine released was called RPGMaker 2000, which you sometimes see today. This engine is commonly referred to as RPG2000, RM2000, RM2K, or just 2K. 2K was never officially released in the west and was instead unofficially translated by Don Miguel.
  • RPGMaker 2003 - The third engine I will be discussing is more common, RPGMaker 2003. This RM software was designed as an "upgrade" to 2K. It has more features, but is still best for making old school RPG's. Like 2K, it was never officially released in the west. This engine is commonly referred to as RPG2003, RM2003, RM2K3, or just 2K3. Since 2K3 is so similar to 2K, people will often write tutorials for both engines etc. and when people are talking about both engines at once they will say, "2K(3)" or "2K/3".
  • RPGMaker XP - This next engine is much more common and often used today. This engine is called RPGMaker XP. This engine was designed for Windows XP. It is the second newest software in the RM series. This engine featured a new scripting language that allowed heavier customsation of the games menu and battle systems, amongst other things, giving people greater freedom. The scripting language is called RGSS (sometimes referred to as Ruby). This software was the first of the RM engines to be officially translated into English and so can be purchased legally from Enterbrain. The engine is commonly referred to as RMXP, or just XP.
  • RPGMaker VX - The newest RM software is called RPGMaker VX. This engine was designed for Windows Vista, but is also compatible with Windows 7. VX was designed to be a more user friendly RPGMaker than RMXP. In the process, many features that people liked in XP were not implemented into VX. One thing that VX is infamous for is its tileset system, as it only natively supports five tilesets (previous RM programs could have far more than this). Although VX lacks some features, it still contains the ability to use scripting, albeit with a new scripting language: RGSS2. This language slightly differs from the original, so don't get the two confused. RMXP and RMVX are sometimes referred to collectively as RMVXP, usually when being compared to RM2K(3). I have written a tutorial series called VX for Dummies. Click this to read it.
  • RPGMaker 1, 2, and 3 - These engines were designed for the Playstation series of consoles. I will not be disscussing these engines, as games for them cannot be commonly found on the internet.
  • RPG Maker 20XX - A customised version of RPGMaker 2003 designed by Wolfcoder. Aims to implement a lot of features missing from the earlier makers without users having to purchase RMXP or RMVX. More information can be found at http://rpgmaker.net/engines/rm20xx/ or http://rpgmaker.net/games/2664/

The GameMaker Series:
GameMaker (GM) is a point-and-click engine used to create action games such as platformers and shooters. People can design games with this engine if they have no programing knowledge, or if they have scripting ability they can use the built in script editor.

Super Mario Bros. X
Commonly referred to as SMBX, this is an engine designed to create Mario World fan-games. This engine is somewhat buggy and chances are those bugs won't be fixed, but that is not any reason to drop SMBX all together. It is still a great engine.

Those are certainly not all the engines out there, but it is enough to get you started.

OTHER LINGO:
There are many other terms that you will see out there in the amatuer RM game design world, here are a few of them:

RTP: 
RTP stands for "Run Time Package". Each RPGMaker engine has its own RTP that needs to be downloaded to play games created with that engine. Most developers will include the RTP with their game, but if you download the RTP in advance then you can save file-space by downloading non-RTP versions of the games you want to play. You must download an RPGMaker RTP to use the engine as well.

Map:
A map is a term used for a room or place in an RM game.
Event:
An event is a term used in many game-making programs, but most especially in RPGMaker. An event is what makes things happen in a game. To see the event screen in VX, click here. Some people will refer to the art of creating events as "eventing" to parallel their efforts with "scripting", this is as events can be used to create things as simple as non-playable characters or things as complex as whole battle-systems. It is generally agreed that, the more difficult a system is, the better it is to use "scripting" than "eventing" to create it (and vice-versa).

Resources:
Resources are graphics and audio that can be imported into a game engine. Once resources are imported, the game designer no longer has to use the default set of graphics and audio. To read my tutorial on importing tileset resources, click here. To find resources for your game, click here.

Sprite:
This is not the soda. When people talk about sprites on RPGMaker.net, they are talking about a form of resource. A sprite is a set of pictures compiled into one image that a game engine can use to provide graphics for animated objects. Here is a picture of a sprite:




Rips:
A rip is a resource from another title you are using in your game. For example, if you are putting Mario graphics into your game, you are using Mario rips. Some rips are infamous for their overuse and so are best avoided, such as music from the Final Fantasy series or the "Rudra" tileset series.

LP:
Not a way to listen to music. LP stands for "Let's Play". People will often record themselves playing through a game for entertainment, or to provide a walkthrough, or to review the game. These videos are usually found on YouTube.

FURTHER READING:
If you would like to know more about RPGMaker, or RPGMaker.net, here are some helpful links:

The Master RPG Maker Things Helpful Topic
New to RMN
Help & Request Topic

That's all folks. I hope this info was helpful.
 

Sunday, July 24, 2011

Review: Heirs of Techcatl

Title: Heirs of Techcatl
Developer: Immudelki, Foretnor.
Translation By: Creation
Homepage:  http://rpgmaker.net/games/2685/
Genre: Adventure
Program: RPGMaker XP

Heirs of Techcatl is a game that came to the English RPGMaker community from French soils and was subsequently translated for us by Creation, an active translator in the RPGMaker community. The game was then featured on RPGMaker.net. It takes place in a dystopian, alternative history were the Democratic Republic of England has emerged from the Great War with seeming dominance over most of Europe. This new republic is ruled by a dictatorial leadership and, predictably, the game revolves around a rebellion that's led against said leadership. The game focuses on the actions of Emmett Berglindh, an ex-pilot for the Republic who is now the curator of an aviation museum, as well as being a self-labelled supporter of the Republic.

When you look at the screenshots available for this game, it's easy to see why people were drawn into it. This game is undeniably pretty and employs heavy use of lighting effects, overlays and other tricks to bring each of its hand-drawn maps to life. This beauty seeps out into all the other areas of the game. From the look and feel of the menu systems to the animation of the NPCs to the cutscene stills that are used for the sake of story-telling, everything looks amazing. If you're looking for a game that contains a lot of eye-candy then this is definitely it, because I can't think of many games that look better than Heirs of Techcatl does.


Heirs of Techcatl is definitely a pretty game, as these two screenshots show. The use of effects like steam and lighting makes for realistic environments, while the hand-drawn backgrounds are some of the best you are likely to see!


Unfortunately, the aesthetics department is the only area of this game that actually possesses any semblance of competence. The rest of the game is a mess of broken mechanics, ridiculous storyline twists, unbelievable characters and system bugs. What time you don't spend admiring the pretty graphics, you'll spend cursing the poorly thought-out mechanics, wondering whether or not a character really just did what they did or going mental because the game has a penchant for crashing whilst you're trying to save your progress (that's right, this game just loves to crash when you're trying to do the one thing that allows you to avoid re-playing large swaths of the game due to a crash!)

Let's start the enquiry into this train wreck with the gameplay. The central gameplay mechanic is "+success", a system that rewards you points for successfully doing things within the games universe. However, most of these events are incredibly trivial, have little-to-nought to do with the storyline and basically require the player to be psychic (or to have written down everything they've observed throughout the course of the game).

Unless you're psychic or you abuse the save-anywhere function, that success bar isn't gonna get very high. Note also the untranslated "What To Do Next" dialogue, how helpful!

For example, early on in the game you will see a poster that explains who the Republic is currently fighting against. Much later in the game, after a number of important plot-events have occurred, an NPC will randomly ask you if you like the posters. If you reply that you do, he will then test if you really do know the posters he is talking about by asking you who the Republic are fighting against. Getting the question right awards you with "+success", the problem with this being that the player is unlikely to remember the answer unless they wrote it down, which they're probably not going to do unless they already know that the NPC is going to ask them about it (ergo, the player basically needs to be psychic). Plus, this assumes the player even managed to view the poster, since it isn't exactly something everyone is going to go and inspect.

Another similar NPC asks you for the name of an engine that is used in a particular type of plane, just to test how good of a former aviator your character really is. However, the name of the engine is a random string of letters and numbers that you have no chance of remembering unless you decided to write it down (and especially not when you need to take a break from the game to use the phone, which is what I did). What is the point in this irrelevant memory test!?

Yet another flawed gameplay mechanic is a time-based minigame were you're asked to input a series of commands to get your character to do a task. On one of these occasions, you are inputting a code in order to get your character to dodge some bullet-fire: However, even if you fail this event, the character just runs through to the next room without his injury ever being mentioned. It's as if the gunfire scene never happened, leaving me wondering, "What was the point?" Not to mention that this element of the gameplay is actually broken on one occasion, an occasion were you are required to dodge a spike-trap. At first I thought I had just put the code in wrong, but after I made several attempts at the code (just to make sure I wasn't being an idiot), I came to the conclusion that it was indeed bugged. Luckily, this bug probably didn't have any effect on the plot anyway since these minigames seem completely irrelevant... but it was an unneeded distraction nonetheless.

To be honest, I seriously don't understand why anyone thought these gameplay elements were a good idea and I can only imagine the plan is to get people to play the game more than once so that they can see the "secret ending" you supposedly recieve for a 95% "+success" score. I'm not a big fan of this sort of mechanic when it is done in such an obvious way, as it's a method that almost ensures a player's first play-through will be incredibly frustrating. I guess another criticism I have of these minigames would be that I get the impression the developers tried too hard to shoehorn interaction into the storyline. It isn't actually important to have gameplay elements if all you really want to do is tell a story and, as such, I think that this game would've been a lot better playing out as a visual novel without any dodgy gameplay elements to spoil the show. The broken game often makes it hard to concentrate on the plot since it's so frustrating, which only harms what I assume was the main point of interest (the storyline).

Although, truth be told, the storyline is a complete and utter mess too. The main problem is that the characters in this game have a habit of doing things for no particular reason, even though those things go against the personality they've been shown to have or against the ideals that they seem to uphold. It's kinda hard to go into details without spoiling the storyline for people, but there were numerous occasions in this game were I basically said to myself, "Lolwut?" One such occasion - an occasion that is unlikely to spoil anything for people who may want to play this game after reading this review - comes during the scene were Emmett is turned to the cause of the rebellion. I felt that the scene took a character who seemed rather happy in his support for the Republic's government, happy in the job that he had and generally happy with his life and made him flip-flop over to the side of the rebellion far too quickly and with far too few reasons. If fact, this scene is the least of the game's worries, as several other scenes are much worse. The ending scene and the scene that occurs before the aforementioned shooting scene are definitely candidates for the "Most Ridiculous Character Flip-Flop In An Amateur Game" award. The game's plot is basically a series of faulty justifications for Emmett being forced through another set of difficult circumstances (and broken minigames). I didn't enjoy it at all.

Some of the NPCs are actually kinda funny, but they can't make up for the terrible plot.

Ultimately, the only thing this game has going for it is how pretty everything is. Without the terrible, broken gameplay elements it might have managed to be a slightly below-par visual novel but, as it is, this game is nothing but a string of facepalm moments. 2/10.
 

Friday, July 22, 2011

Tutorial: "Demi"-Style Skill In RPGMaker 2003

Instead of just blabbing on about other people's attempts at amateur development all the time, I figured I would start posting some tutorials for anyone out there who's considering using something like RPGMaker to create a game. Since most of my experience is with the RPGMaker programs, I'm going to focus a lot of these tutorials on those engines, but I hope the general concepts carry across and that people can also use these tutorials to work out how to make things in other programs too!

Without further ado, here is the second in this series of tutorials: How To Create A Demi-Skill In RPGMaker 2003!

-------------------

To make this type of skill you are going to need:

- A "fake condition" that actually does nothing.
- A skill named "Demi" (rename it if you wish) that has a unique MP cost.
- Two variables ("Current MP" and "Dummy MP").

First, create a "fake condition" that can be inflicted on the enemy. This "fake condition" doesn't do anything to the enemy, runs out after one turn and doesn't have a name, giving the illusion that nothing was actually done. This "fake condition" allows us to determine which enemy is being targeted without having to change any of their stats - it is unnoticeable.

Secondly, create a skill that inflicts the "fake condition" on the enemy. Make a note of what "type" you set this skill up to be and make sure it is not set up to be "normal"-type as this will stop the skill working.

For the purpose of this tutorial, the "type" will be called "Active".

What is more important than the "type" is that the skill has a unique MP cost that no other skill uses as this MP change will be used to trigger the battle-events. I cannot overstate how important this is - no other skill can have this MP cost and no skill can decrease the hero's MP by this amount or else the skill will trigger when it hasn't actually been used!

For the purpose of this tutorial, the MP cost will be 7.

After setting up the skill, you need to create a battle-event that triggers on the very first turn of the battle. This event will be used to "zero" the MP variables we're going to be using. This event should be set up like this:

 

As you can see, the hero in this example is called Cheska. Swap this for the hero you are going to have casting the "Demi" spell in your game. Make sure you do not set the variables to the hero's maximum MP as this will prevent the skill from working - it has to be set to current MP.

The next battle-event you need to create will be triggered by the hero using the skill-type "Demi" is filed under. Remember how I said that "Demi" will be filed under "Active" for the purpose of this tutorial? Well, here is where this becomes important. This battle-event should look like this:

 

This basically does the same thing that the initial event does. It "zeroes" the variables that are used. The difference is that this triggers directly before the "Demi" skill will be cast, making sure that nothing should go wrong.

The final battle-event is the part that does damage. It needs to be set up to trigger when the hero's HP is between 1-100%. Why? Because this trigger is checked straight after a skill/attack is used and hence retains information on which enemy is being targeted. We need to know the target so we need the event to trigger at this time. This battle-event should look like this:

 

What is happening in this battle-event?

1) The "Dummy MP" value is set to whatever it is at the end of the character's turn.
2) If the "Dummy MP" value has changed it will be different to "Current MP" as that is still at the same value it was before the turn started. We can therefore check "Dummy MP" against "Current MP" to find out if a skill has been used.
3) If MP has changed, "Dummy MP" is subtracted from "Current MP". This will make "Current MP" equal the MP cost of the skill that was used.
4) If this MP cost is 7 (the cost of the "Demi" skill in this tutorial) then the targeted enemy is damaged by 50% of their current HP.
5) Both "Dummy MP" and "Current HP" are reset to the hero's current MP to prevent the damage being dealt repeatedly.

Make sense? Obviously, in this case there are only two enemy's present, you need to expand that to encompass all enemies in each enemy group. If you want to make it so bosses are invulnerable to "Demi" or take lesser damage then just change the 50% to something else when you come around to dealing damage to them.

Happy eventing!
  

Thursday, July 21, 2011

Hype: Backstage II

A fairly long time ago (2005), a game was released that I absolutely loved, that game being Backstage. Since Backstage was a survival-horror created using fairly cartoonish, 2D sprites, I thought that there wasn't a chance in hell that the game could scare me in a visual sense... and I was right. The graphics didn't really work and certainly didn't contribute to the amount of "horror" present in the game. However, the game still managed to be creepy, all thanks to a well-written plot and a cast of incredibly weird characters. In fact, I'd go as far as saying that Backstage contains one of my favourite NPC characters of all time, one Detective Wilks... you'll just have to play the game to see why else I'll spoil it for you.

 Creepy title screen? Check!

Anyway, this is fairly irrelevant since Backstage has been out for a while now. What is relevant is that the developer, Max McGee (who currently has one of his games, Iron Gaia, featured at the moment) has re-started work on the sequel, Backstage II, after a long hiatus. I couldn't be more excited! Sporting a new menu-system coded by Archeia_Nessiah, a vastly improved battle-system compared to the original and a set of graphics and maps that actually look like they belong in a survival-horror game, all Backstage II really needs to do to ensure its success is to replicate the terrific storyline that the first game featured. Here's hoping I'm not dissapointed if (when?) this game is finally released!

Better lighting effects and maps should make Backstage II a better horror game, at least in the graphics department.

You can check out the RPGMaker.net homepage for Backstage II here.
Or you can visit the developer's site, Ghostlight Games, here.
 

Sunday, July 17, 2011

Tutorial: MGS-Style Guards In RPGMaker

Instead of just blabbing on about other people's attempts at amateur development all the time, I figured I would start posting some tutorials for anyone out there who's considering using something like RPGMaker to create a game. Since most of my experience is with the RPGMaker programs, I'm going to focus a lot of these tutorials on those engines, but I hope the general concepts carry across and that people can also use these tutorials to work out how to make things in other programs too!

Without further ado, here is the first in this series of tutorials: How To Make MGS-Style Guards In RPGMaker!

-------------------

This is a tutorial for a guard system using a field-of-view. I would use the phrase "cone-of-view", but since RPGMaker isn't brilliant when it comes to forming cones (since it uses square tiles) I will use the word field instead.

The guards in this tutorial will "see" the 6x3 field in front of them (1 square either side of them and six squares in front) no matter what direction you cause them to walk in. This area can be changed by modifying the variables used and I will tell people how to do this if they ask for a specific area. Since this is always true, though, they can technically "see" through walls, around corners etc. Unfortunately, making guards that miss out hiding places is very specific to the set-up of the map in question, so I can't cover that in an unspecific way. Again, if you want to do this then I can tell you how if you ask.

Anyway...

To make this system you are going to need two variables;

Guard X 
Guard Y

You are also going to need two switches;

Guard Gets You 
Guard Dead*
 

*Of course, if you want the guard to do something other than fight you won't need this switch. Instead of turning this switch on, just turn off the Guard Finds You switch at the end of the second page. See later. 
 

The guard event needs to have 3 pages. The first page will be a "Parallel Process" and will be set to "Move By Route". You can set any route you want, the guard will always respond to the direction they are facing in. The code for the event should be something like this:
 

 
This will trigger the second page whenever the guard "sees" the hero walking around. The second page I chose was for the guard attacking the hero, but if you want to do something else then just replace the code in the second page with whatever cutscene you have cooked up. In any case, the second page should be set to "Auto Start" and also set to "Stay Still". It should look something like this, keeping in mind that the trigger for this page is the "Guard Gets You" switch being on:

 
 

The final page is triggered when the battle is over, and is simply a page of nothing. Of course, if you want to have the second page not kill the guard and simply teleport the hero back to the entrace or whatever then instead of turning on the "Guard Dead" switch turn off the "Guard Gets You" switch. It really depends what you want to happen, this is just a basis.

Whatever you choose to do, the event that completes this sequence should be a blank event that is set to "Below Hero" and "Push Key". It does nothing at all, so I shouldn't need a picture, just keep in mind that the last page is triggered by the "Guard Dead" switch being on.

And that's it.
  

Thursday, July 14, 2011

Devblog: The Fear


The closer I get to finishing my game, Sore Losers: Riot Grrrl, the more I wonder if I'm doing the right things. I'm usually pretty stalwart about whatever it is I'm doing, as you might have realised from the way I go about reviewing games, but that doesn't mean I'm completely ignorant to the comments that are made about my projects or completely immune to the fear of failure that developers develop the longer they spend working on a project. Unfortunately, and perhaps regrettably, this fear grows despite the fact that a lot of things have been brought to my attention regarding this game. Although I have attempted to fix some of the problems that have been brought forth, I have been quick to dismiss other comments as suggestions that didn't align with what I envisioned this project to be... which was perhaps stupid of me.

Of course, I'm not the sole problem here. On top of my stubbornness is a deeper problem: It is hard to know whether or not certain misgivings are only held by the few or held by the many. I'm painfully aware that comments are hard to come by in the amateur development community and this makes judging a general consensus a difficult task, so I'm making this blog-post in the faint (and perhaps vain) hope that people might give me a list of their problems regarding the Sore Losers: Riot Grrrl demo, however small they may be.

What will I do in return? I'll try my best to address, in some detail, what I think of those suggestions and why I think they are/are not worthwhile and - in doing so - I hope to eradicate some of the fear that comes with nearing the completion of this game. Also, I hope that it'll help people decide whether or not they want to play this game, since they'll get a better idea of what my vision is by me doing this.
 

Wednesday, July 13, 2011

News: New Look And New Feature

Hey guys, just a quick update to be perfectly honest.

First the obvious news, that I've changed the layout of the blog. I think that the previous design was far too busy and that this made it hard to concentrate on the information contained within the posts, so I've made things a lot simpler and a lot cleaner. I hope it is to everyone's liking. Please note, the background is probably going to be changed to something less generic in the future, so consider it a place-holder for the time being!

Secondly, and probably more importantly, I'm going to be doing a new feature: Project Of The Week. Each Monday (or as close as I can get) I'm going to be updating the blog with a new project that I believe everyone should take a look at. These games might be games I've reviewed before, in which case I will link to my reviews, or they might be games that have simply caught my eye. In any case, I hope I can use this new feature to show you why I love the amateur development scene so much!

So, to summarise: New design, a new feature coming soon, things are going to start being more active around here!