Showing posts with label game design. Show all posts
Showing posts with label game design. Show all posts

Monday, February 13, 2012

Small Update

So work on the editor is still going strong. Kyle managed to add a bunch of features that make the process a lot easier to handle. There is now a selection tool (think of the marquee tool in Photoshop) that allows you to fill in a specific area.

On the non-programming side, I've managed to start thinking up equations for the game mechanics. I had a few questions on the subject and found a great StackExchange Q&A page dedicated to game development. Turns out I wasn't the first to ask similar questions and managed to find great answers.

That being said I decided to figure out what my main attributes will be. From there I will find derived attributes calculated by the main ones (for example, the strength attribute would modify the physical attack derived attribute). Having these is helping me understand the role for each character and will then help me map out the growth of these stats as they gain experience.

One of the major things I'd like to change from classic jRPGs is try and find a way to remove the randomness of misses. I've always hated the random miss during critical moments. I've always felt that if I avoided running from every battle leading up to a boss that I should be able to defeat it without having to go back and grind. If at any given time one of the characters misses arbitrarily and it causes me to lose the battle... well, let's just say that it's infuriating.

I do feel that critical hits and misses are part of the jRPG formula but I'd like to shrink their importance in battle and rather have a situation where a hit might — instead of missing — deal less damage.

Thursday, March 3, 2011

The Silent Protagonist

While writing up the game design document for the game I often think of scenarios I want the party to find themselves in. Often these scenarios involve dialog and I always picture Rohe as being a silent protagonist.

The idea behind this project is to create a RPG I would have loved to play as a kid (definitely aiming for some nostalgia) but I'm wondering if the silence is really necessary. I mean yes, it would really bring me back if Rohe was silent (than again it's not like silent protagonists have gone anywhere) but is it really necessary to make the player feel more connected to the character?

If anything the silent protagonist might make the player feel less like he or she is in control of the situation because other characters are always speaking or making decision for them. If my goal is to make the player feel like he's Rohe (making him a generic boy hero) would they really feel more connected if they never made the decision to go to dungeon X but had Jill bully them into going?

That's why I decided to ask the question on Gamedev. Hopefully someone will come in and answer my question with a clever angle I never considered.

Tuesday, July 8, 2008

Ramblings of a Bored Fool

A friend and I were discussing his data driven architecture he's coding for his game he is programming. He got to the point where he had a working system when he realized that he had no idea as to what to make with it.

The most obvious choice was pong. He kind of grunted at the idea but we started talking about different takes on the game. There are a millions flavours of pong including (but not limited to) plasma pong, pong RPG, all flavours of battle pongs, etc but how were we to make a new pong that is still interesting?

One of the good ideas we had spawned from a joke. I hate kid's TV shows about kids with cards who duel using said cards and take their game very seriously. I'm takling about winning or losing a match is the difference between life or death (it's a freakin' card game!). So hence card game pong was born!

Essentially the game starts as a regular pong match. Every time the ball hits a paddle the player draws a card. The player can hold five cards in his hand. These cards would have effects in the game whenever they are put into play. An example of this would be a ball split card or a temporary paddle extension card.

What's interesting about the ball split card is that it could be used strategically for the owner of the card by using it against himself. Since the player draws a card whenever the ball hits his paddle if he used the split card just before it hits he would have the right to draw three cards (assuming the ball splits into three balls).

I guess the controls would use the arrow keys or wasd to move the paddle and the mouse to choose cards. My only concern is whether the player will have trouble keeping track of the cards he has while the ball is in play. It would be an interesting experiment nonetheless.

So what are other cool ideas?

Tuesday, April 15, 2008

Java and Game Development

It really bothered me that a lot of people couldn't run NSR. I knew XNA was exclusive to Windows which I thought was fair enough thinking most people would have access to a copy (or use an emulator). However even if we ignore the non-windows demographic so many didn't have a video card that supported shaders 1.1, what a bummer.

Well while I wait for the end of the exam period and for Zedix and I to have time to fully commit ourselves to our new project I decided to explore java game development. I decided to install Eclipse and use java's own java2d stuff. From what I read it's not the best for game programming, especially when there are APIs dedicated to graphics like JOGL or GTGE, but for what time I have to invest in this project I think it will be just fine.

As far as design goes I figured that I didn't want to divert too far from the way XNA works. Now I know I can't develop something as fancy as XNA (ooh-la-la) but I could design a simple architecture that would emulate the coding feel of it.

Seeing how the major architectural feature that I use in XNA is the drawable component I made an abstract GameComponent class with the basic update and drawing functions. From there I implemented the MainComponent which would hold a list of all updatable and drawable components and iterate through them in every iteration of the game loop.

I'm unexperienced in the whole field of game loops but for how simple my project will be I will simply define a default frame per second (60) and make sure that only one frame can be executed per 1/60 seconds. I'd post some code but nothing in my design is concrete just yet.

Here are a few links that I found useful: