Slow development

posted in Every Semicolon
Published August 11, 2008
Advertisement
I'll be talking in this entry about my engine progress, changing game plans, some thoughts on potential XNA development and thoughts on making a game using Exult Studio.

ES Engine Development

I realised it has been a while since my last journal entry so I thought I could use it as a way of getting myself back into a good attitude for development.

Following my last journal entry, I wrote out a roadmap that detailed what I wanted to get done for each subversion leading up to version 1.0 of the my engine. It only took me a day or two to reach version 0.3 (I called what I was up to when writing the roadmap version 0.2) and estimated it would take me about half a week to reach version 0.4. About 1 month and 1 week later I got there. I can put this down to a few things, the top one being laziness, but I've also had some job interview-y stuff going on that has distracted me.

At any rate, looking over the upcoming tasks for 0.5, I'm really looking forward to getting back into it and I'm hoping to get through it all much quicker now. The roadmap was shifted around a bit as I decided on new features of the engine that affected others (such as going with a component system for game objects), but mainly what I've done recently is:
  • Animation system
  • Directional light shadows
  • A base per pixel lighting shader with features that can be toggled (eg. Num lights, normal mapping, parallax mapping, specular, specular mapping, shadows, shadow quality, glow/emissive map)
  • Rewrote LUA Manager to work by running already loaded functions rather than loading the lua file every time it's used as I was doing earlier (LUA beginners mistake :) )
  • Fixed timing functions


ES Engine Shot 01 ES Engine Shot 02

I'm still having issues with calculating the time delta each frame. I've never had this issue in the past and rewriting the functions 4 times with different time functions and precision didn't yield any different results. The deltaT seems to have an erratic result a couple of times per second (depends on the current frame rate) which results in jumpy movement. I've got to test the situation more on other PCs to see if it's a hardware problem. I'm using an Athlon X2 4200+ which is known for timing issues, but I've downloaded the supposed fix and in my code I'm setting the thread affinity manually in an attempt to avoid any issues, but it hasn't fixed the result. I've tried it briefly on a higher spec PC which was fine, a much lower spec laptop which was fine and a similar spec laptop (totally different CPU than on this PC) which seemed to have similar issues.

So to get to 0.5 I've got to code:
  • A console
  • Physics stuff: Tri-mesh objects, convex objects and a base physics character object
  • Ragdoll objects
  • XML Parser (probably will just use TinyXML)
  • Hardware skinning for boned animating entities


Changing Game Plans

So last journal entry I talked about probably moving away from making an RTS and instead making something smaller in the vein of my previous game 'Outworlder'. Shane, my cousin and the artist I made Outworlder with and collaborator on any future games, and I came up with a game idea that we have since postponed (and therefore I won't talk about it now) in favour of an Outworlder-esque project that would have a short dev time and will let us create a more visually compelling game.

We're starting to design the different elements of the game now and I'll talk about it more in a future journal, but it's safe to say that it won't re-use anything from the old Outworlder game. So you won't be seeing this Outworlder (player character) or the Scaly (dead enemy) and hopefully not such dodgy ragdolling :) -
Old Outworlder Screen

Instead we'll probably be going for a totally different Outworlder character and will probably have him on a world where the enemies are something like an ancient Mayan tribe. Those sorts characters and their architecture should suit the style we're going after.

I'm hoping to get a strong toolset created for the ES Engine so that once we've completed the one level version of this game, it can easily be developed further into a longer title if we want to.

Possible XNA Development Thoughts

I've thought on occasion about looking into XNA development, but haven't as I've instead been too preoccupied with developing this ending and university before that. When deciding to postpone the previously mentioned (but not revealed) idea, I thought I should look into XNA as a possible platform for when (if) we decide to develop it. While it might seem strange to ignore my own engine after it's finished, I'd merely be choosing a platform more suited to the goal of the project and being that I like to have multiple projects (game dev related or otherwise) at any one time, I'd no doubt be developing something with my engine at the same time.

From the little I've seen so far, it looks like a pretty solid framework and since I'd only be using it as a means to get a game made, I'd probably use an existing engine. The upcoming 3D editor features of Torque X are looking good so at the moment I'm thinking at the moment that I'd use that to cut down on dev time.

Exult Studio

I'm a big fan of the Ultima series, especially Ultima VII (especially especially Serpent Isle) and always look over fan remakes, extensions and the like. Exult is a fantastic project that needs no introduction for Ultima VII fans, and recently my desire to slowly develop a substantial RPG an hour at a time during train rides and the like led me to considering Exult Studio.

The idea of creating an Ultima VII style RPG over the next couple of years in my spare time when not working on other projects definitely appeals to me, but unfortunately I don't think it'll happen. When checking out Exult Studio I was quite easily able to edit the existing Ultima VII titles, but I had a lot of issues (crashing) when trying to start a new game project with Exult Studio. I spent a few hours trying to figure out if I could get around the crashing and get something started, but wasn't able to. I decided if I have that many issues with starting the project, it might not be a stable enough environment for what I wanted.

While making an Oblivion mod with TECS might be the best option at the moment, it's neither new enough nor old enough to appeal to me as an option at this point :).
Previous Entry Engine work
0 likes 2 comments

Comments

Aardvajk
If QueryPerfomanceCounter is causing the timing issues (due to the cores reporting different times as I understand it), I personally found that by calling:


timeBeginPeriod(1);


at program startup, timeGetTime() would return suprisingly good results, far better accuracy than previously and more than good enough to time frames at 60-100-ish hz.

You're supposed to call timeEndPeriod(1) at shutdown if you do this.

Honestly. I know timeGetTime() is notoriously inaccurate but I was amazed at the difference the BeginPeriod() call made - I was getting times out of it in the range of like 0.016876f sort of thing.

Just a thought. I really thought all these issues with QPC were solved now. I need to go and build a timeGetTime() back up option into my game now you've got me worried about QPC on dual cores again.
August 11, 2008 12:49 PM
Matt Carr
Yeah, I'm using QPC. While timeGetTime() would probably be fine, I'm definitely going to be continuing to try and get QPC to work. I just can't narrow down the problem yet. I've even tried setting the affinity at run time at Task Manager, but the results are the same.

The problem is that I used QPC in Outworlder without issue on this PC and I've used the exact same code from Outworlder in this ES Engine and still get the same timing issues. So I'm fairly confused at this point.
August 11, 2008 08:27 PM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Advertisement