Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

About this blog

Virtually unlimited technological advancement in a socioeconomic system... and screenshots.

Entries in this blog


Tech Arena Returns!

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!

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

[size="2"]A) [color="#696969"]Design application with the user's needs in mind but also with a long feature list that is "successfulwebsite.com-like".[/color]
[size="2"]B) [color="#696969"]Throw a bunch of programmers at it.[/color]
[size="2"]C) [color="#696969"]Launch.[/color]
[size="2"]D) [color="#696969"]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.[/color]
[size="2"]E) [color="#696969"]Code is inflexible and typically sloppy so changes require a lot of band-aids.[/color]
[size="2"]F) [color="#696969"]Adding more features and, as a result, adding more problems.[/color]
[size="2"]G) [color="#696969"]Development (or adding problems) vs. fixing problems evens out. Team's getting frustrated.[/color]
[size="2"]H) [color="#696969"]Your most important asset, knowledge, begins walking out the door. Begin hiring new people.[/color]
[size="2"]I) [color="#696969"]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.[/color]

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!).

A) [color="#696969"]Set up infrastructure for development. Put incentives in place so developers have a reason to stay more then a year.[/color]
B) [color="#696969"]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.[/color]
C)[color="#696969"] Launch.[/color]

D) [color="#696969"]Gauge how users are interacting with the software. Successes? Failures?[/color]

E) [color="#696969"]First round of changes. No problem. Preparations for this were made ahead of time.[/color]

F)[color="#696969"] Add features based on common usage. Keep them simple.[/color]

G)[color="#696969"] Build on existing features, add new ones when necessary. Adapt to your users.[/color]

H) [color="#696969"]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![/color]

I) [color="#696969"]Review code constantly, making improvements where necessary and jump back to step (D). If expanding, jump to step (B). Rinse and repeat.[/color]

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

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!





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.


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

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!


"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.


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?

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....

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?"




Shots of much screeniness

This is the GUI I've been working on for Tech. Everything is based off of a single Class, CGUIObject. Which commands all the basic behavior of the GUI. It's platform independent and Graphics API dependent. I've extended it to other basic GUI objects, such as window, checkbox, number field, text field, button, etc.

In the background is a simple tringle in motion. The GUI and tringle/background color are on seperate threads. The triangle is anti-aliased.





I've been spending entirely too much time lately doing home-improvie type things... and partying. I said to myself, "Self, you should really take a break until the weekend so you can get some programming done." And Self said, "Uhhh, I like gravy." So, it's settled. I'm lighting the candles, warming up the scented oils, putting on that red silk robe and throwin' on some Barry White. The computer and I are gonna have the place to ourselves tonight. [wink]

I've still got code to organize. There's entirely too much test code floating around. Tonight, I'll put everything in it's permanent place and do some tweaks.




WTF happened to my BG color?

Since they change over to the Christmas pattern, my background on my entries went to the background of the page contents. Damn.

Anywho, it's the holidays and there ain't a chance in hell at making progress. The multi-threaded architecture is done. It works just as well as before but now I don't have to be kept up at night with thoughts of the system interrupting user input.

Since I feel so guilty for being a lazy-ass, I'll make myself feel better by bringing a few chuckles:

Top Thirty Chuck Norris Facts




Creepin' along

I made a pretty stupid mistake. I'm pretty new at multi-threading... and it shows. I've divided up my application into separate parts to be threaded: physics, video, even the GUI (see previous entries). However, I put my input code in the main application. WTF? I've gone through all this trouble to keep input and GUI from from experiencing slow-downs but I put the input in the main application. What happens during system slow-downs? Reading the harddrive, for instance? GAH!

So, tonight I created a new thread and placed the input routines within it. I'm using a mediator to communicate with it. It actually helped the asynchronous GUI rendering by making it refresh smoothly. Go me. Anywho, I'm just cleaning up code this week and throwing down some comments like a good programmer should do. More later! (I know, the suspense is excruciating)




Rockin' the multi-threadedness

SUCCESS! My graphics engine is now multi-threaded! This means that the GUI and game rendering run on seperate threads and if the game bogs down (
For now, I'm just cleaning up my multi-threading code and putting all components of the game in their rightful threads. The application is doing nothing but checking for the exit action so that it may kill all threads, clean up whatever's left over and exit to system gracefully.


The new house is still a major (but necessary) distraction. Today, we spent the day doing some patch work so that we can be ready to paint next week. We're also doing a little electrical work. It's an old house and uses aluminum instead of copper. Therefore, I have to prep the contacts (so they don't corrode, arc and burn the place down... kind of important).

Still working on getting us some screenies of the new GUI in action. It's simple but pretty.




I'm psyched! Screenies coming soon =)

The new video and GUI are FINALLY integrated into the game application! WOOHOO!!! I've been adding to and tweaking the framework architecture and I'm pretty happy with the results. My physics and video threads are now running and playing nice with the rest of the app. This is important for one VERY good reason...

I'm trying to implement a feature that I've never seen in a game before. We've all played games that get bogged down, and if it's a mouse driven game, it turns into mouse cursor HELL! Yes, the mouse cursor whips to and fro and your ass is getting handed to you. My idea was to put the GUI and the game rendering in two seperate threads, write to two different surfaces and combine them in the main thread. If one isn't updated, the old surface is drawn. So, if the game is knocked down to 1 FPS, there's no reason for the GUI and mouse to maintain a minimum 16 fps, allowing complete control in the toughest situations. Neat, huh?!

Well, it works! It's still in need of some refinement, but I'll have that done before the weekend is out. Also, this weekend, I'm going to add the screenshot feature so I can post some evidence that I'm actually doing something. ;-)

One more thing... I've finally changed my gay-as-hell icon to a cool shot of me playing guitar on stage. AW YOU READY TO BLOODY RAWK AND ROWL?!?!?! Didn't think so...





Recovering from the weekend

Had a party at the new house this weekend! w00t! Obviously, I didn't get any work done... Sorry, PC! Now that the hangover's passed, I can get back to work. ;-)

Not a whole lot to report. I've got all the parts of my framework complete. Over the next week, I'll be putting everything together which includes incorporating the GUI and building the new console. Interface designs to be posted soon. =)




Feast your eyes on this sexy be-otch!

That's right! You're lookin' at a picture of yours truly. Now, settle down ladies. One at a time.

I found this on my harddrive at work and couldn't resist posting it. We were shooting a commercial for the company I work for and I was asked to be in it. Flattered, I obliged... however, they were very hesitant on giving me a copy of the script until I actually got there. You can probably figure why. =b




Mission Accomplished

WOOHOO!!! The move to the new house is now complete!

I'm still having some work done to the house, buying cheap crap to fill it with and making some modifications here and there. It's a fixer-upper so I've gotta devote some time to it. It'll be worth it when the time comes to sell it. At any rate, now that I'm moved in, I can get back to programming!


I've gotten to the point of development that's most frustrating. I'm putting in a lot of time to build a solid framework so that development of the game will go smoothly later on. My problem is, I haven't begun developing the game. I've only developed the pieces needed to make A game. So, there's no cool screenshots, no conceptual or technical demos, nothing that I can show someone and make them say, "Gee, that's kinda cool".

Instead, I've got a bunch of test apps to stress test various components like the resource manager, memory manager, video, etc. Let's face it. It's boring. What's worse is that I've been explaining to my non-techie girlfriend that I'm working on a game for months and months. Then she looks at what I'm doing and it's nothing but a bunch of numbers and meaningless crap on the screen (I'm sure I'm not the only one here that has trouble explaining what we do to the technically illiterate).

The good news is that the framework is VERY, VERY close to being complete. Next, I plan to begin some conceptual demos to test out ideas for various systems needed for the game. This should, hopefully, yield a little eye-candy. ;-)




Draining the world of it's caffiene supply

As usual, programming 40 hrs per week and scheduling development around a social life is excruciatingly slow. However, I've made SOME progress. The graphics component is complete minus a few optimizations. This means that I can FINALLY integrate the GUI into the application framework and I can FINALLY build the nifty new console. Since the whole app is controlled through commands, the console will allow easier development and testing. That'll pretty much complete the framework of the game.


Tonight, my girlfriend and I are chillin' with my friend and his new woman (he wanted to introduce her... awwww), so my time coding tonight is gonna be a bit limited. Since we'll be drinking margeritas, I'm sure I'll be unfit for coding tomorrow too. Luckily, I've reduced the rest of my work week to simple, repetitive tasks so I can just zone/nap at my workstation if I have to. ;-)

The new house is demanding more of my attention so dev time is getting limited. =( I'll be running a few graphical concepts as soon as I can get to it.




Progress temporarily hindered by real estate

It's been quite a while since my last entry. I've just recently bought my first house (WOOHOO!) and having some work done to it before I move in. Although this has slowed down my progress, it hasn't stopped it. I've still been hard at work on the game.

Last I left off, I was trying to call all lower-level functions in the framework through an action processor. I managed to get this to work some time ago and even created actions for thread control. So far, the framework is looking good. Now, I'm just trying to tie everything together. I've been updating my video component to work better with the GUI which now renders the GUI on it's own surface. Multiple surfaces are rendered in seperate threads so that the screen can be redrawn whether or not both are complete. This will help during hectic parts of the game where the action is high and the frame rate is low. The GUI will still refresh even when the framerate of the game screen drops.

Once I've got the GUI and the new video component integrated into the system, I would like to work up some concept demos. I'm going for a simple but clean look but have nothing to show for it yet. After all, some screenies would be nice!




Ahhh, the frustration of bein' a programmer

Ya know those times when you just can't get something to work and you just don't know why? Yeah, this is one of those times.

I'm almost done with the framework for my application. Everything that happens on the kernel level is executed though "actions". What's cool is that I have a console (which has been rewritten) and anything that you enter into the console gets translated into an action by the kernel. This works but I'm trying to add all DirectX initializations as system actions. I've extended the CAction class to a CActionInitVideo class. This new class is set up with everything that it needs to initialize the video. However, I send the action request to the kernel and... poop. I'm back out to windows with an error telling me that I've failed miserably.

Now, do I NEED this feature? Of course not. I can just have the kernel initialize the video directly (and all other DirectX objects) but that's just not cool. I want all commands to the kernel to happen via the console... and directed to the action processor. Then, I want a config file (text) that contains all of my action commands to the console which the system can execute during initialization. Any parameters can then be in the config file. If I do this, I'll have the killer framework that I had envisioned.

I'm using adaptor classes to interface with all of these objects. Perhaps I screwed the couch when I was writing the adaptor class? The adaptors hold a static pointer to the object that they are interfacing so all instantiations are acting on the same object. Therefore, there shouldn't be a prob.

Anyway, it's 3:30am and I have work in the morning. I'm off to bed with my tail between my legs. =/




Wake me up when we're done.

I had a whole night of programming ahead of me. I had just got off of work, My girlfriend had to work a late night and, buh gawd, I was streamin' with ideas. First I had to spend a little time on a friend's project which he's payin' me for and then I was home free. Nice quiet apartment, no distractions. Perfect night for a coder like myself. You know what I'm talkin' about.

Of course, to further seperate myself from the world, I had my headphones on, listening to a plethora of rock music at random. Thanks, Winamp.

I was finished with my friend's project so I shut off the music and checked my phone. Three missed calls. All three were from a buddy of mine that is/was about to go through a divorce. I knew what this would be about. I retired my computer for the night and made the call. Sometimes you have to put friends before code.


Anyway, I was hefting major household appliances and my friends personal belongings until the wee hours of the night. No coding was done. Since my last entry, I did manage to integrate a few components into my application. They aren't quite talking with eachother yet, but they'll get comfortable with eachother before too long.

One last note, please say a prayer for the shuttle astronauts. They might be playing it off but I'm finding myself a little worried about the minor damage to the hull (at 15,000mph, there's no such thing as minor).

- Jay




Stayin' home on a Satuday night

My girlfriend's bartending for a wedding tonight so I'm stayin' home and cleanig up some old code that I need to use on my project. Not much to report, really. I've just worked on the structure of my main application and, so far, so good. I also cleaned up the "action processor" that I'm using to handle actions that need to be executed in my main thread. Since it's a precursor to a virtual machine I'd like to implement later on, it's important that it's squeaky clean. =)


On a personal note, I'm having trouble convincing people of the size of the monster that lives with me so I thought I'd use my web space to temporarily post a pic. He's a black Maine Coon cat. The table that he's standing on is about 3 1/2 ft. in diameter. I don't know if you guys have ever seen a Maine Coon but they're enormous. Everyone, I'm pleased to introduce Lucky:

I came to a realization. When dealing with factory methods, there's a way to insure that the factory method of you child calsses are implemented.

I have a CAction class with a factory method. I use a CActionProcessor object that registers, maps and executes CAction objects. CAction is an abstract class and requires that the Factory method is implemented. Instead of using a stub in the parent class, the parent class simply returns NULL. This works well where you want to use the CAction class for a different solution but still want a default Factory method to get it to compile. So if I say

CAction * Factory () = 0;

in the header file, I can't compile without implenting the method. On the other hand, I can impliment it as such:

CAction *CAction::Factory () {
return NULL;

Now I can instantiate the class without worrying about the Factory method but my CActionProcessor class will ignore anything that returns NULL. In some applications, this could be a little messier and the previous stub would be a better fit. I just kinda dig this option because it allows a bit more flexibility.




Let the game(s) begin!

I've been meaning to start this journal for quite some time. I've finally got my GDNet+ account (WOOHOO!) and quite a bit of "usable" code written over the past couple of months.

I've played around with writing games before but I always run into the same problems... weak memory management, lack of a decent GUI, flat physics model, the list goes on. Any past attempts have pretty much been a hodge-podge of code and have resulted in inflexible applications, giving me no room to do what I want to do (or to even finish for that matter).

To remedy this, I'm writing a flexible (but somewhat simple) game engine. Keep in mind, I write code for a living 8 hours a day so the game is coming along slowly for now. I have a series of games in mind that I plan on implementing with this engine, each more complex than the previous but based on the same concept.

Here's how I've come along so far:

- Memory management: Easy-to-use components that deal out objects and destroy objects upon request. Great for use in a builder pattern.

- GUI: A flexible GUI class that can easily be extended into many GUI objects.

- Command processor: Command class is extendable to many command objects that may be queued into a command processor to handle major functions of the application. Good for running commands from a console. Plus, it's a nice little exercise before diving into the light-weight script engine I'll be needing later on.

- Console: Crap. I'm rewriting it using the GUI and command processor above.

- Physics system: Pretty robust but badly designed and, worst of all, 2D. It manages objects within "spaces", allowing collision detection on about 12,000 moving objects simultaneously @ 50 fps on a P4 1.5GHz. Not bad, just needs a rewrite.

- All the basics such as DirectInput, system timer, File I/O (w/ serialization), etc.

- Other tidbits: Parser, AI, good targeting and leading with some of the worst path-finding ever, etc.

Currently, I'm building a multi-threaded application using most of the above and plan on starting the first game of the series ASAP. I think about how much I've written so far and I feel like I'm almost over the finish like. Then, I think about how much further I have to go. Ugh!



Sign in to follow this  
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!