About this blog
I am developing a space-based RPG that utilises it's own 3D engine.
Entries in this blog
I had hit a bit of a slump with the progress of the engine, mainly due to the initial design showing its flaws. One such problematic system was the resource manager that handles loading and sharing of textures, meshes, etc - it worked, but I wasn't happy with the way it had turned out so I started a new side project to prototype different ways to handles resources. The prototype's design turned out to be quite good, so I implemented a few other systems from the main project into it to see if the new design was actually feasible. It was, and soon enough I'd added all the other systems, and the prototype became v2 of the engine!
I have just brought the new engine up to the same point the old engine had reached, and the design is much clearer this time around. I won't go into the details of the old engine's design, but the new engine basically consists of these objects:
Application - acts as the interface between the engine, the player at this machine, and the OS. This object contains a single Engine instance, which it initialises and sends update commands to. The application contains the 'main game loop', similar to:
Handle events from the OS
Tell the engine to update itself (which in turn will update the world)
Tell the player to render
World Domination sorry, wrong list
Engine - the engine. This will contain a reference to the game world, as well as act as the 'owner' of the various subsystems, e.g. resource management, loading/saving worlds, plus lots more! I haven't fleshed out this object yet. One main point I emphasised when designing the engine was that the Engine object will not know about, or care about, players. I came to this conclusion after thinking about games that support dedicated servers, in that they are perfectly happy to run with no humans connected.
Render Window - represents the window that is rendered to. This also receives and distributes window events from the OS to the renderer, e.g. resized, closed, etc.
Renderer - provides a set of functions for rendering to the screen (more specifically, a Render Window). Note that only the Renderer object 'knows' about the render window - the Player object only interacts with the Renderer object, which delegates to the render window.
Player - the interface between the application and the player. The Player object handles updating input and contains the reference to the renderer. This object will not represent the player entity in the world. Instead, the entity that represents the player in the world will have a reference to the Player that controls it, and will query it for input commands. This kind of breaks the encapsulation of the world, in that the player entity will have to 'reach outside' the world to grab its data from the human controlling it, but I guess this is exactly the point of the player entity being controlled by a human.
World - this is where all the entities in the game world will exist. Each entity will have it's own Think() and DoPhysics() (etc) routines, which will be called by the World object each 'update frame'.
At this early stage, it's hard to tell if everything will work out. I haven't even started on the engine and world code yet! The engine is designed to support multiple renderers, OSes, input mechanisms, etc, but so far I have only implemented the features to work with Windows and DirectX9, so I can only hope that I've abstracted the interfaces enough to support other configs!
Hi! This is my first jornal entry and will do nicely as an intro to my project.
I am developing a space-based RPG along the lines of Eve Online, but single player. I am also developing my own 3D engine for the game. I am using Visual C++ 2003 and DirectX9.
From a game design standpoint, I have nothing more than a loose set of scribbled notes and free-range ideas floating around in my mind. I have a few key goals, such as strong player-NPC interaction (as well as NPC-NPC interaction), complete freedom of movement throughout the universe, strong exploration aspects, plush leather interior, ABS and that new car smell.
Developing the engine will serve to introduce me to the finer, trickier aspects of game programming, such as resource management, low-level maths, engine architecture and code design.
The engine is at an extremely early stage - I am currently working on the in-game object system, e.g. where the objects are, which way they are facing, what mesh they use, etc. No 'game' code has been written yet.
I have no set ETAs, major milestones or other such project-management targets, and am just taking it a day at a time. I tackle problems and developments within the engine as they arise, in which fixing usually leads to other items that need to be worked on, and so on. I look forward to the day where I begin to work less on the engine and more on the game code.
So that's the short of it! I guess I plan to update this journal every week or so, or whenever something major happens to the project. I might even do a bit of ranting here and there.