Tech lives!

posted in Tech: Arena
Published July 03, 2009
Advertisement
THE TECH SERIES

"Virtually unlimited technological advancement in a socioeconomic system."

The Tech Series, as the above quote ambiguously suggests, is an attempt to remove the limits of what can exist within the game environment while at the same time creating a game environment that responds to what exists in it. The scope of the project is a bit ambitious and no where near practical for a one-man team, so, I've broken it up into three seperate games, the first of which, Tech Arena, I'm currently neck-deep in. Each of the three installments of the series is an incremental implementation of this goal.

The first, Tech Arena, tackles the physical and technology building aspects of the series. On the surface, the game is designed to be somewhat casual. The player may simply select a vehicle and immediately jump into an arena which may feature different game types such as combat, racing, base defense, etc. Some configuration of the vehicle is allowed but is limited until a player enters a career game. From here, new vehicle components may be bought, designed, manufactured, used or sold. There really is no limit to how far you can go other than cost. Want a weapon more powerful than anything that currently exists in the game? Knock yourself out! You might want to build up your bank roll first though.


COMPONENT-BASED ARCHITECTURE

Vehicles are an assembly of components, each providing a specific function. Components have connection sockets where they can be attached to other components. Here's an example of a simple vehicle constructed of two engines, four hover drives, a chassis H-frame, cockpit and power core (just a prototype so please excuse the cheesy graphics):



Internally, each of these components is driven by a script that defines the physical object, it's connection sockets where it can be attached to other components and "data" sockets that define how information is communicated to other components. I use the term "data" loosely here since one socket type, energy, may directly or indirectly (within the component heirarchy) connect the component to the vehicle's power core where certain script functions that require energy may request that energy and behave based on what's available.

These connection sockets are usually fixed but may also be axles, hinges, ball joints, sliders and others. Motors may also be applied to joint connections to drive motion. Ever use ODE? Okay, you get the picture. Only difference is that there's much more organization, fixed connections are actually stable and you get to play with it in a game environment rather than writing code. ;-)

Here's a screen showing a slider joint being used as a suspension system on the vehicle's hover drives. This helps maintain a great deal of stability during gameplay:



As components become damaged, their functionality decreases. Once destroyed, they are lost along with their functionality. Here's a severe case example:



Creating new components is made to be as easy as possible. The player may select an existing component type, modify some parameters and play around with the component, real-time, in the "simulator". If they can afford the component, it may then sent to manufacturing. Particularly industrious players may even create new component types with the in-game IDE:



The editor also features debugging and GUI integration, so, it's actually being used to implement some of the game's features as well. Here, I'm editing the GUI editor and you can see the debug panel on the right side that allows debug mode execution, break points, line step, variable output, etc. These features will be available while actually using the component in the simulator environment.

Well, that's enough of what I've been up to during my long GDNet hiatus. There are many other features implemented that I'll probably cover in other entries. Currently, I'm working on a fast and flexible terrain generator (the one used in the prototype was just too weak) featuring noise, displacement/perturbation, voronoi diagrams and other structural features offering a great deal of flexability. Most likely, the game will feature a terrain editor that allows you to play with the game's generators and even create your own. More on that later though.
0 likes 5 comments

Comments

QRebound
=D Great work! I love this concept of extensibility. It's actually very reminiscent of my own current project... I'm taking extensibility to the point where each iteration of our level editor will be a level developed in our level editor. >_> Trust me, I'm still trying to wrap my head around it too haha.

I went back and reread your whole archive, and noticed you don't update very often. Just wanted to post to let you know I'm now an avid follower, if the encouragement helps you to post a bit more often! =)
July 03, 2009 11:05 AM
coderx75
Thanks! The positive feedback is greatly appreciated. =) My subscription has lapsed for some time but I'm paid up for the year. I've got a mountain of things I've been working on (about 2MB of source) so the journal's been long overdue. I'll be updating fairly often and have a few topics lined up:

- Procedural content and extensible terrain/texture generation
- Streaming, ODE-compatible progressive meshes (LOD)
- ODE: continuous physics (using ray casting), stabilizing fixed joints and stabilizing... ODE
- TechOS: App runs under an operating system for the Lua VM. Definitely worth a few journal entries by itself.
July 03, 2009 12:19 PM
QRebound
Awesome! Sounds really exciting, I'll be waiting to hear about it. =)
July 03, 2009 06:07 PM
RAZORUNREAL
Very impressive. I'd been thinking for a while about a game very like this. Oh well, I guess I'll just follow your progress instead. One thing: How do you determine the price of components people code for themselves? Giving people an ide seems like it's asking for trouble in terms of balance.
July 05, 2009 07:10 AM
coderx75
As producer, cost is based on labor, raw materials and operating costs (energy) across four different fields of technology. These costs can be minimized through research beforehand. Some costs of a script can be easily calculated. Weight, integrity, dimensions, connections sockets, data sockets and many others are constants that can be pulled during initialization/reinitialization during the debugging process. Some costs are more complex and require parsing of the actual script. Lua is good for this but all the prototyping done so far only gives a decent starting point while most of the balancing will have to wait until beta.

It is difficult to weed out the exploits and, although planning is important, at some point you just have to do it. I think I have enough control over how the costs are figured but there's a lot more going on in the background requiring a good deal of economic theory. This was one of the main motivating factors behind splitting up the original project and starting off "small". Trying to tackle these exact problems on a larger scale would just be project suicide.
July 06, 2009 04:41 AM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Profile
Author
Advertisement
Advertisement