Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 16 Feb 2013
Offline Last Active Aug 23 2016 01:38 AM

#5113412 The idea of mixing JRPG and Western RPG's into one game?

Posted by on 30 November 2013 - 10:13 PM

Do you mean working backwards so no matter what happens i'd end up with a few ''ending'' possibilities? and by ''converge'' wouldn't that make a dna effect? meaning it'll branch out then come back in then branch out again?


Yes, exactly. By having the events all come to the same few endings it will really make the game come full circle rather than feeling open-ended. And yes, converging events would create that effect.


Another thing which would greatly help the sense of unity is to create several large scale events which occur in the world and are somehow tied to the overarching story line. These large scale events would occur no matter what path you're on, but the path you've chosen will effect how you interact with those events. For example, imagine that at a fixed point in the timeline there's an army which attacks a city. Depending on your current branching path, you may find yourself in a number of positions. Perhaps you're at the front lines of this attacking arming, or maybe you've enlisted in the militia of the city and are defending it. Or maybe you just happen to be strolling through the city at the time of attack. Or perhaps you're in a distant land altogether and you only hear word of the attack. Or maybe you've found a way to prevent the attack before it even happens, such as by helping form a truce of some kind.

#5112368 Moving Content on a Surface that isn't the SDL_SetVideoMode() Surface

Posted by on 27 November 2013 - 12:51 AM

What if I have objects that are past the size of the screen? for example: if I had a rectangle at the x position of 650, but my screen width was only 640


It will not draw it to the screen surface. Bounds checking when drawing to a surface is built into the API. The same goes for an image that is partially off screen - it will automatically clip what doesn't fit.

#5112363 Moving Content on a Surface that isn't the SDL_SetVideoMode() Surface

Posted by on 27 November 2013 - 12:37 AM

You shouldn't need to draw the moving sprites onto the background's surface. Each frame simply clear the screen, draw the background to the screen surface, then draw the moving objects to the screen surface. The images are always drawn on top of one another, so draw them in order of furthest to nearest.

#5112339 Converting dice rolling mechanic into digital games

Posted by on 26 November 2013 - 10:01 PM

You could simulate the dice roll but make it interactive. Allow the player to "shake" and "release" the dice - and not just through a simple button press either. The player should be able to control the amount of shake and how the dice are released. This should make the player feel like he has control over the outcome and thus feel more involved.

#5111748 Implementing better code design for a camera feature in a 2D game

Posted by on 24 November 2013 - 11:15 PM

The camera should have its own coordinates. These coordinates will determine where the screen is currently positioned in the game area. When you render an object on screen, you do so in relation to the camera's coordinates. Just subtract the camera's coordinates from the object's coordinates to determine where it should be drawn on screen.


In other words, the object's render function needs to know about the camera. The camera doesn't need to know about each object.

#5111228 Why do 2D games have main character locked in the middle of the screen

Posted by on 22 November 2013 - 01:03 AM

In many 2D platformers such as Super Mario Bros., the camera is actually locked to a predefined vertical height and will only move horizontally with the player, keeping him roughly in the centre of the screen only on the X-axis. In this setup, the main character is not necessarily in the middle of the screen. The camera does not move up with the player as he jumps or even when he moves to higher platforms. It's even possible to jump above the top of the screen so the character is no longer in view. The basic principle behind this method is that the camera should move as little as possible and only when it needs to. Jumping is a quick motion and would cause the screen to be very jerky if it were locked to the player's position. Many later platformers such as Super Mario Bros. 3 used a hybrid system in which the camera would lock to varying vertical heights defined throughout a level but could enter a "free mode" if the player happened to move too far in one direction up or down or where in places there is no defined vertical height to lock to. In this "free mode" the camera more or less keeps the player in the centre of the screen.

#5110023 Design concept

Posted by on 17 November 2013 - 04:35 PM

Incoming focus brings camera attention to any incoming threats. Threats are defined as offensive attacks from outside of the camp or internal areas of concern such as disease or fire outbreak. Task is accomplished by pressing the I button.


Perhaps this could be done a bit differently. When an incoming threat occurs, a small second display (think picture in picture) could appear somewhere unobtrusive on the HUD, such as in a corner. This display would show what is happening in the area of the threat. The "I" key could still be used to make the main camera jump to this area.

#5106713 Improving vocabulary in game design

Posted by on 03 November 2013 - 11:30 AM

This is a very good question, but unfortunately I don't think there is a good answer to this. The study of game design is something relatively new, and because of this many of the terms used are non-standardized. There are online resources such as the video game section of TV Tropes which has a vast, community-built list of such terms, but this is obviously non-standardized. You also have resources such as Extra Credits which go into much detail about certain terms, but again it's not standardized. Even within school courses on game design I'm sure you'll find terminology varies greatly between different schools.


With that being said, far more important than knowing the terminology is understanding the meaning behind each term. It isn't enough to read a list of terms, you need to be able to identify them as you are analyzing a game.

#5103593 Incredibly niche games?

Posted by on 22 October 2013 - 11:47 PM

So what if I had a game where the game is absolutely nothing but turn-based RPG battles, one after another, and long ones too?


The key to making this work is variety - not necessarily content wise, but in moment to moment conflicts. Do not just have long battles, have lots of short ones too. Vary the number of monsters you fight against - have some battles with a couple strong enemies and other battles with several weaker enemies. Make each battle feel different than the last. Perhaps the player must handle each battle differently depending on the enemies present, the environment you're in, or the characters you currently have at your disposal. That's another huge opportunity for variety - having the player control a rotating set of characters from battle to battle. Each character should have a unique fighting style (like in FFVI) which forces the player to handle each one differently.

#5101963 Gods in a fantasy game

Posted by on 16 October 2013 - 03:56 PM

I am split between two ways I can present them, one of the ways is that they will be manifestations of concepts from inteligent creatures, and the other way is that they are assended from ordinary creatures who did extraordinary deeds.


Why can't you have both? I see no reason why having one path to godhood would exclude another.

#5101217 Final Fantasy VI game - chronological order of building & being challenge...

Posted by on 14 October 2013 - 01:55 AM

I believe you should start with figuring out the game mechanics - first on paper, then with prototyping. You should figure out how you want to handle equipment stats, levelling up, spells, damage calculations, etc. Even more importantly, you need to figure out how you want to handle combat itself. Do you want to use the ATB system just like in FFVI, or do you want to take your own twist on it?


Next, you should think of what kind of story you want to tell. Most likely a large scale epic, but you will also need to think of the themes you want to explore. Afterwards you should figure out the overall progression of the game, in terms of story development, area exploration, and character development. Map out all of the important events first and fill in the smaller details later. Since combat is central to these kinds of games, remember to weave important battles into the story development.


You begin programming as soon as you start prototyping the game mechanics, and you continue to program throughout. Work out all of your ideas about the game mechanics, story, and characters on paper first - in fact, get a sketchbook going. I would advise against progressing the content in the code until you're fairly certain of your decisions. Art, sound, and music should come last. In the meantime you can use placeholders for all of those things.

#5101212 Dissecting Final Fantasy and Final Fantasy VI

Posted by on 14 October 2013 - 01:23 AM

Since Final Fantasy VI is one of my favourite games, I'll address the second question. I believe the most important aspects of FFVI is the character development, story development as well as scale, and the setting. Throughout the game, you are introduced to a lot of interesting characters with backgrounds that you slowly get to know. This works especially well since you rotate control of the characters throughout the game. This makes it so no character feels like the main character, and that each are equally important. There are characters that at first you don't think much of when you first meet them, but through clever character development you begin to feel a bond with each one (e.g. when Setzer's character develops when he tells the story of his ventures with Daryl). As for overall story development, it starts out in a small local area and slowly becomes larger in scope, until it eventually concerns the fate of the whole world. The setting of the world makes it a place you want to learn more about. It mixes high-fantasy with steampunk elements - swords, magic, and technology.


However, I feel that the game mechanics themselves weren't FFVI's strong point. The ATB system wasn't particularly engaging, and neither was the system for learning magic spells. Equipment and damage calculations were fairly standard for the genre, and the way combat was handled didn't differ much from many other RPGs either.




I recommend looking into this eight page article which dissects FFVI in great detail.

#5100066 Wasting potential, and seeking cloning

Posted by on 09 October 2013 - 09:33 PM

Perhaps you need to spend more time thinking of what you want to achieve with your game. Sure, you can clone an existing game (as many developers often do) but there must be something new you want to bring to the table. Perhaps it's an interesting game mechanic (in the case of the FFVI clone, maybe it could be a unique battle system in the way it handles damage, equipment and character stats, and/or spells). Or maybe you have an epic story you want to tell through the game. Or possibly you want to explore an interesting visual style that appeals to you. Or perhaps you just want to create an immersive experience for the player to get lost in. In any case, before you commit to an idea you should first explore that idea in depth to see where you can take it. Think about it for a few weeks, jot down notes, sketch some drawings, and really try to develop your idea before you even begin prototyping it. Afterwards you'll have a clearer idea of whether or not your game idea has potential.

#5099466 Thoughts on implementing four damage types in an action-strategy game

Posted by on 07 October 2013 - 10:19 PM

I don't see much difference between this and what RPGs have been doing for decades with things like elemental damage and resistances. With that in mind, the success of this system really depends on how it is implemented. You will need to take even more care in balancing out the different damage types with units' armour capabilities as this system introduces greater opportunities for game breaking strategies to go undetected in initial play testing.

#5097540 SDL tutorials

Posted by on 28 September 2013 - 09:13 PM

You can check out Tim's tutorials at http://www.sdltutorials.com/, however, this site is a bit outdated as the tutorials are based off SDL 1.2.

Be sure to check out the documentation for SDL as well: http://wiki.libsdl.org/FrontPage


You're going to want to look here: lazyfoo.net/SDL_tutorials/

It's been a long time since I used this website or SDL so Im not sure if it's up to date or not


Lazyfoo is in the middle of adding tutorials for SDL 2.0.