Red Nebula
Christmas was nice. I finally got a new monitor (Samsung 2232BW) to replace my old CRT with a horrible picture, so that was good. Actually I didn't get it yet because I'm still at my parents', so I'll have to wait until next week when I get back to my place. This is relevant for game development because until then, I'm stuck with writing code on my laptop, which tends to go much slower than on my desktop computer. On the other hand, I've been reading a lot on various subjects, so that counts as progress too even if there aren't much concrete results. 
I also bought Fundamentals of Game Design by Ernest Adams and Andrew Rollings for myself, and so far it looks good. Inspired by the book, I finally wrote a very rough concept for Red Nebula and its first milestone:
Red Nebula is a sci-fi strategy game of the 4X (eXplore, eXpand, eXploit and eXterminate) genre.
Notable features include:
- A procedurally generated, dynamic world
- Emphasis on exploration, as I feel it's an aspect of the genre that's been seriously neglected
- Try to avoid some ugly cliches of the genre, such as "Star Trek" aliens and implausible combat
Milestone 1 implements the procedurally generated world in some degree. Main gameplay content are various scenarios, such as "eight colonization fleets were sent from Earth to an unexplored star cluster, let each player control one fleet". These scenarios can vary in scale, and contain static elements in addition to the procedurally generated world. The milestone concentrates on playing as humans; no sentient alien species will be included. The exact scale and scope of this milestone haven't been decided yet, though most likely it will be on fleet level rather than individual ship level.
Now, Milestone 1 is really a full game in itself, so there will definitely be sub-milestones. After Milestone 1 is complete (or abandoned 
), I will review the situation and decide if I want to continue with expanding the concept or doing something else altogether.
For now, I'm still working on getting rendering working again. I fully switched from Pygame to Pyglet as my main "platform" library, and I'm glad I did, since it's much easier to work with. Basic resource management also works again, and now I'm working on scene management and the OpenGL rendering plugin simultaneously. As soon as I get some really basic rendering working, I'm going to start working on the game, and let that fully drive development on the engine side.
Still another path…
I know, I know. I was going to continue working on resource management or the renderer plugin, but then I got seduced by Pyglet. I wrote a Pyglet window manager plugin for the engine, and I'll have to say that I love it! Compared to Pygame:
- No dependencies
- No building needed to install (it was a nightmare to get Pygame installed on OS X)
- Better documentation
- Cleaner interface
- More features, such as multi-window and multi-screen support
- Opens a window on OS X in a fraction of a second vs. the couple of seconds with Pygame
- Maybe more...
I blame this thread on Gamedev.net for making me do it. Of course Pyglet is still in beta and isn't nearly as widely used as Pygame, but still, feels much better at least at this point. Next I hope to finally get to resource management or rendering.
Laying eggs
I've been lost on another side path for the past few days (and being lazy on purpose as part of my Christmas holiday ), but hopefully this is the last one on my main path of producing something I can actually show you, my valued readers! ...and something I can play with myself. Oh, I haven't told about my main path? My roadmap for the near future is:
- Implement resource loaders
- Get the renderer plugin working again
- Start writing scene management
- Start writing Red Nebula
To explain the first step, I probably have to explain plugins in Spineless (as it's still called, new name is pending; also see end of this post). Plugins are used to implement low-level parts of the engine which depend on an underlying library. At the moment these include the window manager (Pygame plugin implemented) and renderer (OpenGL plugin). Audio mixer, networking and physics are other examples. As such, there can only be one plugin per group loaded at a time.
Resource loading used to be based on similar plugins too. There would be eg. Pygame and PIL plugins for images. The problem was that this was mixing resource representation with loading. As such, you couldn't for example load models using both the Collada and OBJ plugins. I'm going to add a second type of plugin now, the resource loader. There can be many of these loaded at once, and any loader can be used to load resources. For some resource types, there can also be toolkit plugins, which you can only load one at a time.
And finally, about the side path. Over the course of this new engine revision, I implemented at least three different ways of loading plugins, none of which I was really happy with. This was before I had learned that setuptools can be used to discover and load plugins! After throwing some code away and writing literally a few lines of setuptools-using code, I had far more elegant plugin loading implemented. Welcome, setuptools!
I've also been thinking about a new name for the engine. It's not critical, but it's something I want changed. Unfortunately, coming up with good names is extremely difficult. I have a couple of options:
- Some derivative of Sampo, since it's from Finnish and magical
- Something related to the (code) name of my game: Red Nebula. Unfortunately the obvious choice Nebula is already taken at least a couple of times.
- Something else:
Suggestions are welcome.
MVC, my friend
As I was finishing high level design of scene management, I realized it was starting to resemble the Model-view-controller pattern. The (hopefully) more or less final design is sort of a hybrid of the alternatives I already presented:
- Entities contain arbitrary data in attributes. These compose the Model.
- Entities can contain any amount of features; these are the controllers.
- Subsystems (for lack of a better name) link entity attributes to lower-level systems - such as the renderer, audio mixer and physics simulation - and thus represent views into the scene.
Features are normal tasks in the engine, based on cooperative multitasking. They can read from and write to attributes and create, trigger and listen to signals (an implementation of the observer pattern), which is how they communicate with each other. Subsystems also listen to signals to get notified of attribute changes. Attributes can be shared between features; for example transform is a common attribute probably used by almost all features and subsystems. Sharing of attributes is based purely on their names, there's no actual cooperation between features and subsystems except for signals and of course documentation.
I think a rough example is in order again:
- A ship gets hit, triggering the hit signal.
- The damage controller feature is listening to this signal and gets notified.
- Damage controller decreases ship health accordingly and notices it's below zero: it adds a destruction sequence feature to the ship entity and stops listening to hit events.
- Destruction sequence adds an audio source attribute to the ship entity (if it doesn't already exist), spawns particle effects for a while and finally marks the ship entity for removal.
- The audio subsystem notices the new audio source and adds it to the low level audio mixer.
What do you think? Input is still welcome, I haven't actually started implementing this yet. And I still have at least a couple of open questions:
- How should signals be triggered externally, for example by features in other entities? Should they just trigger the signals directly, or should there be an "external API" consisting of callable attributes?
- Should features occupy named slots like attributes, or should they just reside in a generic list? I'm currently leaning towards the latter approach and reserving names just for attributes, since feature don't have to directly know about each other.
I still have to design the rendering pipeline; I already have a general idea of what I want, but details are kind of blurry. But that's the topic of another post.
Between designs
Yesterday and this morning I've read a lot of material on various topics related to scene management, rendering and a host of other subjects. TomF's Tech Blog was especially useful with rendering. I think I now have a relatively good idea about what I need in scene management and what features it should have. However, at the moment I'm torn between two designs, which are roughly equal to the first and third alternatives in my last post. I wrote small and rough examples on both to illustrate, and input would be really welcome at this point. The example is a space ship with an AI, a rigid body for physics, an audio source for positional sound, a particle effect for the engine and a turret, which in turn contain its own AI.
1. Data container entities with single-instance subsystems handling all the logic
ship.visual = ship_mesh
ship.rigid_body = ship_body
ship.logic = ShipAI()
ship.audio_source = AudioSource()
effect = Entity()
effect.visual = ParticleEffect()
effect.parent = ship
effect.transform = engine_transform
turret = Entity()
turret.visual = turret_mesh
turret.logic = TurretAI()
turret.parent = ship
turret.transform = turret_slot_transform
2. Feature (aka component) container entities, with all the logic and data contained in the features
ship.add_feature(ShipAI())
ship.add_feature(ship_mesh)
ship.add_feature(ship_body)
ship.add_feature(AudioSource())
effect = Entity()
effect.add_feature(Link(ship))
effect.add_feature(ParticleEffect())
effect.transform = engine_transform
turret = Entity()
turret.add_feature(turret_mesh)
turret.add_feature(TurretAI())
turret.add_feature(Link(ship))
turret.transform = turret_slot_transform
Which do you like more? In my opinion, the first option has the advantage of being perhaps more intuitive and clearer to use: you just assign features to attributes, whose name tells what they are for. On the other hand, the second interface depends less on magic and is perhaps easier to extend with new feature types, as there are no predetermined names for feature "slots" (in the first option, the names are defined by the subsystems that handle the logic of entities). Of course you could also use subsystems in the second option and "intelligent components" in the first option, but these two interfaces seem to fit those two underlying designs best, at least in my opinion.
If you have any questions or general comments about either of the designs, feel free to post them, all input is welcome.
Research phase
I've been doing some research and brainstorming for both the engine (still without a new name) and Red Nebula. I'm trying to design a new scene management package for the engine, including a new renderer. What's certain at this point is that it's going to be based on entities with components. Entities are more or less dumb containers for components, which describe the behaviour of the entity. Data lives in either the entity, its components, or both, depending on the exact design. Evolve Your Hierarchy is a good article on what it's about and why you should do it.
This thread on Gamedev.net has been really helpful for getting them brain juices flowing, and as I wrote there, I've got a couple of alternatives I want to think about further:
- Very similar to the misguided attempt of creating a unified scene graph for Spineless, but on a higher level, based on game entities, not low-level scene graph nodes. Entities contain just data, while subsystems (or workers as I called them) contain all the logic of how to deal with the data. There are no components per se.
- Components define only behaviour, while entities contain components and their (possibly shared) data.
- Entities are solely containers for components, while components contain both behaviour and data.
At the moment I'm mostly leaning towards the first alternative, though the other two have their advantages too, and all of them seem quite elegant to me. I'll have to think more about this first, and input is of course always welcome.
Brainstorming for Red Nebula has piqued my interest in reading sci-fi again, so I started reading Iain M. Banks' Use of Weapons. I really like his stories and writing style; they're definitely "high sci-fi" in the sense that technology is really advanced - space battles generally last only fractions of a second - and there are actions sequences and such, but they're not corny adventure stories or anything. I think the genre is called "hard sci-fi". The other sci-fi writer I really like is Philip K. Dick, though his style is completely different and not that much centered on technology.
I've also done some coding, but not much. Mostly just stubs for the new scene package and small fixes here and there. I should get resource management out of the way at some point, before starting to really work on scene management.
Busy and exhausted
Three days of training capoeira behind, one left (tomorrow). It's starting to feel quite exhausting, but has been really fun too! That's also the reason I haven't updated in a while, and haven't made much progress either. But I've done a bit...
The plugin system and layout is hopefully more or less final (for) now and the renderer is starting to get together again. I want to get the renderer plugin done and do some changes to resource management, then start working on scene management again. When that's sufficiently done, I can finally start working on the actual game. I'm not going to work on the engine any more than the game requires. I also released a simple tool for counting Python lines of code a couple of days ago.
Tomorrow's my final exam for this Autumn and on Friday the deadline for the infovis project, so I will probably have a bit more time for hobby programming afterwards. The week after I'm going to my parents' for Xmas, and who knows what will happen after that...
Design phase
First, thanks for the encouraging comments. Even a comment or two will help me keep motivated about the projects, especially since there isn't anything concrete done yet.
Lately I've been spending some time on thinking about design, of both the engine and the game. Specifically:
New name. Now that I pulled the plug on Spineless as a public open source project, it's the perfect time for a name change. Spineless was meant to be an ironic name, but I got a lot of questions on why I chose the name, and probably lots of negative associations. Although the engine won't be public again for a while if ever, I want to make the change now.
Engine layout. Also connected with the "death" of Spineless, I'm going to restructure the engine again based on my experiences with the rewrite. It's more or less just moving things around, not really rewriting anything. I want to get the layout and especially plugin implementation right from the beginning to save major headaches down the road.
Red Nebula roadmap. I now have a rough idea on what to work on first, and what's important for the overall goal of the game. I want to get something pretty (well, at least screenshot-worthy) and interactive together as soon as possible. Unfortunately I can't get started on that yet since the renderer isn't ready, but I've been doing some research and design so I can get started as soon as the engine is sufficiently done.
Teasers! Red Nebula will be 3D, it's going to be a long project with no clearly defined "finished" state, and I'm going to develop it incrementally, with ever-increasing scope and detail. As long as I'm interested and have faith on it being fun, that is.
About Me
1 month ago from Twitter for iPhone
2 months ago from Digsby
2 months ago from Digsby
Recent Comments
- Benoit Jacob on Help needed
- Jussi Lepistö on Help needed
- Benoit Jacob on Help needed
- Jussi Lepistö on PyEigen 0.2 feature complete
- Benoit Jacob on PyEigen 0.2 feature complete
Cool Python modules
Favourite Blogs
- 2D Boy
- D Baumgart
- Data Realms
- Dwarf Fortress
- Entity Crisis
- Flash of Steel
- Introversion Software
- Kloonigames
- Stephen Whitmore
- Wolfire
- Ysaneya
Archives
- May 2010 (2)
- March 2010 (6)
- November 2009 (1)
- April 2009 (1)
- March 2009 (3)
- February 2009 (2)
- January 2009 (2)
- December 2008 (3)
- October 2008 (1)
- September 2008 (1)
- August 2008 (1)
- July 2008 (4)
- June 2008 (11)
- May 2008 (3)
- April 2008 (2)
- March 2008 (1)
- February 2008 (10)
- January 2008 (4)
- December 2007 (8)
- November 2007 (9)