Jump to content

  • Log In with Google      Sign In   
  • Create Account


Platinum314

Member Since 07 Jul 2003
Offline Last Active Oct 23 2013 06:21 PM
-----

Topics I've Started

Mouse Look + Drag and Drop UI

07 August 2012 - 03:36 PM

Some of my favorite games of all time are Ultima Underworld I and II. I liked lot's of things about these games, one of which is how nearly everything was interactive, items can be picked up and dragged into your inventory, you can drag items out of your inventory and drop them in the world. Items can be used on other items by dragging them on top of another. I liked creating treasure rooms where I could arrange my stuff however I liked. Some games since have attempted the same thing, in particular the System Shock and Elder Scrolls Series of games, of which I am also a fan.

However it seems that now days the mouse is reserved for which direction the the character camera faces. Back in the old days of UUW there wasn't much reason to have so much control over the looking (although they did let you use the keys 1,2, and 3 for looking up, looking ahead, and looking down).

I have seen only a few modern games that have attempted to combine the mouse look and the drag and drop inventory. Arc Fatalis was in about the same spirit as the underworld games, and you were able to drag and drop items to your inventory at the bottom of the screen. However you needed to press a key to 'switch' between two modes where the mouse looked around, or was used as your hand and interacting with the environment. The same attempt was used in an indie game called Delver that I found on the web (It is supposed to be a combination of a rogue-like with an Ultima Underworld style exploration game).

I am wondering if anyone has seen any system that has managed to seemlessly combine the ability to mouse look with the ability to drag and drop items or other things in the environment. Something I found interesting was a mechanic shown to me from my brother in a game he loves called Red Orchestra 2. It looked like the weapon you weilded didn't automatically aim at the center of the screen, instead moving the mouse also moved how the character was aiming the weapon, yet mouse look was also on at the same time.

In one of the game designs I've been working on my ideal control mechanism would allow mouse look, the ability to aim weapons without changing the camera, and the ability to drag and drop items, all at the same time without a changing of state. I am however stumped. I've been toying with a prototype in unity where the camera rotates when the cursor approaches the edges of the screen (Similar to how Wii shooters work), but I have always gotten complaints that it feels unresponsive and slow from those that have tested it. I think the mouse look is just the mechanic that is expected to be in all first person games today.

Planetary Scale Levels

02 July 2012 - 09:34 AM

For a fun discussion I thought that I would pose something that has been bothering me in one of my game designs that I plan on seriously making a prototype of soon. I'm curious if anyone else has faced this problem or just has any creative ideas to solve it.

In a single player exploration sandbox style game that is trying to be at least semi-realistic, is it possible to have a game world that includes several planet sized environments? This is a major toughy from both a game design and programming point of view.

I feel that if I have multiple planets, and give the player the ability to travel between them, that there isn't any justification for limiting how much they can explore. What's stopping the player from landing their spacecraft whereever on the planet they want? I can't store thousands of square miles (kilometers) of persistant geometry, let alone making it all interesting. If the player want's to go on a long hike in some arbitrary direction what do I do?

I'm tempted to rewrite the story of one of my games I've been working on so that it takes place in a series of smaller regions on one planet, Climate and the sort of local flora and fauna can be different on the same planet but then I have a hard time explaning how different locations can have different gravity and atmospheric types. For this particular game design I hate the idea of invisible walls or impassible mountains.

The idea of procedurally generating locations that you visit is a possible way to approach the problem. Daggerfall and Minecraft come to mind. This would make it so that you aren't restricted in where you can go and that no matter where you go that there will be something there. A sense of scale would be met. It would also guarentee a large amount of replayability. If I want any special locations for story purposes I can place them within this world. Such an approach though may lend itself to having the player lost, not knowing what to do, or overwhelmed.

Perhaps I am just overthinking this and gamers just expect that they don't have this sort of freedom in a game world.

Too tired to code

11 February 2012 - 09:52 PM

I'm currently working towards my PhD in Mathematics. So I have classes that I am taking, classes that I am teaching, tutoring and grading responsiblities, and reading texts on functional analysis on which I give presentations to my mentor. I'm absolutely loving it so far.

I just went to a seminar on how Grad Students in Mathematics need some sort of personal grand project that is enjoyable, but that also practices analytical skills. I thought that working on one of my big computer game ideas would fit.

However I am finding that I tend to get worn out. Previously I would relax by programming some hobby game projects. Problem is now I just can't get myself to code anything, I feel like my brain is too worn out to work on anything.

I had worked in the professional video game industry for the period of time before going back to school. I've decided that it probably not for me, as it seemed to suck up all my time and leave me hating the game development process.

I've put a little bit more work into some of my recent projects in C#/XNA, and Unity (I haven't used C++ much for my own projects for a while, too much debugging). However I always run into UI programming, which after all of my schoolwork just isn't appealing at all. This tends to lead to me just adding new pieces to my project in a scattered fashion to random components that can't even be tested properly until later.

Should I try to team up with other like minded people over the internet who can help pick up the slack when I am exhausted? Should I find a framework or engine that takes care of everything I don't want to personally mess with?

Massive number of interacting objects

24 September 2010 - 05:55 AM

Now that I'm coming out of crunch time at my job at EA, I have time to work on my own projects. Naturally I started to work on one of my more ambitious projects.

I've been working on a game where I'm running many objects each cycle. Clearly having each object check versus every other object for collision detection is out of the question. So I set up a system where each thing checks against things that are nearby.

Each tile contains a list of all of the things on it. Things know what tile they are on. When a thing moves and ends up on a different tile it transfers itself from the old tile to the new tile. When a solid object attempts to move it checks for collision with the solid objects in the lists of the tile it's on and the 8 neighboring tiles.

I also set up a cool system where new things can be created and destroyed dynamically in a relatively fast fashion. Things can create other things and so on.

Everything was working nicely so far. I had over 10,000 solid objects bouncing off of each other at a decent frame rate.

The problems started to happen once I made non-solid objects capable of interacting with solid objects. Now it grinds to a halt because I have areas where I have hundreds of non-solid objects each checking against other solid and non-solid objects in the same tile.

I've thought of making multiple lists per tile, one for solid objects, other lists for different types of non-solid objects. However this would drastically complicate other things.

Just to see what happens I put in limits to objects per tile. It wasn't good.

Is there anything left that I could try?

Distinguishing melee weapons?

14 June 2010 - 08:40 AM

I've been working on a game design for quite I while, including 3 or so prototypes. I've decided to go back to the actual design and remove things that are getting in the way.

The main premise behind my game is that you are a spellcaster that compiles their own spells in order to solve puzzles, combined with a roguelike adventuring.

The spells in the game are much like equations or programs, and are thus quite predictable.

I've decided that I need at least some kind of simple combat system. I want this combat system to not have any randomization involved in order to fit with the feel of the game. I've settled on a simple damage vs resistance system. Spells can alter these attributes.

I've thought of having weapons such as daggers, swords, and axes. They have an amount of damage they deal, how fast they are, and what magical spells they are enchanted with. If I decide to have weapons in the game I have the following problem. Other than the damage and speed of a weapon, what can I use to distingush one weapon from another without dramatically increasing the complexity of my system?

I've decided against having separate physical damage types such as piercing vs bashing and such. For a while I was experimenting with extra attributes like accuracy modifiers and such, but this made it no longer easy to calculate damage.

Any ideas?

PARTNERS