Archive for the ‘direction’ tag
For various reasons, I’ve spent some time away from LxEngine coding over the last several weeks. I’ve decided to intentionally use this time away from the code to attempt to distinguish the forest from the trees and ramble about where LxEngine should be headed…
Script + Engine Driven
I believe I’d like to modify lxengine.lib into lxengine.exe. Instead of a library to build applications on, it should be an executable that is driven by a configuration file, scripts, and native plug-ins. A new app should be writable without any native C++ code. This mindset fits better with the original goals of rapid development as a priority. I’ve envisioning a manifest file suppling a list of shared and custom plug-ins (which are in turn a series of configuration files, scripts files, DLLs, and resource files) and a “main” script file to control execution. This seems like a better architecture for my goals.
Smaller Core, More Plug-ins
Physics, Sound, and many other utilities should be separate dynamically loaded DLLs. Lots of small DLLs is less efficient at runtime, but again – the goal of the project is easy, intuitive development rather than bleeding-edge performance. I need to constantly remind myself of this. I need to break out the non-core services into a set of plug-ins per the architecture described above.
More but Smaller Samples
With a “no native code required” engine setup, I’d like to throw together a lot more minimalist examples. This fits better for testing purposes – not to mention it fits better with my erratic coding schedule.
The first-class concepts I’d like to include are:
States both in the form of sequences (context-dependent behaviors) and stacks (inherited and overridden behaviors). Concurrency, i.e. in the form of good threading support. Task support in the form of elegant coding mechanisms for large sets of small functional units. Coroutines, i.e. interruptible and resumable functions for spreading behaviors over a non-sequential time-period (useful for animation and AI scripts). Events – i.e. the engine should be almost entirely event-driven rather than sequential to better fit with the concurrency model.
I’d follow the same “manifest file” approach with individual resources. A model, texture, script, etc. _cannot_ be loaded unless it provides a manifest file with licensing and other use / authorship metadata. I’d like to have part of the engine itself be a service to enumerate the proper credits and licensing information for any set of resources. Sure, this would be trivial to circumvent, but that’s not the goal; the goal is to make it easy for those developers who want to use open resources to automatically properly credit them.
Still a Development Platform
I still want LxEngine to be both an engine itself as well as a easy to use development environment / platform. Even if Bullet (for example) is no longer linked into the core engine, I want to retain LxEngine’s current scripts for pulling down the source release and building Bullet locally as part of the environment. I still want to support the use case where the third-party “auto-build” and configuration can still be used even if the lxengine core code itself is not used. Build and configuration is too much of a hassle on Windows. It shouldn’t be.
NaCL and the Web
Nothing technically astounding to report: only some regular progress.
I’ve been moving away from OGRE and towards coding my own OpenGL-based renderer. Why? Because I realized that, as much as I want LxEngine to utilize the work of others and avoid reinventing the wheel, this is also currently a hobby project and, bottom-line, I enjoy writing custom graphics code.
That out of the way, I’ve been very interested in terrain lately. Between the Lithosphere demo (see earlier blog entry) and unfortunately downloading and instantly getting a minor addiction to Minecraft, I’m fascinated by what a procedural terrain engine theoretically could do.
Step 1: Height maps. These seem to have a nice balance between simplicity (e.g. path-finding and collision detection) and capacity to display something interesting. Here’s a heightmap generated from a sin + cos wave with a checker pattern and fake diffuse lighting:
Video was probably overkill for such a simple example, but I thought I’d use this as an excuse to try out CamStudio (a free, open source screen recording app). Pretty simple to use. I recommend it.
A bit more work and some head-scratching to really understand Perlin noise, and the result is this heightmap:
Thanks to these pages for the information on Perlin noise:
- Malcolm Kesson’s page on Improved Perlin noise
- NVidia’s GPU Gems Chapter 5 (authored by Ken Perlin)
- Ken Perlin’s slides on Noise Machine
Perlin Noise And Turbulence by Paul Bourke
Added automatic generation of additional tiles and a cheap GLSL fog effect:
As mentioned in the prior post, I’ve taken a break from the lower-level graphics programming that I’ve been posting about on this blog.
I’ve started a small project creatively called “Adventure”. The vision (which isn’t very well-defined at this point) is to create a small game that is some sort of cross-breed between a linear, story-driven adventure game (e.g. King’s Quest) and a simulation game (e.g. SimCity). What exactly this means will evolve, but overaching theme is to create a “complete” engine that heavily utilizes existing third-party toolkits, is part “sim” and part “story.” I want to take some time away from a single low-level component and spend more time on understanding the big picture – not to mention honing my skills battling the Not Invented Here tendency many developers, my self included, seem to have.
As I mentioned, completeness is a higher priority than anything else. Therefore, I’ve start out simple with version 0.0 being a simple text adventure game. In the current incarnation there are only a half dozen rooms and the player simply needs to figure out the right commands to enter in order to win.
(Needless to say, with a name like “Adventure”, I’ve put creativity in the game concept and story on the back burner as well.)
About the Technology…
While it is a simple, text-based game at this point, I am trying to build a solid base to expand it into a more technically noteworthy game. For example, the build system uses a nested CMake hierarchy. The code is linking against Boost, which opens up a lot of doors for reuse of some solid, useful code. The game data is loaded from Lua files which allow for custom scripted actions in each room.
The Adventure code itself is not much, but the intention is to establish a good base to build upon where code is added, to replaced, as more advanced functionality comes on-line. I intent to spend a significant amount of time building a very clean base so that the architecture evolves fluidly.
The game architecture at this point revolves around three key concepts. They are fairly simple, but the interesting part is that even though they are simple, it’s quickly apparent how these concepts allow for a fairly complex game system to be constructed.
A Cell is a self-contained part of the game world. The player is in one and exactly one Cell at any point during game play. The only way to exit a Cell is via a well-defined connection to another Cell. Any actions that take place by the player are local to that Cell.
These restrictions keep the game space well-defined so that the game simple to code for, stable, and logical. Of course, exceptions to these rules (for example, some actions may affect other Cells) but as a general guideline this works well.
This concept works well for a single text-based game, but it also should works for a graphical game. The cell is basically the current “area” whether that’s a single enclosed room or a large outdoor map. The concept can be expanded upon by making Cells into a heirarchy or expanding the notion of locality of action to chain to neighboring cells to an N-th degree.
The next concept is an Action. An Action is simply the user doing something that causes the game world to react. Quite simple.
In the text-based world, the Action is usually just a command like “get”, “look”, “listen”. It’s a verb that – depending on the verb – may act upon a particular Entity in the Cell or act upon the Cell itself directly.
In a graphical world, the Action may include additional details implicit from where in particular the player is located or looking. However, the basic notion concept of a single discrete Action, with accompanying Entity and some details about the Action, more or less translate equivalently whether it is text or graphics.
An Entity is an object in a Cell that can be receive an Action. This may be a non-playable character, a lamp, a whisp of fog – it’s anything that an Action can be applied to.
State of the Code
The current build has fairly decent starting points defined for Cells and Actions. Next is a good, generic, scriptable Entity concept.
Recently added the ability to dynamically reload the game data while in game. It stores the file modification time of each cell it loads and reloads and newly modified files upon an update command. Given that the system is using reference counted boost::shared_ptr<> objects, this works correctly even if the cell that the player is actively in is reloaded (the old version won’t be discarded until it is no longer referenced).
On a related note, I also updated my perforce server to the latest version (thank you to Perforce for making it so straightforward – server upgrades of personal data always sound like potential for disaster) as part of starting this project.