Jump to content

  • Log In with Google      Sign In   
  • Create Account

Tech: Arena



Tech Arena Returns!

Posted by , 15 November 2013 - - - - - - · 488 views

Not so much of a "return" as it's been in development. Things had slowed down during the whole family-building process but have been in full swing for the past few months (as in spare-time full swing).

Tech arena allows players to build vehicles (and pretty much anything they want to) from components and compete against friends, enemies and AI in an arena. These components and their functionality are each defined by scripts. On the front end, the player may create new components from existing types but these types are really templates of Lua scripts. If one so chooses, however, they can use the in-game code editor to write their own components from these templates or from scratch.

I've posted a new video testing out the new rocket launcher component and the physical effects of explosions in general. Fun stuff!




Doin' the .com hump!

Posted by , 14 October 2011 - - - - - - · 244 views

Behold! The life-death-cycle pattern that nearly all startup companies have been following for nearly 20 years:

Posted Image


A) Design application with the user's needs in mind but also with a long feature list that is "successfulwebsite.com-like".

B) Throw a bunch of programmers at it.

C) Launch.

D) As always is the case, you can never really hit the target right out of the gate when it comes to the user's needs. First round of changes.

E) Code is inflexible and typically sloppy so changes require a lot of band-aids.

F) Adding more features and, as a result, adding more problems.

G) Development (or adding problems) vs. fixing problems evens out. Team's getting frustrated.

H) Your most important asset, knowledge, begins walking out the door. Begin hiring new people.

I) Downward spiral of which there is no escape. Some projects may be well-funded. So, the possibility of tearing it down and doing it right exists in this case. However, they will almost always choose to throw money at the old codebase, as that is (of course) the cheaper solution. Spiral downwards in slow motion.

Nothing is more powerful than an idea whose time has come. Victor's right. I've spent the past several years learning whatever I could about producing successful technology. Software architecture, team infrastructure, communications, methodologies, any knowledge that can help me be a better programmer and be able to handle creation of a lasting product. However, after putting in this enormous time investment, I'm only coming away frustrated because the idea (investing in technology) has not caught on. I'm holding the holy grail and ready to lead my employers to a better tomorrow. My employers, on the other hand, are doing the .com hump.

Why has this pattern not been identified and anyone following this pattern not given 40 lashes and stoned to death? Why are non-technical people still brazenly leading their companies down this same path? Hubrous, of course. Still, it's the same pattern over and over. How is it not obvious? Recently, a project that I'm working on was about to be steered off a cliff and I stepped up with my experience to save the day. Rather than heed my advice, I was told that they deal in results, not theory. Since then, I've laid out a strict overtime payment structure.


The Solution

So, enough ranting about the stupidity that I'm sure many of us have witnessed first hand. I'll propose a solution. Given the biz-people's love for anything "successfulwebsite.com-like", we'll call it "The Google Model" (it doesn't matter if it's technically accurate, these are business people we're talking about!).

Posted Image


A) Set up infrastructure for development. Put incentives in place so developers have a reason to stay more then a year.
B) Stick to your core competency and invest in it heavily. No added features!!! In other words, keep it small, make it flexible and manageable. Also, don't be afraid to put some usage metrics in place.
C) Launch.

D) Gauge how users are interacting with the software. Successes? Failures?

E) First round of changes. No problem. Preparations for this were made ahead of time.

F) Add features based on common usage. Keep them simple.

G) Build on existing features, add new ones when necessary. Adapt to your users.

H) Development team begins building up steam having worked on the same project and with eachother for some time. I can not stress the importence of employee retention enough!

I) Review code constantly, making improvements where necessary and jump back to step (D). If expanding, jump to step (B). Rinse and repeat.

Success comes from a strong core concept and not from tons of bells and whistles. More importantly, success is adaptability. Much can be added here (and feel free to) but my point is that the constant repetition of the same mistakes with the expectation of different results is, by definition, insane. I believe the time has come that these mistakes be recognized as such across all applicable fields of interest.


A small bump in the road

Posted by , 11 December 2009 - - - - - - · 209 views

Great news! After two months of job hunting, I managed to find something with good pay and a flexible schedule. I set out to find a job that would not get in the way of the development of Tech Arena and my other personal projects. TA has been on the table now for over 10 years because my work schedule has always made it impossible to do anything with it. So, I'm extremely excited to have this opportunity. The past two years have been spent working on TA but making very little money. Finally, I can breath easy, have money left over to put towards the game and see what has been a life-long dream to completion.

Where da game at?

I left off some time ago promising screenshots and expecting to have a playable alpha build by now. I'm more than two months behind and I have an AJAX web site project I'll need to complete before getting back on the game. However, I'll be using this to build the TA web site and integrating it with the game. So, it's important to the project and will have some screenshot-worthy captures while I'm working on it. I'll be writing up some entries about the AJAX-based system and how I'm planning to integrate it with the game, so stay tuned!


Untitled

Posted by , 24 July 2009 - - - - - - · 232 views

The new terrain generator is still being integrated with the game's resource management system. I was planning on having it ready this week but it's only stable on small scale maps and the generated textures haven't been incorporated into it. This means no screen shots. =( However, it is coming together nicely and the new terrain certainly proved to be worth the extra effort. So, screen shots are postponed until early next week, but, since I'm taking a little break, let's talk saving massive amounts of development time.


Complex Features on a Limited Schedule

I've been planning the Tech series for over 10 years now and as much as I've thought about gameplay, I've also thought about making the project practical for a one-man show (at least in the beginning). Although Tech Arena's features have been boiled-down to a bare minumum, it's still a great deal to accomplish. Component development, trading/economy, managing resources, etc. have all been major problems looming over the project. However, I worked out an easy solution that has greatly simplified the development of the game's more complex features.

After reading "Programming in Lua" by Roberto Ierusalimschy, I realized that the Lua VM, itself, had some powerful, yet elegantly simple, features: easy integration with DLL components, debug support, environments for seperate scripts, metatables which could be used to restrict and grant access to data, garbage collection, weak tables, easily serializing and deserializing persistant data. It's such a simple and powerful virtual machine, that I thought, like other "machines", it should have an operating system written for it... and boom went the dynamite!

Why integrate Lua into an application when you can integrate your application into Lua?


The Solution: TechOS

Using the game's already existing GUI, input system, rendering system and other major components, I set out to write a kernel for the VM that would treat scripts as applications which could be integrated together to drive the game's interfaces and features. The actual game is, itself, a Lua application (although it's mainly for initialization, firing up threads and responding to input). Even vehicle components can be treated as seperate application instances. There are quite a few things to consider.

- Applications must be encapsulated (your cockpit code can not access my targeting system code)
- Must allow some form of multitasking but also allow for strictly single instance apps or even one-off scripts
- Applications must easily integrate with eachother
- Some applications are more restricted (vehicle components can not access OS functions)
- Must be some control over the order in wich things execute
- Apps must easily be able to save state
- Must be extensible (DLLs... Lua already does most of the leg work here)

The OS maintains tables of all currently running scripts. When an application is run, an environment table is created and that table gets an access metatable assigned to it. The access metatable contains read-only references to all functions, objects and tables for that access level. For instance, OS level apps are assigned the global table (_G), giving it full access.

Persistant tables are also maintained by the OS. An application can call Sys.Persist() on a table which then returns the current state of that table (restores if previously called). This is somewhat similar to the Windows Registry except that only that application has access to its data.


Multitasking, Instances, Integration and Priority

These four issues are all handled very simply. First, event-driven multitasking is used rather than actual multithreading. This gives control over order of execution and avoids the nightmare of using multiple VM's across seperate threads.

Applications (and vehicle components) typically have OnCreate(), OnUpdate() and OnDestroy() functions that are called from the OS. "Global" code and data executes when loaded and affects all instances of the app. The three event functions are passed an instance table to hold all instance data which is maintained by the OS. Without these functions, the application is treated as a one-off script and is terminated upon completion. Single instance apps implement OnCreateOnce() instead of OnCreate(). Rather than opening another instance, the OS will focus the currently running instance.

When apps are opened from other apps, they may pass parameters which are received by the OnCreate function. This also allows apps to share tables for integration by passing those tables as parameters.


Extensibility

Some exciting possibilities come to mind now that this system is (mostly) in place. Rather than creating only vehicle components, an industrious user could possibly write applications for the OS and extend the games interface and functionality. Although DLL's currently are loaded as OS level functions only, I plan to allow other access levels to be extended. This leaves the development of the game wide open for community participation. I've even considered backing up DLL's that have name collisions with currently loaded libraries so you have an option, in-game, of which to use. Don't like the graphics engine? Write a new render.dll. It's a crazy idea and would require that all players in a network game run the same DLLs. Still, it would be easy to implement at this point and probably worth a try.


In Conclusion...

All of this took about a month to write and was definitely time well spent. The in-game IDE, which was one of the more daunting items on my task list, was implemented in under two weeks and ended up with many more features than I originally planned. I've been considering releasing TechOS seperate from the game for those interested though it probably won't be worth much until I document the core API.

Well, that's enough insane rambling for one day. Back to being productive! ;-)


Extensible Terrain Generation

Posted by , 06 July 2009 - - - - - - · 639 views

Hope everyone had a great Fourth!

Now that I've fully recovered from the weekend celebrations, I spent the morning wrapping up the terrain generator for Tech Arena. It's a topic that's been discussed in great detail so I won't get into the basics but I am going to cover what I've been doing with the core generator architecture. After revising the terrain generator a few times and realizing it still wasn't near what I wanted, I decided to create a more flexible, modular solution that can be easily modified and extended if and whenever necessary.

Originally, I planned on using simple noise generation while allowing for geometric modifiers to define areas in which certain effects could be applied to the output. This is just miserable. Noise generation only gives you something uninteresting to start off with and geometric modifiers look, well, geometric. I still like the idea of being able to create a geometric "concept" for a map or even being able to generate geometric patterns such as Voronoi Diagrams. Even noise has its place, but just doesn't cut it alone. Here's an example, under the new system, of a diagram being processed into something hopefully useful:



This is a 64x64 height map and what I tend to use for terrain "chunks" that are streamed in as the player moves around the map. There are (currently) three levels of detail that are loaded in, each 8X the resolution of the last. The first defines areas of 4km, 512m for the second and 64m for the third. Chunk edges are expected to match up somewhat but blending is applied to seem together any breaks. So, we can be a little more liberal in what types of filters can be used and not worry (too much) about breaking seems.

Each of these detail levels can use a seperate generator, each containing sets of channels, filters and modifiers. Channels are simply just raw data that filters may read and write to. A filter type is defined with its process (if it generates anything) along with it's source and destination iterators. These are generic iterators that simply define how to find the first element/node pointer and how to get the next element/node pointer. So the channel may be of any data type or data structure. It can even be a result set generated by another module or system. The filter, once instantiated, could then have modifiers added to it that tell it how to combine the source data with the generated data (if any) before writing to the destination. Here's a quick overview of the generator used to create the above images:



First, we start with the diagram. This is a whole other system in itself and is used for precalculating and quickly querying diagrams of arbitrary polygons. Such a system comes in handy for things like AI, rendering and, for what it will be used for here, Voronoi diagrams and terrain editing/generation. When querying an area, the diagram returns a generic iterator which enumerates the contained shapes. This iterator is passed to a "simple" filter which does nothing but read a source and write to a destination. Since enumerated values (as seen on the far left) aren't very interesting, an ElevateByID modifier is applied which gives a value in the range 0.0 to 1.0 based on the current shape enumeration and the coordinates of the point being iterated. A curve modifier (similar to Photoshop curves) is applied to "bubble" out the terrain, giving it a rounded shape. A MultByID modifier generates a list of numbers on initialization (for the number of shapes in the diagram) and multiplies each "site" by each corresponding number. This gives us psuedorandom elevations for each shape. Some wider passageways would be nice, so the entire map is subtracted by 20 and a Floor modifier clamps the values to zero, forming spaces between the geometries as seen in the "Filtered" channel, second from left.

Some noise is generated (midpoint displacement) and multiplied by the desired elevation to be combined with the diagram output. The combine filter may take raw data from a channel and use that as "generated" output which may then be combined (by modifiers, Add in this case) with the source. This is similar to how the displacement filter works as well (only the data being combined is displaced and interpolated).

A second noise filter is used to generate a displacement map which is used twice to displace the map, once diagonally from top-right (Disp Out) and once from top-left (Output). Curve is used again to sharpen the output (really, just makes for a cooler looking heightmap for use in the journal) and finally Clamp is used to keep the values within an easily renderable range (you can see where values fall out of range in the other channels).

There are a number of other modifiers such as Blend, Overlay and BinMultByID which multiplies an enumerated site by a percentage controlled mix of 0's or 1's. This will be used in conjuction with Voronoi diagrams to control the sparsity of sites. Also, since there's some margin of error allowed in the seeming of the maps, I'll be implementing parameter maps that contain ranges of filter and modifier parameters. The parameters for an area are generated and blended with neighboring areas so that maps won't be monotonous over large distances.

I'll be implementing a terrain editor in-game that will allow arrangement of channels, filter and modifiers as well some editing of diagrams. I may also put together some diagram generation routines. I thought it would be cool to have a maze generation algorithm create diagrams which could then be filtered into maze-like systems of mountains. A lot of ideas stem from this and not all seem to add to the overall experience. I will likely release the filter and modifier API so that other programmers can build their own components. TechOS already has an extensions directory where DLLs can be added to the application so it wouldn't require much, if any, extra work.

I'll be spending the rest of the week incorporating this into the app so stay tuned for a screenshots. ;-)


Tech lives!

Posted by , 03 July 2009 - - - - - - · 157 views

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.


Is all the world a stage?

Posted by , 22 May 2007 - - - - - - · 244 views

I blelieve this to be one of my most important entries (and the only in a long overdue time) because it addresses money, quality of life, mental health and gettin' a game done...

To all of you I give you this message.

A job is a job and it can only be no more than that. Someone can take a job from you but they can't take your career. They can't take your abilities. They can't take your track record. They can't take the thousands of hours you've spent since childhood behind a computer honing your skills. They can't take the fact that you are a computer programmer.

I've been doing whatever programming I can get done while in a place that made me miserable. I wasn't even in game development. I was working for a web site and the stress finally got to me. I ended it.

More accurately, I walked. Luckily our Employee handbook clearly states that "walking" is considered a resignation and not a firing offence. Therefore, I still hold my track record of never being fired. Still, I walked.

My message here is that if you're in a situation where you're loved ones are telling you that you're a miserable shit and need to leave your job to be happier, don't hesitate. Just update and polish that resume and do it way before you have to come to the conclusion that I've come to.

I've got the money to back myself up and (while not working on getting a new job) I'm building a game. I'm finally building Tech.


Another note....

Posted by , 29 December 2005 - - - - - - · 275 views

Put a song together and placed it in the anouncements forum

New song

As was said in the thread:
"I've just finished putting a new song together. I'm thinking that I need something in the middle of the song so it's still somewhat of a work in progress. I'm thinking that I could put something extra in the middle of the song but I'm not sure what. Extra guitar effects? Spoken poetry? Gotta lot of ideas and have the resources, just not sure what to put there. What do you think?"






Recent Entries

Recent Comments

Twitter



PARTNERS