Jump to content
  • Advertisement
  • entries
  • comments
  • views

Move along, there's nothing to see here

Sign in to follow this  


A couple of minor additions to the project last night, but a lot of thinking was done. After reading VertexNormal's journal I felt inspired to finally add a VFS to Manta-X. I was planning to write my own, but to be honest it seemed like a lot of unnecessary work and time that would be better spent on the game itself. These days I'm consigned to use as many external libraries as I can, simply so I don't lose focus and get bogged down by writing engine code. As interesting as that sort of coding is, it doesn't get the game completed. I opted for PhysicsFS and it seems to do what I want so far. I don't like it's ugly c-like naming scheme - PHYSFS_* functions and variables - and I'd prefer if it were more OO but that's just aesthetics. The actual file handling code is stashed away in a couple of managers so it won't make it into any of the game code itself, so once it's in I never have to see it again. One thing that will need a workaround is the interfacing with external libraries, namely TinyXml.

I use TinyXml for all of my Xml work and my project is fairly Xml-heavy (or will be), so there may be problems when loading/saving Xml files to the VFS. One possible workaround is that I change the way I load Xml files and pull them from strings which are obtained by calling the VFS. This doesn't solve the saving problem however, though it could be a non-issue due to the fact that the only real saving to be done will be player saves and during editing. Most edit-mode changes will need pulling into the Zip anyway and editing is not the normal course of play. Another fairly hackish way would be to modify the TinyXml library to provide override functions for the Load/Save methods of the XmlDocument. I'm fairly cautious about this approach though, mainly because TinyXml is a stable library and I don't want to knacker it with my tweaks; it'll also make it more difficult to just drop newer TinyXml versions into my base code without having to modify that again. I think the way to go is to use a workaround within my code base.

I also tweaked the particle systems, removing the alpha channel and putting additive blending in there. Whilst it's not as fast as the previous alpha blended version, it looks a hell of a lot nicer and allows for more groovy effects.

I've started on the mission planning for the first stages of the game. These are likely to be prototype missions that are played whilst I'm coding, probably won't make it into the final game but you never know. I've decided to have each mission break down into a set of objectives that can be conditionally set to mark completion. When an objective is completed, it can either trigger off more or set certain mission flags, so I'm going to have to design the system with this in mind. Mission files will easily collapse into Xml files for easy editing and parsing. The Xml action/event based scripting system I planned and tinkered with a few weeks ago should be perfect for this sort of scenario.

It's kind of ironic (points for guessing why) that this version (the prototype at least) will not be featuring an embedded scripting language per se (aside from the Xml system I mentioned previously). The reason for this is that I cannot see a perceivable situation where I'll need anything other than simple motion and AI behaviours to warrant the need for a full-scale language. Most of the enemy spawning will be done by triggers and the motion will be largely pathed, so I think this decision is valid.

Talking about scripting, I had a good hard think about how to recode the jsInvaders scripting base. I was creating/destroying aliens on the fly before, causing problems keeping the script up to date with the game. Whilst the SpiderMonkey engine could cope, it was the horrible way I wrote the demo script that couldn't (hey, it was a test!). I think that for now, I'll rewrite the actual script as the gamecode shouldn't need too much tweaking (aside from the new addition of templated JSObjects).

As a final point, I was mystified by the conversation in this thread - It's hard to believe that people actually use Internet language as part of their everyday life. It reminds me of an article I read in the newspaper about British schoolkids failing English exams because of their use of "TXT SPK" and Internet language in their papers. It's shocking how the line between real English and slang has degraded so much that people walk around saying "OMG POONED ROFFLES".

Maybe in a few years, we'll look back and all say "OMG I CNT BLVE THY USD FUL WRDS THN". [rolleyes]
Sign in to follow this  


Recommended Comments

Heh,let's pray we never degrade to using slang in our day to day lives.Though it's becomming a prob with the smaller kids nowadays.

Nice journal though.Have fun.Good Luck.

Share this comment

Link to comment

These days I'm consigned to use as many external libraries as I can, simply so I don't lose focus and get bogged down by writing engine code.

I'm in pretty much the same boat. A lot of stuff I would enjoy writing from scratch, but the more of that sort of thing I do, the less progress I make on the actual game. I started out writing my own scripting language from scratch, switched to Lua instead when I decided I needed to start making real progress. Started a VFS library, switched to PhysicsFS instead. Started a cross-platform OpenGL wrapper, switched to GLFW instead. Yay for open source, eh?

Share this comment

Link to comment
Nah,not when I am trying to learn details.

I am perfectly happy to use OpenGL to make games, but right now I am experimenting/learning software rasterization , I myself cant belive how much time I spend on SVGA and how much I have learnt.

Yea, would agree with my whole heart going too much into micro details will give us less time to do the macro details.

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!