ID:50233
 
Keywords: design
Various aspects in my life suggest that it's time for another big push in BYOND development. However, one must first reconsider the old before moving on to the new.

"Project Xenoverse" idea taken back to the drawing board

What I made was an extensive, if rather experimental, tile-based environment. Upon the foundation BYOND provided, I've dropped a good GUI (including a simple mini-game that the player can use to enhance performance) simulated aspects of mass, electricity, and even temperature. I provided the player with a tool that serves to change the game world as they see fit.

This was Project Xenoverse. It was a good start, but I've now second thoughts.

Project Xenoverse Beta Shot. Yes, that is Nintendo's R.O.B. there on the right - placeholder icon only.

The central problem I'm encountering is that the conflict seems unsatisfying. The idea was that the players are taking something from the planet - perhaps precious minerals or artifacts - and there's hostile alien life on the planet that would attempt to force the player out. It wasn't good enough because that was pretty much the whole game: collect resources so you could collect more resources. Blah! I've played games like that before, and it gets monotonous quick. There needs to be a meaningful resolution to make a story.

A second problem was that I was having difficulty isolating a good means of player progression. There were no statistics or skills. Instead, players are immediately given a "portable materializer." It was sort of a terraforming Swiss army knife, you can sort of think of this as a Star Trek replicator, but installed on a space suit you're walking around with. The concept of advancement was perhaps a score is kept as to how well you're doing and this grants more functionality the portable materializer.

The trouble with that approach is that it was too elemental. In giving them a single piece of all-in-one equipment, I sacrificed all the additional RPG character that would go instead into having a character possess skills to use unique pieces of equipment. Instead of having a "laser pistol" or a "quadratic fusion bolt cannon" you have a portable materializer that can be set to "dice" and "mince." There was no need for skills in this push-button universe and, while that may be accurate of a futuristic backdrop where machines do all the work, it needlessly dropped a number of useful game pieces.

Where to?

Were these problems unresolvable? Not really. However, I've gone in the wrong direction enough that I think a far better product could be made by starting over again. As I mentioned awhile back, perhaps I aught to stop reinventing the wheel. To these ends, I'm thinking of implementing something closer to a traditional RPG mechanic with an inventory. However, I still plan to innovate on two key factors.

First, I still want to give the players more dynamic influence over the game world. I'm not going to be afraid of the consequences of a dynamic world like so many developers did when early Ultima Online descended into chaos. Instead, I'm going to take responsibility for it as a developer, and that means putting enough detail into it that the PCs are held responsible for their actions.

Second, I want to make sure the game is fun. Despite the fact I made Project Xenoverse sound like one, I'm not going to make a simulation for simulation's sake. I'm developing a game first with virtual worldly aspects second.

So, there's my focus. Now to turn all my skills towards working out every minute detail involved. One strong improvement I plan to make immediately is to make better use of the skin system by swapping out child controls to handle different mechanisms, such as dialogue or inventory, instead of having so much reliance on screen objects.

My Net Dream concept, at the time of this writing, would probably resemble a late-1980s game by the name of Sentinel Wars: Future Magic. However, the project will change a bit between then and now, and it's hard to say what I'll end up with for certain.
collect resources so you could collect more resources.

This was pretty much the mandate of Lode Wars, and it was still a kick ass game. Then again, teams were placed against each other, and team mates were rivals at best. I guess what the creator hated about his own game is what I enjoyed. Although you had to work as a team, backstabbing your team was also a way to win.

--

I have one thing to say about that screenshot though: AHH! VISTA! Foul temptress shall be forced way back into the depths from whence it came! Be gone! *bolts of lightening erupt from body*

--

Aside from that, the rest of your post sounds interesting. But I have a question, how do you intend to create a dynamic BYOND world?

I've never come across a method I could use to easily create and maintain a dynamic world. Then again, I've had a headache every time I've thought about it. I wonder if those two conditions are because of each other <.<
Tiberath wrote:
Aside from that, the rest of your post sounds interesting. But I have a question, how do you intend to create a dynamic BYOND world?

That's a good question. One thing I'd like to figure out myself is a way to dynamically create maps on the fly.

In this particular design, I managed 'dynamic' by giving the players' the capacity to build. In the finished design, they'd be able to build walls, build turrets, build doors, even create robots and send them on patrols.

That was half of the dynamic aspect. The other half was that I'd create a AI process that evaluated the players' presence and would regularly send attackers to undermine the players' work.

Thus, nothing they ever created was permanent, the players had to defend their assets to keep them. But without constant vigilance, the destruction of player-built content was inevitable.

It would be an ever-changing world that eventually became pockmarked with the battle scars of previous engagements.

Is that dynamic enough to suit the meaning of the word? That's probably going to be matter of opinion.
The whole space-suit-with-magical-replicator-while-aliens-try-to-stop- you-collecting-resources thing sounds a lot like Colobot. Colobot extends the idea by having players program robots to do tasks such as destry aliens, collect artifacts etc. It was possible to construct a totally automated resource cycle, from mineral extraction to processing, and to have your combat bots fly back to base, repair and change their batteries (while another robot collects discarded batteries and places them in a recharger). For one mission I did all of these things, and I was pretty unimpressed about being told to pack up and leave at the end of the mission ;-).

In this vein, you could limit your replicator to producing basic buildings for unit construction, research etc. and have the player construct machines, tile-by-tile, in order to extract and process materials.

You could also have players work towards building some sort of monument, and the player who does this in the shortest time period wins, or have a set time in which the player much accrue as many points as possible.
Interesting stuff - this is the first I've heard of Colobot. Sounds like they had the same idea. Looking at their webpage, they even realized it in 3D with an embedded user-accessible programming language for the robots!

I guess I shouldn't be too surprised. What I'm talking about here is really very base-elementalish:

* The suit replicator is basically eliminating all elements of abstraction between the user and interacting with the game world.

* The programmable robots are basically eliminating all elements of abstraction between aspects of life and a computer simulating it.

* The destroying aliens and collecting of artifacts are eliminating all elements of abstraction between a story and activity.

That's what ultimately came back to haunt me about what I was making: It's a fabulous game concept, yes, but there needs to be more narrative meat to it than these base elements. That's where I'm taking it back to the drawing board.