Generalizationismic
Phew, been a busy week, but today I got quite a lot done again. I generalized the code for input mapping, component subsystems (which are responsible for managing the entity components of a game world) and collision handling, and I'm quite happy with all of them at the moment. Terrain is also a bit more interesting now (see screenshot below). If I have time, tomorrow I'll continue on gameplay. Though after that, there will most likely be a whole week without any progress for Real Life reasons.
My biggest problem at the moment is choosing starting locations for units. They need to be more or less level, but with procedural terrain it's not always granted that there will be level ground at all. To start with, I think I'll first randomize the general area the unit will be placed at, then look for a location nearby that's level enough. If a location can't be found, move the heightmap around to create a level spot. Later I'll probably try to handle things like starting between two huge cliffs or facing a cliff wall that prevents you from shooting in that direction at all.
Another problem with starting locations is that since I have physics simulation going on, it will be really difficult to find starting positions that are stable. The problem will be even greater if I later introduce units whose shape is a bit stranger. I think I'll solve the problem by first finding an approximate starting location for units, then running physics simulation at high speed for a while without drawing, then check if units are upright and settled down. If not, find a new starting position and repeat.
I have also been brainstorming the shmup with a friend. It's most likely going to be my next project. We got some wild but doable ideas bouncing around, it should be really interesting. But more on that later as things get a bit more solid.
Component-based fun
As I suspected, most of yesterday was spent snowboarding and playing board games, but today I have been working quite a lot on the game again. Specifically, I've been working on component-based entities. It was quite a big a change and it essentially had to be done all at once, so the game didn't even start for the whole day. And now all I got is a black screen with the HUD (GUI) drawn on it, so something's obviously wrong, but the hard part should be behind.
Though the code is still a bit of a mess and the transformation to components isn't fully done yet, I can really say they clean up the code structure and responsibilities a lot. Communications also work better than I expected, at least at this point. We'll see what problems I run into when things get a lot more complex. I really like the entity type / entity distinction too. You can already add new units and artillery shell types to the game by placing an appropriate Python script file in the "units" or "shells" directory, respectively. In any case I'm happy to finally get back to "real" progress after this transformation. And you can start expecting screenshots again next week. 
Btw, if you want to know more about how some part of my design works, feel free to ask and I'll talk about it in a future post.
Day four: entity types
Got more stuff done today. I started on entity types with a type database, added a simple texture manager and again structured and consolidated lots of code. Entities are all the visual and/or physical objects in the world: at the moment the terrain, units and shells. Entity types define properties for entities, and entities can be created from entity types. Two different tanks would be two different entity types, two tanks of the same type would be different entities but the same entity type.
Before I can get this done though, I think I need to formalize entity components a bit. At the moment I'm just adding arbitrary attributes to entities, but I'll need to keep track of them somehow. Physics- and gameplay-related attributes could be collected to their own components. With the flow I've been in for a good part of the week though, I don't expect this to be a serious problem. Tomorrow will again be a bit busier in the real life department and on Saturday I'm probably going snowboarding with a few friends, but I'm still expecting at least some progress.
As a small statistics, the project has exceeded 1000 lines of code (including comments and empty lines).
Slow day three
As expected, today was a bit slower on the coding front. I did manage to implement a unit-based turn system (as opposed to a player-based), meaning a player can potentially have multiple units and not all units have to be controlled by players. There's also really basic collision response now: shells disappear when they hit anything. I'm tempted to improve the camera next, but I think I'll start fleshing out units tomorrow instead. Gameplay before polish. Until tomorrow, then.
Day two
Like yesterday, I didn't get what I wanted to done, but did get as much done as I wanted to. Summary of today's accomplishments:
- Physics simulation for all objects, thanks to Chipmunk (see screenshot #1 below)
- Units can now shoot, but turns don't change yet (screenshot #2)
- Input mapping is done in a really nice, general and configurable way, though still needs more work, but that will be for later (this took quite a while to write)
- Lots and lots of structuring and cleanup of code
I'm really, really enjoying working on this project. Most problems feel bite-sized unlike the hurdles I was facing with complex 3D graphics. My current plan is to continue making smaller projects to ease my way to more complex projects. Along the way, I can start collecting and consolidating common pieces of code for the games, and hopefully end up with a much better game engine than the one I used to work on. For the next project I'm probably going to use at least some 3D graphics. After that... who knows. But first I will, of course, finish this one. I want to show I can get at least something released after too many years.
One feature I was going to write about this morning but forgot is the turn system. I'm not going to implement a traditional I-go-you-go (alternating turns) system, but not a we-go (simultaneous turns) system either. What I have in mind is very similar to what I've only seen one game, Titans of Steel do. The idea is that each action takes some amount of time, and you get a turn each time your action is done. What this means in practice is that if player A has a light tank capable of shooting one round per second with its light gun, and player B has a heavy tank firing one round per five seconds with its heavy gun, player A gets five times as many turns as player B. On the other hand, player B's gun will probably do a lot more damage and create much bigger explosions than player A's gun. And Player A's tank is probably faster. This should give you some alternative strategies to choose from, and heavier tanks will not be absolutely better.
Tomorrow will probably be a bit slower on the gamedev front as I have people to meet and other things to do, but I'll still probably get at least something done. And keep you updated, of course.
Plan for the day
Ok, I'm all ready to start development for today. Today I'm going to focus on gameplay and playing around with physics assisted by Chipmunk. But first I'm going to write a bit about my plans for the game.
There are two major gameplay features and one programming technique I want to emphasize. Let's get the dull technical one out of the way first. I wrote about component-based entities back in December but never got far enough with my "main project" to get anything actually implemented. I'm going to remedy that with this game and experiment with component-based entities. It'll be a very useful experience for future projects and hopefully some readers. But more on that later as I start implementing that stuff.
And now the interesting stuff. The feature I most liked about my old artillery game was its modular weapon system I wrote about in my memoirs. I want to create something similar, but of course better this time. Maybe I could even let the players customize their weapons, we'll see... The other feature is not really a feature, but a kind of a fixation of mine. In addition to sci-fi, I've always liked "pseudorealism". Not simulation-level realism, but I've always liked stories and games that are not pure fantasy. In the artillery game, this was manifested as separate kinetic and explosive damage, drag for the artillery shells and other features more complex than usual for the genre. I have also always dreamt of writing a pseudorealistic shmup (shoot'em'up), so maybe that will be my next project...
And now, back to work!
Day one
Ok, so I didn't actually update during the day and didn't get an actual playable game prototype done today, but I'm damn pleased with my progress in any case. And I don't remember programming being this satisfying for a long, long time!
Anyway, I got randomized, heightmap-based terrain and basic units implemented. You can also freely scroll and zoom the camera using the mouse. I started on gameplay but didn't get any actual game mechanics done yet. The basic groundwork is already there, but I need some kind of "game physics" going on next. I'm not sure if I should just make a quick hack or use something like Chipmunk right from the beginning (I'm going to eventually use physics simulation anyway). The code isn't a horrible mess, but I have avoided getting bogged down perfecting a design. Instead, I've done what needs to be done to get a feature up and running, then structured it better afterwards.
Here are the promised screenshots anyway, testing 200 units randomly scattered around. I found the images / textures on Google and have no idea about their copyright, but this is just a prototype after all. Zooming isn't constrained in any way yet. The units are actually resting on terrain, not floating above it, but the texture has a bit of empty space at the bottom and there's no concept of offset for the units yet.
Tomorrow I'm going to write a bit about what I have in mind regarding the design of the game, and of course continue actually programming. Stay tuned!
Roots
Morning.
First order of the day is a little rant and laying out of plans. As I said in an earlier post about my history as a game developer and yesterday's post, I haven't really done any game development for a long while. I think my problem is perfectionism.
"Back in the day" I used to just smash code together in an ugly mess that would make feel sick now, but I actually got things done! Since I started paying attention to elegant code, code reuse and all the other "proper" stuff, I haven't really finished anything. I think it's time to get back to the roots. Today, I'm going to recreate the game I first released, Arty (which I talked about in my the memoirs post) and this time, I'm not going to give any thought at all to code reuse. I'm going to start on a clean slate and use no code from my other projects.
I'm going to update my progress in this post during the day. Also, as always, you're welcome on the #python3d IRC channel on the Freenode network. First, I need some coffee and read the Pyglet documentation a bit. Then I'll start creating some procedural 2D terrain. I'll keep you updated.
Programmer’s block
I know, I know, I haven't written an entry for a while, and I haven't actually got anything done either. I've been struck with programmer's block: for many days now I've fired up Eclipse and just stared at code but getting nothing actually done. I just can't seem to get myself to write anything. It all started with my problems with how to implement materials and stuff, which isn't really something I can just pass by and work on something else since it's critical to rendering...
Maybe I should try to code something completely different to get my programming motivation back, a 2D game using Pyglet for example. It might help me get back to my main project too.
During tomorrow, barring any unexpected obstacles, I promise to write at least a minimally playable 2D game prototype and write about it. With screenshots! I promise this more to myself than readers of this blog, since I've been away from game dev for too long.
Rumours
Rumours of me disappearing have been grealty exaggerated. Though being ill and concentrating on studies (for a change) have stopped me programming for a while, nothing has been abandoned. In fact, I did what I have been planning to do for ages: I learned Blender. Now I can hopefully make my own test models instead of relying on artist friends and stock models for all testing.
Anyway, I should hopefully be a bit less busy starting next week, and I hope to be back to full coding speed again.
About Me
5 days ago from Twitter for iPhone
4 weeks ago from Digsby
4 weeks 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)